[#101179] Spectre Mitigations — Amel <amel.smajic@...>
Hi there!
5 messages
2020/12/01
[#101180] Re: Spectre Mitigations
— Chris Seaton <chris@...>
2020/12/01
I wouldn’t recommend using Ruby to run in-process untrusted code in the first place. Are people doing that?
[#101694] Ruby 3.0.0 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 3.0.0. From 2015 we
4 messages
2020/12/25
[ruby-core:101262] [Ruby master Feature#17371] Reintroduce `expr in pat`
From:
kazuki@...
Date:
2020-12-06 14:54:34 UTC
List:
ruby-core #101262
Issue #17371 has been reported by ktsj (Kazuki Tsujimoto). ---------------------------------------- Feature #17371: Reintroduce `expr in pat` https://bugs.ruby-lang.org/issues/17371 * Author: ktsj (Kazuki Tsujimoto) * Status: Open * Priority: Normal ---------------------------------------- How about reintroducing `expr in pat`, as akr-san proposed in DevelopersMeeting20201026Japan. The difference between `expr => pat` and new `expr in pat` is the return value of the expression. ``` # expr => pat 0 => a #=> void (succeeded) 0 => 1 #=> NoMatchingPatternError (failed) # expr in pat 0 in a #=> true (succeeded) 0 in 1 #=> false (failed) ``` Motivation and use cases are described at [Feature #15865]. I pointed out that there is a concern that in this specification a user might overlook the pattern did not match, and changed the return value at [Feature #16355]. However, now we already have new "rightward assignment style" pattern matching syntax, so we can say that this problem is solved. If `expr in pat` is accepted, I also propose that the return value of `expr => pat` on a successful match be the left-hand side value. Because, in this case, it becomes more clear that the use of `expr => pat` is assignment. -- 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>