Your experiment confirmed 1.9.2 changed the behavior, like mine did.
Yes, but I got different results than those you claimed. Which made me
wonder.
I'm aware of the definition of syntax error.
Why then do you use it in the wrong way?
irb(main):006:0> x,=f 1,2
That line does not die, with an-error-checked-at-runtime, nor would
x.member (given [] does not have .member) die with an-error-checked-at-
runtime.
When the author of a test writes assert_latest() they know whether
they expect a scalar or a list to return, and they should not waste
their time checking for a single-element list before using it in the
assertion that actually checks for the important stuff.
Well, if you use "x,=..." then you have the first element and no
additional checking is needed. But if you really want to ensure the
proper number of values is returned you need to test for the array
length anyway. At least you would need to to something like
irb(main):008:0> x,y,*remainder = f 1,2
=> [1, 2]
irb(main):009:0> remainder
=> []
irb(main):010:0> remainder.empty?
=> true
irb(main):011:0> x,y,*remainder = f 1,2,3
=> [1, 2, 3]
irb(main):012:0> remainder.empty?
=> false
For consistent checking of the returned data you can do
*x = f(...)
x will be an Array even if f returns a single value only.
If I use record, = assert_latest(), and if a future bug added a second
record, the assertion would not break, that line would not break (with
a comma), and lines using record would not break.
Also I'm not sure why I need to justify the use case, if such a low-
level syntactical thing should not change in a language revision.
Actually most people seem to cope pretty well with this as only corner
cases are affected of the change. If you want to ensure no additional
values are returned you need to splat assign any way to count values, i.e.
*x = f()
It's
a bug in return *splat; it no longer behaves the same as = *splat.
It's not syntax but runtime behavior. You can and will never get a
syntax error for this.
AFAIK Matz changed it deliberately - although I have to confess I don't
remember the reasoning. You'll probably find it in the archives.
Note though that also argument assignment changed quite a bit in 1.9
which has much more sophisticated options where 1.8 only allowed for the
last parameter to collect additional values. The 1.9 model is superior
to that:
irb(main):001:0> def f(a, *b, c) p a,b,c end
=> nil
irb(main):002:0> f 1
ArgumentError: wrong number of arguments (1 for 2)
from (irb):1:in `f'
from (irb):2
from /usr/local/bin/irb19:12:in `<main>'
irb(main):003:0> f 1,2
1
[]
2
=> [1, [], 2]
irb(main):004:0> f 1,2,3
1
[2]
3
=> [1, [2], 3]
irb(main):005:0> f 1,2,3,4,5
1
[2, 3, 4]
5
=> [1, [2, 3, 4], 5]
And you have pattern matching with block arguments
irb(main):007:0> f = lambda {|a, (b,c), d| p a,b,c,d}
=> #<Proc:0x202a96c4@(irb):7 (lambda)>
irb(main):008:0> f[1]
ArgumentError: wrong number of arguments (1 for 3)
from (irb):7:in `block in irb_binding'
from (irb):8:in `[]'
from (irb):8
from /usr/local/bin/irb19:12:in `<main>'
irb(main):009:0> f[1,2]
ArgumentError: wrong number of arguments (2 for 3)
from (irb):7:in `block in irb_binding'
from (irb):9:in `[]'
from (irb):9
from /usr/local/bin/irb19:12:in `<main>'
irb(main):010:0> f[1,2,3]
1
2
nil
3
=> [1, 2, nil, 3]
irb(main):011:0> f[1,[2],3]
1
2
nil
3
=> [1, 2, nil, 3]
irb(main):012:0> f[1,[2,3],4]
1
2
3
4
=> [1, 2, 3, 4]
irb(main):013:0> f[1,[2,3,4],5]
1
2
3
5
=> [1, 2, 3, 5]
Cheers
robert