Apologies if this is a dup, I thought I saw an issue for this a while ago, but couldn't dig it up.
The current behavior:
julia> x, y = (1, 2, 3)
(1,2,3)
julia> x
1
julia> y
2
@andreasnoack, @vchuravy and I think this behavior's bug-proneness-to-usefulness ratio might be a bit high. We should be consider making it an error. Users could easily (and more clearly) write x, y = take((1,2,3), 2)
to accomplish the same thing.
Especially it might be clearer if we introduce _
as a special bitbucket variable. https://github.com/JuliaLang/julia/issues/18251#issuecomment-242819855
The current behavior seems kind of Matlab-inspired, I think. It's really useful for a function like eigs
that returns a tuple of a zillion things, but where most of the time you only want two, and you can write λ, X = eigs(...)
to discard all of the extra outputs.
As discussed on the mailing list, it also allows you to add outputs to a function that already returns a tuple without breaking most existing code.
It's really useful for a function like eigs that returns a tuple of a zillion things, but where most of the time you only want two, and you can write λ, X = eigs(...) to discard all of the extra outputs.
If the caller only wants the first two elements of the return tuple, they can always explicitly write λ, X = take(eigs(...), 2)
.
@jrevels, yes, they can call take
, but that's a lot more verbose if the common case is that you want only a subset of the outputs.
Not having to explicitly call take
only saves a couple of characters, while if you're chasing down a bug as a result of this feature, the investigative cost can be annoyingly high. The OP here was the consensus from a discussion within the MIT group after an overly long bug-chasing session where this behavior was the culprit.
A potential replacement here could be λ, X, _... = eigs(...)
— that's https://github.com/JuliaLang/julia/issues/9343 + https://github.com/JuliaLang/julia/issues/2626.
Is it at least possible to retain λ, X, = eigs(...)
? (with the trailing comma.)
We generally allow trailing commas in as many places as possible, so e.g. a, b, = [1,2,3]
leaving a == 1
and b == 2
. We could, however, allow this a, b, ... = [1,2,3]
to explicitly discard the rest of the values. The real utility, imo, of just ignoring additional values is that it allows functions that return tuples of values to return more without breaking code, but maybe that's not as useful as I think in terms of an upgrade path.
Most helpful comment
Not having to explicitly call
take
only saves a couple of characters, while if you're chasing down a bug as a result of this feature, the investigative cost can be annoyingly high. The OP here was the consensus from a discussion within the MIT group after an overly long bug-chasing session where this behavior was the culprit.