Erik Ernst

> > **Disagreed**. First note that we have already decided that they must be treated as separate functions rather than simply as compile-time references to other constructors: > > That...

> > which imply that this declaration has a behavior which is to invoke the redirectee passing on its formal parameters > > And that's what I disagree with. I...

That's a great analysis and write-up, @lrhn! It really clarifies several points. However, I end up with less absolute conclusions because I disagree on the starting point: > I take...

@tatumizer wrote: > For Iterable - I don't understand it. The point is that `e.{ }` is an abbreviation of `e.(T this){ }` where `T` is the statically known type...

@kasperpeulen wrote: > You could also combine this with the cascade operator That's the intention! (I'm going to work on the 'proposal' part later today), and also `e?.{ ... }`....

@tatumizer wrote: > we can now write .. Adding in the semicolon that we will presumably need (until we settle on something in the area of optional semicolons): ```dart var...

@lrhn wrote: > .. extend #43 with `e1 -> { block where this is bound to value of e1 }` That's definitely an interesting idea! The pipe operator will surely...

@tatumizer wrote: > we have nested "this" which is very confusing (javascript is famous for that). In JavaScript there are a bunch of reasons why the meaning of `this` is...

@tatumizer wrote: > Everything looks consistent [here](https://github.com/dart-lang/language/issues/260#issuecomment-471577661) True, it does add up quite nicely!

@yjbanov wrote: > This looks similar to the [argument blocks idea](https://github.com/munificent/ui-as-code/blob/master/ideas/named-argument-blocks.md) I proposed similar things already a couple of years ago and it's definitely possible that these ideas blend in...