Issue #18573 has been updated by tenderlovemaking (Aaron Patterson).
matz (Yukihiro Matsumoto) wrote in #note-7:
> Array.pack1 is unlikely because there is no connection between the responsibilities of the method and the Array class. I also disagree with String.pack1 for the same reason.
> The most natural candidate is Object#pack1, but I question the need to pollute the namespace for this trivial method.
>
> Matz.
Feature #18897 introduced a specialized instruction for Array#hash, but it created a new instruction called `opt_newarray_send`. I think we could leverage that instruction for the case of an array literal + pack. That would avoid the array creation. I will try to make a patch.
----------------------------------------
Feature #18573: Object#pack1
https://bugs.ruby-lang.org/issues/18573#change-104894
* Author: os (Shigeki OHARA)
* Status: Open
* Priority: Normal
----------------------------------------
# 概要
String#unpack1 の逆の Object#pack1 が欲しい。
# 背景
Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。
``` ruby
[codepoint].pack('U')
[digest].pack('m0')
[mail_body].pack('M')
[ip_address].pack('N')
```
標準添付ライブラリーなどを眺めてみてもチラホラあるようです。
ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。
# 提案
String#unpack に対して String#unpack1 というメソッドがありますが、
Array#pack に対する Object#pack1 というメソッドを提案します。
イメージとしては以下のコードのような感じです。
``` ruby
class Object
def pack1(template, option = {})
[self].pack(template, **option)
end
end
```
# 議論・課題
* Object で良いかどうかは議論の余地があろうかと思います
* メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います
--
https://bugs.ruby-lang.org/
Issue #18573 has been updated by matz (Yukihiro Matsumoto).
Array.pack1 is unlikely because there is no connection between the responsibilities of the method and the Array class. I also disagree with String.pack1 for the same reason.
The most natural candidate is Object#pack1, but I question the need to pollute the namespace for this trivial method.
Matz.
----------------------------------------
Feature #18573: Object#pack1
https://bugs.ruby-lang.org/issues/18573#change-104876
* Author: os (Shigeki OHARA)
* Status: Open
* Priority: Normal
----------------------------------------
# 概要
String#unpack1 の逆の Object#pack1 が欲しい。
# 背景
Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。
``` ruby
[codepoint].pack('U')
[digest].pack('m0')
[mail_body].pack('M')
[ip_address].pack('N')
```
標準添付ライブラリーなどを眺めてみてもチラホラあるようです。
ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。
# 提案
String#unpack に対して String#unpack1 というメソッドがありますが、
Array#pack に対する Object#pack1 というメソッドを提案します。
イメージとしては以下のコードのような感じです。
``` ruby
class Object
def pack1(template, option = {})
[self].pack(template, **option)
end
end
```
# 議論・課題
* Object で良いかどうかは議論の余地があろうかと思います
* メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います
--
https://bugs.ruby-lang.org/
Issue #18573 has been updated by Eregon (Benoit Daloze).
`Array.pack1(obj, format) -> String` sounds weird since there is nothing about Array in there.
I think `String.pack1(format, obj)` is the best option.
(`String#pack1(obj)` is confusing because of existing `Array#pack(format)` which has the reverse order).
(IMO this is something a JIT should optimize but I understand that's hard on CRuby).
----------------------------------------
Feature #18573: Object#pack1
https://bugs.ruby-lang.org/issues/18573#change-104830
* Author: os (Shigeki OHARA)
* Status: Open
* Priority: Normal
----------------------------------------
# 概要
String#unpack1 の逆の Object#pack1 が欲しい。
# 背景
Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。
``` ruby
[codepoint].pack('U')
[digest].pack('m0')
[mail_body].pack('M')
[ip_address].pack('N')
```
標準添付ライブラリーなどを眺めてみてもチラホラあるようです。
ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。
# 提案
String#unpack に対して String#unpack1 というメソッドがありますが、
Array#pack に対する Object#pack1 というメソッドを提案します。
イメージとしては以下のコードのような感じです。
``` ruby
class Object
def pack1(template, option = {})
[self].pack(template, **option)
end
end
```
# 議論・課題
* Object で良いかどうかは議論の余地があろうかと思います
* メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います
--
https://bugs.ruby-lang.org/
Issue #18573 has been updated by jeremyevans0 (Jeremy Evans).
I developed a patch for this that implemented the feature using `Array.pack1` and was going to create a new feature request for it, but I'm glad to see there already is an existing feature request for it. Here's my pull request for it: https://github.com/ruby/ruby/pull/8598
----------------------------------------
Feature #18573: Object#pack1
https://bugs.ruby-lang.org/issues/18573#change-104824
* Author: os (Shigeki OHARA)
* Status: Open
* Priority: Normal
----------------------------------------
# 概要
String#unpack1 の逆の Object#pack1 が欲しい。
# 背景
Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。
``` ruby
[codepoint].pack('U')
[digest].pack('m0')
[mail_body].pack('M')
[ip_address].pack('N')
```
標準添付ライブラリーなどを眺めてみてもチラホラあるようです。
ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。
# 提案
String#unpack に対して String#unpack1 というメソッドがありますが、
Array#pack に対する Object#pack1 というメソッドを提案します。
イメージとしては以下のコードのような感じです。
``` ruby
class Object
def pack1(template, option = {})
[self].pack(template, **option)
end
end
```
# 議論・課題
* Object で良いかどうかは議論の余地があろうかと思います
* メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います
--
https://bugs.ruby-lang.org/
Issue #17925 has been updated by kddnewton (Kevin Newton).
I agree with @yui-knk here, I think this is definitely a choice and at this point can't be changed.
----------------------------------------
Bug #17925: Pattern matching syntax using semicolon one-line
https://bugs.ruby-lang.org/issues/17925#change-104733
* Author: koic (Koichi ITO)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
## Summary
There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior?
```console
% ruby -v
ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
% ruby -ce 'case expression when 42; end'
Syntax OK
% ruby -ce 'case expression in 42; end'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
-e:1: syntax error, unexpected `end', expecting `when'
case expression in 42; end
```
So, I have two concerns.
- Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`?
- Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right?
This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1.
## Additional Information
NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax.
```
% ruby -ce 'expression in 42'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Syntax OK
```
NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit.
```
% ruby -e ruby -ce 'case expression; in 42; end'
Syntax OK
```
--
https://bugs.ruby-lang.org/
Issue #17925 has been updated by yui-knk (Kaneko Yuichiro).
It's possible https://github.com/yui-knk/ruby/tree/bugs_17925.
I think this is not limitaion but the matter of choice. Currently `expr` is expected after `case` therefore `expression in 42` is interpreted as `expr`.
For example
```ruby
case expression in 42
in true
in false
end
```
Before the change, this is interpreted as
```ruby
case (expression in 42)
in true
in false
end
```
After the change, this is interpreted as
```ruby
case expression
in 42
in true
in false
end
```
# Impact
## For `case ... in`
As shown above, this will change the behavior of current codes.
Before:
```ruby
expression = 42
case expression in 42
in true
p :t
in false
p :f
end
#=> :t
```
```ruby
expression = 421
case expression in 42
in true
p :t
in false
p :f
end
#=> :f
```
After:
```ruby
expression = 42
case expression in 42
in true
p :t
in false
p :f
end
#=> nothing printed, because body for 42 is empty
```
```ruby
expression = 421
case expression in 42
in true
p :t
in false
p :f
end
#=> 421 (NoMatchingPatternError)
# because nothing matches
```
## For `case ... when`
Before this change, this is valid
```ruby
case expression in 42
when true
p :t
when false
p :f
end
```
However after this change, it's invalid
```ruby
case expression in 42
when true
p :t
when false
p :f
end
# test2.rb:2: syntax error, unexpected `when' (SyntaxError)
# when true
# ^~~~
```
Impact on `case ... when` is inevitable because new grammar recognizes this is `case ... in` when third symbol (`in`) appears.
## New exception
`expr` appears other place of the grammar. For example, `if expr ...`, `while expr ...` and so on. This change introduces an exception that you can write one line pattern matching after `if`, `unless`, `while`, `until` and so on but you can't after `case`.
# Conclusion
* This a matter of choice not limitaion
* New grammar introduces incompatibility. It changes the behavior of `case ... in` and breaks `case ... when`
* It introduces an exceptional rule to the grammar
* As a reporter says, there is workaround to add `;` after `expression`
`expression in 42` always returns `true` or `false` therefore it might be useless for `case`. Howerver we need to consider such impacts and benefits before decision making.
# Note
Impact on `case ... when` can be found as Shift/Reduce conflict. In this state, shift derives `case ... when`, on the other hand reduce derives `case ... in`.
https://github.com/yui-knk/ruby/tree/bugs_17925_2
```
State 394
shift/reduce conflict on token "`in'":
60 expr0: arg •
71 expr: arg • "`in'" @7 @8 p_top_expr_body
First example: $@1 k_case arg • "`in'" @7 @8 p_top_expr_body opt_terms @19 case_body k_end "=>" @5 @6 p_top_expr_body opt_terms
Shift derivation
program
↳ 2: $@1 top_compstmt
↳ 3: top_stmts opt_terms
↳ 5: top_stmt
↳ 7: stmt
↳ 37: expr
↳ 68: arg "=>" @5 @6 p_top_expr_body
↳ 269: primary
↳ 358: k_case expr_value opt_terms @19 case_body k_end
↳ 78: expr
↳ 71: arg • "`in'" @7 @8 p_top_expr_body
Second example: $@1 k_case arg • opt_terms "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases k_end '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs opt_terms "end-of-input"
Reduce derivation
$accept
↳ 0: program "end-of-input"
↳ 2: $@1 top_compstmt
↳ 3: top_stmts opt_terms
↳ 5: top_stmt
↳ 7: stmt
↳ 32: command_asgn
↳ 41: primary_value '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs
↳ 377: primary
↳ 361: k_case expr_value0 opt_terms p_case_body k_end
↳ 77: expr0 ↳ 500: "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases
↳ 60: arg •
```
----------------------------------------
Bug #17925: Pattern matching syntax using semicolon one-line
https://bugs.ruby-lang.org/issues/17925#change-104453
* Author: koic (Koichi ITO)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
## Summary
There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior?
```console
% ruby -v
ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
% ruby -ce 'case expression when 42; end'
Syntax OK
% ruby -ce 'case expression in 42; end'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
-e:1: syntax error, unexpected `end', expecting `when'
case expression in 42; end
```
So, I have two concerns.
- Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`?
- Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right?
This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1.
## Additional Information
NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax.
```
% ruby -ce 'expression in 42'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Syntax OK
```
NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit.
```
% ruby -e ruby -ce 'case expression; in 42; end'
Syntax OK
```
--
https://bugs.ruby-lang.org/
Issue #17925 has been updated by kddnewton (Kevin Newton).
This is interesting. It surfaces and incompatibility we have. I didn't realize Ruby didn't allow this, so YARP allows `case expression in 42; end` to parse as expected by the OP here. If `parse.y` can't support this, I will need to explicitly disallow this in YARP.
----------------------------------------
Bug #17925: Pattern matching syntax using semicolon one-line
https://bugs.ruby-lang.org/issues/17925#change-104372
* Author: koic (Koichi ITO)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
## Summary
There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior?
```console
% ruby -v
ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
% ruby -ce 'case expression when 42; end'
Syntax OK
% ruby -ce 'case expression in 42; end'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
-e:1: syntax error, unexpected `end', expecting `when'
case expression in 42; end
```
So, I have two concerns.
- Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`?
- Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right?
This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1.
## Additional Information
NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax.
```
% ruby -ce 'expression in 42'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Syntax OK
```
NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit.
```
% ruby -e ruby -ce 'case expression; in 42; end'
Syntax OK
```
--
https://bugs.ruby-lang.org/
Issue #17925 has been updated by nobu (Nobuyoshi Nakada).
I thought it a trade-off.
To allow the statement, one-line pattern matching is not allowed there.
But it returns `true`/`false` only and may be useless for `case`.
----------------------------------------
Bug #17925: Pattern matching syntax using semicolon one-line
https://bugs.ruby-lang.org/issues/17925#change-104322
* Author: koic (Koichi ITO)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
## Summary
There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior?
```console
% ruby -v
ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
% ruby -ce 'case expression when 42; end'
Syntax OK
% ruby -ce 'case expression in 42; end'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
-e:1: syntax error, unexpected `end', expecting `when'
case expression in 42; end
```
So, I have two concerns.
- Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`?
- Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right?
This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1.
## Additional Information
NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax.
```
% ruby -ce 'expression in 42'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Syntax OK
```
NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit.
```
% ruby -e ruby -ce 'case expression; in 42; end'
Syntax OK
```
--
https://bugs.ruby-lang.org/