Destructuring assignments

[vonagam]

Proposed syntax with new funnel operator:

Some(var int) =< option;

if (Some(var int) =< option) {
  trace(int);
}

Render.

Relevant issue - 4300

[grepsuzette]

Probably destructuring assignement was meant in the title (instead of destructive).

But it's a really weird proposal, introduces a new operator, is entirely focused on haxe.ds.Option and fails to reuse or address the basic ideas presented in https://github.com/HaxeFoundation/haxe/issues/4300.

So (don't take it personally, @vonagam I've seen your great contributions to Haxe lately) I'd be in favor of closing to leave more room and visibility for new evolution proposals.

---

(for the above purpose, I like the approach taken by tink_core, e.g. simply: optionName.sure(). Where optionName:Option<String> and static function sure(o:Option<T>):T, the latter throwing an exception if o is None)

[vonagam]

Probably destructuring assignement was meant

Yes. (Seems to forgot to rename it there, in some places like in the file name of proposal and in the branch name it was proper destructuring, but in the title and in the text it was destructive...).

is entirely focused on haxe.ds.Option

No, it is just an example of a pattern. General syntax is:

pattern =< value;

if (pattern =< value) { ... }

introduces a new operator

Because reuse of var/final for that was taken down in the mentioned issue and a pattern can contain those too.

fails to reuse or address the basic ideas

Which ones?

[grepsuzette]

Which ones?

From this discussion: https://github.com/HaxeFoundation/haxe/issues/4300

[vonagam]

From this discussion

I know the discussion. It is linked by me in the opening comment. I am asking about: Which basic ideas does this PR fail to reuse or address from there?

[grepsuzette]

By "basic idea not reused", I simply meant there was this thread of discussion A started in 2015, which was quite interesting, and present thread of discussion B which begins with Some(var int) =< option;.

The present proposal makes me uncomfortable because it looks nothing like Haxe and also nothing like the previous discussion, which means it likely will only slow down the actual evolution of Haxe (let A' and B' be mature evolution over A and B threads of discussion, then B will not become A, B' is unlikely to get implemented because of new operator and unhaxy syntax, potential A' solution will likely only emerge after B is closed, to summarize my thinking).

[vonagam]

nothing like the previous discussion

Previous discussion's solution A was shut down. So if you want this functionality you need to come up with some new syntax that won't have same drawback as A. This one is such.

present thread of discussion B which begins with Some(var int) =< option;.

Do you want me to copy and paste things from original issue? That will not add anything new to the discussion.

The only bottleneck is syntax and here it is. Everything else is pretty clear at this point and not a problem.

potential A' solution will likely only emerge after B is closed

Really strange logic here. Original discussion was closed 5 years ago. Since then there was no significant movement anywhere on that front. You propose to close this issue because this somehow will help to move some potential inexistent solution forward. That's not how things work.

If you want the feature, but don't like proposed syntax - try to come up with and describe one that you consider haxy (your ideal A' solution).

[back2dos]

As for the "funnel operator", I think it's nice, but a little odd when compared to the other languages that have destructuring and all implement it in a relatively similar fashion:

• JavaScript: let { firstname, lastname, country } = student;
• C#: var (name, address, city, zip) = contact.GetAddressInfo();
• Swift: let (first, last) = splitName("Taylor Swift")
• Scala: var (x, y, z) = (1, 2, 3)
• Kotlin: val (name, age) = person
• Python: x, y = (5, 11)

Some of the above languages also allow assigning to existing vars via destructuring, but perhaps that's best left for a later time.

---

Generally speaking, I would like something like this, although perhaps in a way that it doesn't implicitly throw.

[Aurel300]

I think I already expressed this on Slack, but I really would prefer a syntax without a new operator. I don't think there is a useful case where destructuring is ambiguous, so as long as the left-hand side of a regular assignment contains a pattern rather than just an identifier, we can do destructuring.

var Some(x) = haxe.ds.Option.Some(1); // may throw
var {a: x, b: y} = {a: 1, b: 2}; // may throw
if (var Some(y) = haxe.ds.Option.Some(2)) {
  trace(y);
}

I don't know about the other voting members, but for me it is a no with the current syntax, a yes with a regular assignment syntax.

[vonagam]

To be clear, i would prefer an originally proposed syntax (without new operator) too.

This one is proposed on an assumption that nothing changed since then and original one is still blocked (have not seen anything indicating otherwise yet).

[Simn]

lean-reject: confusing syntax