Destructuring

[azenla]

https://github.com/DirectMyFile/dep-destructuring

[munificent]

This looks cool. If you haven't already, you should email the core-dev list about it and start building some enthusiasm around it.

I'll mark this as a draft for now, since I don't think it's ready for the committee to give it the full review yet.

[azenla]

@munificent Thanks! I have work to do on it though, still must write parts of the spec.

[munificent]

still must write parts of the spec.

You can do that first if you want, but it doesn't hurt to start getting people involved early.

[azenla]

@munificent Can you evaluate my changes to the spec and tell me what you think? I need feedback to verify that this proposal is feasible.

[munificent]

It's within the bounds of reason, I think. But it's also a big change, so expect to be putting a lot of work into this if you want to get it to a point where it can make it to TC 52. This will be a marathon, not a sprint. :)

[azenla]

@munificent I'm prepared, I am dedicated to Dart, I will do whatever it takes :)

Thanks for your encouragement too btw, honestly before you contacted me, I was considering dropping the proposal. You have inspired me to keep it going :)

[eernstg]

Hello Kenneth,

that's great -- and it is a very interesting proposal! Looking forward to
the discussions about it, too. ;-)

On Mon, Mar 30, 2015 at 9:39 PM, Kenneth Endfinger <notifications@github.com

wrote:

@munificent https://github.com/munificent I'm prepared, I am dedicated
to Dart, I will do whatever it takes :)

Thanks for your encouragement too btw, honestly before you contacted me, I
was considering dropping the proposal. You have inspired me to keep it
going :)

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

[lukechurch]

Nice proposal. I think I'd be interested in seeing a little more about what we do when the code has problems.

E.g. trying to reference properties that don't exist, having the wrong types on the LHS assignments. Could you consider adding a section on warnings and errors?

[azenla]

@lukechurch Yes, that's my next goal.

[polux]

Pasting my comment to core-dev here as this seems to be the place where it is discussed:

Hi Kenneth,

I have no authority whatsoever regarding Dart, the following is just my personal opinion.

I'm hoping that one day Dart can have full-blown pattern matching. I know this is not going to happen anytime soon so I'm all for having a lightweight version first like the one you propose. I think it would be nice if we could keep this in mind while discussing your DEP though: we should try to make destructuring forward-compatible with a possible future implementation of pattern matching in Dart.

I know this sounds impossible as there is no spec for that yet, but we can at least take some guesses. For instance it seems to me that staying away as much as possible from ad-hoc syntax for certain datatypes is a good start (although there's already a special syntax for constructing lists and maps, so it sounds ok to have a special syntax to deconstruct them too). Also we should try to ask yourselves whether the many notations you introduce are somehow consistent with respect to scoping.

[azenla]

@polux I would absolutely love to help with Pattern Matching. Is it possible for you to make a quick GitHub Gist or something with a description of what you would like? I am new to language design, and have never really used pattern matching before, so I will need some guidance on this :)

[polux]

I'm not sure what I'd like :) I think the main challenge wrt integrating pattern matching in Dart is that dart classes aren't necessarily algebraic datatypes. More generally pattern matching seems to break abstraction.

One way to reconcile pattern matching and abstraction is to use views. It is the way Scala implements pattern matching for instance.

Another way, which is like views but on steroids, is to have first-class patterns (patterns are themselves objects you can pass around and combine). That's the approach of an extension of newspeak and of this paper for instance. I've tried to implement something similar to the second link but it's not so nice to use. You really need support from the language for binding new variables at some point if you want a seamless integration.

All these solutions are pretty heavyweight and having something like you propose as a first step sounds good and more realistic to me. I just don't want us to close the door to a future full-fledged integration of pattern matching in Dart. So I'd like us to keep that in mind.

[munificent]

Pasting my comment to core-dev here as this seems to be the place where it is discussed:

Oh, God. This is not where this should be discussed. We'll end up with one giant thread no one can follow. It would be better to either use core-dev or file issues on @kaendfinger's repo for this.

[polux]

code-dev SGTM but it is my impression that "the community" is mostly not present on core-dev. My understanding of the DEP process is that we're in the "community discusses the proposal" phase. Maybe @kaendfinger should notify misc that this discussion is taking place on core-dev.

[munificent]

"the community" is mostly not present on core-dev.

Yet!

Maybe @kaendfinger should notify misc that this discussion is taking place on core-dev.

👍

[lrhn]

I moved a reference to this proposal to the language repo: dart-lang/language#207
The DEP process has been discontinued, so nothing more will happen here.