Allow slurping at the beginning rather than just the end (for destructuring and method definitions)

[StevenWhitaker]

Sometimes I find myself wanting to do something like

(data..., p1, p2) = function_call()

because function_call returns many values, but I really only need to separate out the last one or two because, e.g., I will just splat the first however many values into another function call. Granted, I could accomplish this with

x = function_call()
(data, p1, p2) = (x[1:end-2], x[end-1:end]...)

but I like the idea of having a concise syntax to do that.

(I see that #2626 touched on this, but I wasn't entirely sure what the conclusion was.)

It could also be cool to have this for method definitions too, e.g.,

function f(x..., y)
    # code here; x contains 0 or more arguments
end

One could argue that I should just reorder my arguments, but if, for example, I'm defining an infix operator reordering arguments might not be ideal. For example, |> could be defined as

|>(x..., f) = f(x...)

and then instead of, e.g.,

computation() |> args -> g(args...) # g takes two arguments, computation returns two results

I could do

computation()... |> g # no anonymous function needed

(Admittedly, defining an infix operator with not exactly two arguments probably doesn't make the most sense in most cases.)

I'd be interested to hear of other potential use cases, and to hear whether it's even possible to allow slurping in this way.

[wnoise]

The fully general case would also allow "middle" slurping.

[martinholters]

For destructuring assignment, that might be possible, but potentially a bit inefficient: In the general case, where the length of the RHS is not known at compile time, the generated code would need to first collect into a temporary and then peel off the last n elements.

Allowing this for function definitions is much trickier, as it would mean allowing Tuple types with Vararg now only at the end (for the function signatures). That would certainly make subtyping much harder. And just allowing Vararg first or last but not in the middle (in the hope that might keep things simple enough) would not work because type intersection makes it appear automatically. Consider the intersection of Tuple{A,Vararg} and Tuple{Vararg,B}: That would be Tuple{A,Vararg,B}. Also note the intersection of Tuple{A,B,Vararg} and Tuple{Vararg,B,C} which would (unexpectedly?) give rise to a Union (being Union{Tuple{A,B,C}, Tuple{A,B,Vararg,B,C}}). I doubt this is feasible.

[simeonschaub]

Addressed by #42902