Issue #15928 has been updated by chrisseaton (Chris Seaton).


There are specs that cover this, so at least it is how Ruby implementors understand that it is intended to be, and it's been this way for a decade or more.

https://github.com/ruby/spec/blob/ff678eb339f16fc5424b25f2e2c82c59c14583be/language/constants_spec.rb#L138-L150

----------------------------------------
Bug #15928: Constant declaration does not conform to JIS 3017:2013
https://bugs.ruby-lang.org/issues/15928#change-78626

* Author: yugui (Yuki Sonoda)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.7.0dev (2019-06-16T14:01:46Z master d4929f5185) [x86_64-darwin18]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
The order of evaluation in constant declaration does not conform to JIS 3017:2013 11.4.2.2.3.

# Problem

Suppose that we are evaluating the following program.

```
expr::C = lhs
```

The standard seems to be requiring the following evaluation order:

1. expr
  * raise a TypeError if the value is not a kind of Module
2. lhs
3. rb_const_set(expr, :C, lhs)

However, the actual implementation evaluates in the following order

1. lhs
2. expr
3. rb_const_set(expr, :C, lhs)
  * raise a TypeError if the expr is not a kind of Module


# How to reproduce

The next program does not raise "recv" but raises "value"

```
raise("recv")::C = raise("value")
```

The next program does not raise a TypeError but raises a RuntimeError

```
A = 1
A::C = raise("value")
```

# Question
* Is this interpretation of the standard correct?
* If it is, Should we change the current behavior?
* If we shouldn't, does it mean an issue in the standard?

c.f.
* https://twitter.com/n0kada/status/1140234416175763456



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>