a, b... = [1,2,3]

[StefanKarpinski]

This would be a very nice syntax for taking head and rest. Likewise a..., b = [1,2,3] might be good for slurping the initial elements into a and the tail element into b.

[JeffBezanson]

Should we add tail(itr, state) to the iteration protocol, giving a collection with elements starting at the given state?

[StefanKarpinski]

In some cases that would be easy but it won't always. Having a Rest{T,S}(itr::T,state::S) type that wraps an iterator with a state and allows you to iterate the rest of it might do the trick.

[JeffBezanson]

Ah, of course, the Drop iterator already does something very similar to this.

[StefanKarpinski]

Rest might be a better name for that iterator.

[JeffBezanson]

Well, they are actually a bit different. Drop takes a count of items to skip. Rest would start from a given state, making it basically trivial to implement.

[StefanKarpinski]

Ah, that's true, but the Rest type can server both purposes, it's just a matter of how you get there – by taking an explicit state or a number of values to skip over.

[ViralBShah]

Wouldn't it be possible to simulate matlab-style varargout with this? I guess even though possible, it should be avoided since it would play havoc with the type system.

[JeffBezanson]

No, this does not tell the function how many outputs are requested. And actually, in a,b = f(), as long as f returns 2 or more values, this will work and just drop the rest.

[vtjnash]

But it does result in telling the iterator how many arguments are necessary, so it seems you could write the function as a continuation iterator to weakly simulate matlab's varargout (the sane version where you just do lazy computation)

[StefanKarpinski]

We could generally support Matlab's varargout if we did it lazily and changed the protocol for destructuring a little bit. The idea came up in the discussion of factorization objects. I.e. if a,b = x caused a single destructuring call to x to occur, giving some kind of boolean mask of which values should be produced. Then again, I'm not sure we really want fully general varargout since it's a bit weird that the outputs can change completely depending on how many of them are asked for.

[mschauer]

Before implementing this maybe it would be good to check whether a more general approach to destructuring assignments is welcomed. Basically, every function f with a fixed bijective inverse function inv(f) can be used to write

f(a, b) = c
-> a, b = inv(f)(c)

examples for f are tupel composition and list composition from head and tail
f(a,b) = (a,b)
but also say
(sign(x), abs(x))
and
((a,c), (b,c))
have such inverses, which can be found by applying the rule
inv(f*g) = inf(g)*inv(f)
or be provided explicitly.

[JeffBezanson]

Yes, you can do that, but it's not a new capability added by a,b... = x syntax. You can do it already. Just have the function return an iterator that computes values as next is called. Then a,b = f() will compute 2 values, a,b,c = f() will compute 3, etc., with no ... needed.
The real problem is the case of a single result, a = f(x), which just assigns the whole thing and no destructuring happens. If that breaks, composing functions starts to get difficult.