queue

> `map (.property) array` would be sufficiently descriptive and terse. However, this would run `-> it.property` for each element, which is slower than a for-loop (though a [sufficiently-smart compiler](http://c2.com/cgi/wiki?SufficientlySmartCompiler) would...

Another thought: providing destructuring inside a `for` statement is another way to provide some of the functionality, albeit more verbosely coco's current support for destructuring assignment in a for loop...

> tbh I thought coco allowed it since LS does Whoops, coco does indeed support destructuring forms in the for loop, didn't test it beforehand.

> Evaluation I actually ran into this problem where I discovered this use case: ``` coco for el of $$ \.file el.addEventListener \click construct-click-fn \type ``` Where `construct-click-fn \type` was...

> The RHS can be arbitrarily complex. Caching is nonviable unless we limit it to a single access/call, narrowing it further. Yeah, but the spread operator is such a simple...

But unlike `a.b.c ||= d`, property access is intrinsically uncachable in the spread. Everything _except_ the `.` chain could still be cached: ``` coco expr*.sub.property.access #=> el.sub.property.access for el of...

What does `get-fn! ->` signify? I don't see how that effects the proposal.

I understood that part, but nothing about that effects hushing auto-return. ``` get-fn! !-> ``` is still unambiguous.

> That leaves out `~>` and ``: - `!->` already looks like a standalone symbol and it's used plenty of places in the coco source--as well as my own projects....

There are at least a few ways to approach this: ## Ambiguity / Redundancy / Developer confusion Features that--were coco mainstream--would appear in a "fractal of bad design"-type blog post....