[#97652] [Ruby master Feature#16746] Endless method definition — mame@...

Issue #16746 has been reported by mame (Yusuke Endoh).

24 messages 2020/04/01

[#97655] [Ruby master Misc#16747] Repository reorganization request — shyouhei@...

Issue #16747 has been reported by shyouhei (Shyouhei Urabe).

12 messages 2020/04/01

[#97745] [Ruby master Bug#16769] Struct.new(..., immutable: true) — takashikkbn@...

Issue #16769 has been reported by k0kubun (Takashi Kokubun).

10 messages 2020/04/08

[#97803] [Ruby master Misc#16775] DevelopersMeeting20200514Japan — mame@...

Issue #16775 has been reported by mame (Yusuke Endoh).

20 messages 2020/04/10

[#97810] [Ruby master Bug#16776] Regression in coverage library — deivid.rodriguez@...

Issue #16776 has been reported by deivid (David Rodr刕uez).

11 messages 2020/04/10

[#97828] [Ruby master Misc#16778] Should we stop vendoring default gems code? — deivid.rodriguez@...

Issue #16778 has been reported by deivid (David Rodr刕uez).

37 messages 2020/04/11

[#97878] [Ruby master Feature#16786] Light-weight scheduler for improved concurrency. — samuel@...

Issue #16786 has been reported by ioquatix (Samuel Williams).

72 messages 2020/04/14

[#97893] [Ruby master Bug#16787] [patch] allow Dir.home to work for non-login procs when $HOME not set — salewski@...

Issue #16787 has been reported by salewski (Alan Salewski).

18 messages 2020/04/15

[#97905] [Ruby master Feature#16791] Shortcuts for attributes of Process::Status — 0xfffffff0@...

Issue #16791 has been reported by 0x81000000 (/ /).

10 messages 2020/04/16

[#97907] [Ruby master Bug#16792] Make Mutex held per Fiber instead of per Thread — eregontp@...

Issue #16792 has been reported by Eregon (Benoit Daloze).

9 messages 2020/04/16

[#97989] [Ruby master Misc#16802] Prefer use of RHS assigment in documentation — samuel@...

Issue #16802 has been reported by ioquatix (Samuel Williams).

10 messages 2020/04/21

[#97992] [Ruby master Misc#16803] Discussion: those internal macros reside in public API headers — shyouhei@...

Issue #16803 has been reported by shyouhei (Shyouhei Urabe).

14 messages 2020/04/21

[#98026] [Ruby master Bug#16809] ruby testsuite fails on s390x alpine (musl) with --with-coroutine=copy — ncopa@...

Issue #16809 has been reported by ncopa (Natanael Copa).

11 messages 2020/04/23

[#98034] [Ruby master Feature#16812] Allow slicing arrays with ArithmeticSequence — zverok.offline@...

Issue #16812 has been reported by zverok (Victor Shepelev).

12 messages 2020/04/23

[#98044] [Ruby master Bug#16814] Segmentation fault in GC while running test/ruby/test_fiber.rb on s390x — Rei.Odaira@...

Issue #16814 has been reported by ReiOdaira (Rei Odaira).

14 messages 2020/04/24

[#98059] [Ruby master Bug#16816] Prematurely terminated Enumerator should stay terminated — headius@...

Issue #16816 has been reported by headius (Charles Nutter).

9 messages 2020/04/24

[#98066] [Ruby master Feature#16818] Rename `Range#%` to `Range#/` — sawadatsuyoshi@...

Issue #16818 has been reported by sawa (Tsuyoshi Sawada).

11 messages 2020/04/26

[ruby-core:97922] [Ruby master Feature#16670] Reverse order of `expression` in `pattern` for 1-line pattern matching while it's still experimental

From: daniel@...42.com
Date: 2020-04-16 14:07:26 UTC
List: ruby-core #97922
Issue #16670 has been updated by Dan0042 (Daniel DeLorme).


I think the `in` syntax and order feels natural when you're actually matching a pattern. It's not AI-like pattern recognition like "find a pattern _in_ this" but rather pattern correspondence like "is this _in_ the range expressed by this pattern".

But when using it only as destructuring assigment it does feel that something is off. Maybe it's because `expr in var` has the opposite order of `for var in expr`.

So rather than reversing the order, I'd like to propose `~|>` as a more natural-feeling alias for rightward destructuring assignment. Full proposal at #16794

----------------------------------------
Feature #16670: Reverse order of `expression` in `pattern` for 1-line pattern matching while it's still experimental
https://bugs.ruby-lang.org/issues/16670#change-85145

* Author: ttilberg (Tim Tilberg)
* Status: Open
* Priority: Normal
----------------------------------------
Currently the 1-line syntax for pattern matching is:

```
# Usage: <expression> in <pattern>

expression = {
  pattern: "Example"
}

expression in {pattern: something}
# something => "Example"
```

Is it technically possible, and desirable to switch the order of this syntax to:

```
# Usage: <pattern> in <expression>

expression = {
  pattern: "Example"
}

{pattern: something} in expression
# something => "Example"

```
?

Here are my reasons:

- It is more intuitive in English -- we are "finding a pattern in something". Finding "something in a pattern" doesn't seem to make sense.
- Assignment is happening, and this keeps assignment on the left side of the operator which feels more natural.
- It matches existing behavior with the workings of the case statement:

Understanding that a `case` block evaluates each `when` expression using `when_expression === case_expression` makes more consistency with `when_pattern in case_pattern` using the new operator.

```
case something
when /pattern/
end

# is equivalent to

/pattern/ === something

# This creates more parity with

case something
in {pattern: x}

# would be equivalent to

{pattern: x} in something
```


Please see the following discussion on Reddit: https://www.reddit.com/r/ruby/comments/favshb/27s_pattern_matching_official_docs_recently_merged/fj2c7ng/



-- 
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>

In This Thread