[ruby-core:77701] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[ruby-core:77701] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[headius]

Issue #12860 has been reported by Charles Nutter.

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 2.3.1
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:77702] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[headius]

Issue #12860 has been updated by Charles Nutter.


Rails PR (which unpacks via multi-assign to avoid this bug) filed here: https://github.com/rails/rails/pull/26854

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-60984

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 2.3.1
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:77703] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[headius]

Issue #12860 has been updated by Charles Nutter.


This behavior appears to go back as far as Ruby 1.9.3. Ruby 1.8.7 and earlier could not have regular arguments after a splat.

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-60985

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 2.3.1
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:77704] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[headius]

Issue #12860 has been updated by Charles Nutter.


It is worth mentioning that if the splatted value is not an array, we can see that `to_a` does get called before `shift`. That makes this even more unintuitive, since the calls happen in proper order but the assembly of the args list happens in the wrong order.

```ruby
a = Object.new

a.instance_variable_set :@ary, [1, 2]

def a.to_a
  p :to_a
  @ary
end

def a.shift
  p :shift
  @ary.shift
end

def f(*x)
  p x
end

f(*a, a.shift)
```

All implementations I tested output `to_a` before `shift`. However, as with the plain array, MRI delays the application of the splat until *after* the shift call.

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-60986

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 2.3.1
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:78267] [Ruby trunk Bug#12860][Closed] Splatting an argument does not obey left-to-right execution order

[nobu]

Issue #12860 has been updated by Nobuyoshi Nakada.

Status changed from Open to Closed
Backport changed from 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN to 2.1: REQUIRED, 2.2: REQUIRED, 2.3: REQUIRED

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-61633

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: 
* ruby -v: 2.3.1
* Backport: 2.1: REQUIRED, 2.2: REQUIRED, 2.3: REQUIRED
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:78860] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[usa]

Issue #12860 has been updated by Usaku NAKAMURA.

Backport changed from 2.1: REQUIRED, 2.2: REQUIRED, 2.3: REQUIRED to 2.1: REQUIRED, 2.2: DONE, 2.3: REQUIRED

ruby_2_2 r57210 merged revision(s) 56469.

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-62268

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 2.3.1
* Backport: 2.1: REQUIRED, 2.2: DONE, 2.3: REQUIRED
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/

[ruby-core:79093] [Ruby trunk Bug#12860] Splatting an argument does not obey left-to-right execution order

[nagachika00]

Issue #12860 has been updated by Tomoyuki Chikanaga.

Backport changed from 2.1: REQUIRED, 2.2: DONE, 2.3: REQUIRED to 2.1: REQUIRED, 2.2: DONE, 2.3: DONE

ruby_2_3 r57342 merged revision(s) 56469.

----------------------------------------
Bug #12860: Splatting an argument does not obey left-to-right execution order
https://bugs.ruby-lang.org/issues/12860#change-62500

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 2.3.1
* Backport: 2.1: REQUIRED, 2.2: DONE, 2.3: DONE
----------------------------------------
Ruby evaluates arguments left to right, but it does not appear to handle construction of the eventual argument list from left to right.

Take this example:

```ruby
def foo(*args)
  p args
end

ary = [1,2]

foo(*ary, ary.shift)
```

With left-to-right execution, the `ary` value should be splatted (1, 2), and THEN shifted (1) producing `args == [1, 2, 1]`.

However, on MRI, the shift occurs *before* the splat, so `args == [2, 1]`.

This is counter-intuitive. At the moment in time the splat is encountered, `ary` is still `[1, 2]`. So the first two arguments should be (1, 2). THEN the shift happens, producing a third argument of (1).

This affects JRuby running Rails because they have a small piece of code that depends on this unusual behavior: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L411-L425

This code appears to have been introduced into Rails recently, and I will file a separate issue to change it to be more explicit about ordering.



-- 
https://bugs.ruby-lang.org/