[ruby-core:103746] [Ruby master Bug#15928] Constant declaration does not conform to JIS 3017:2013

Issue #15928 has been updated by Eregon (Benoit Daloze).


Thank you for the context.

IMHO changing single assignment order is a lot simpler, and would bring consistency too.
I feel consistency also has rather low value here, multiple assignment is different to multiple single assignments, notably that all values are evaluated together.
Evaluating values first is simple to explain, I think the new behavior isn't.

BTW, it sounds like MRuby always evaluates the value first: https://bugs.ruby-lang.org/issues/4443#note-8
I could confirm it with:
```
$ mruby -e '(p :a; a).b = p(:value)' 
:value
:a
$ mruby -e '(p :a; a).b, v = p(:value)'
:value
:a
```
MRuby's behavior is simpler, consistent and more efficient.

@mame @ko1 @yugui Are we sure we want to go ahead with the change in #4443 and this one? Or should we keep things as they are in 3.0, or as change single assignment like in MRuby?
This change does make Ruby slower and the implementation significantly more complicated, as Jeremy found in https://bugs.ruby-lang.org/issues/4443#note-20.
In other words, that change is costly in terms of implementation effort, risky in terms of compatibility (maybe not so much but feels weird to me to change in 3.1), and slower.

---

> In my opinion, we shouldn't test for behavior we consider wrong.

I believe we should if that behavior is exposed to users. And "wrong" is very much depending on personal opinions, so that sounds like a bad rule.

> This is a bug fix, not a feature change, and should be treated like other bug fixes.

Like other bug fixes, none of them removes specs. They add a version guard.
A new example for the new behavior would be great, so we can clearly see what changed, but I won't fight for that in this issue (every other committer does it though AFAIK).

I recommend to see ruby/spec as a test suite shared between Ruby implementations (so it must support multiple Ruby versions), and to which all Ruby implementations can easily contribute (the name is confusing, I know, we all make mistakes).
Maybe it's easier to understand my point of view that way.
And since I'm the main maintainer/contributor of ruby/spec, I believe I get to define the vision and what is its purpose.

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

* Author: yugui (Yuki Sonoda)
* Status: Open
* Priority: Normal
* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>