From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MIME_HTML_MOSTLY,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 125FA20305 for ; Wed, 17 Apr 2019 12:31:41 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id B6BF9120946; Wed, 17 Apr 2019 21:31:34 +0900 (JST) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by neon.ruby-lang.org (Postfix) with ESMTPS id D0062120936 for ; Wed, 17 Apr 2019 21:31:27 +0900 (JST) Received: by mail-it1-f181.google.com with SMTP id q14so4256791itk.0 for ; Wed, 17 Apr 2019 05:31:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=otCmX8i6HtyAFB9qGAxfduYd0+VHEKFtkAKbFt700BY=; b=bEWHrR4EE4bGzRGarw/YyFzSS5oTmeVlNeusuKsgi04QSm941S9w9Hq7dGijSzdPj/ HcF2L3FRLg+QbbHCiWeVGjO7wTKUfo3n38BA7ahawgyUbVkJnSSJPeXtuCndwmMT9Xlr PuWbaU+Z+O5WBqWRQflgOAjkGQwJOr1A4iG7nJwTTP0+ncyQkZpMjVGqZRCAYtqH7/ui Wh3pdcuzn7eQoi9cqpBETJrswhiNhnVc74XfZ3RzHlaJ2gIeclj02XClW4vSalzaTW+W zXwM/xXtB13N5V2UZmuaweNk1jFDY95Gvoj1ZOwujJfvL2WbeC92gqaW96L0LcnPH/Ji NwOA== X-Gm-Message-State: APjAAAURjYh6FWqAH5DJAjk5ofLCMgUYIJwrhCVSvPpC0oyiBrk9boSn 0iK0L9hfe8QfWAmLay3Ym9CaYABptoZohDDrDtgWJlV0 X-Google-Smtp-Source: APXvYqwKtbMArDjPEIWXcw7SN4nP2zOGubjcSm7la1YeNk0FqEv0bKu4aYb1Iy9MKAwvCsDI2vxgB3JWSDwjsFMFHKc= X-Received: by 2002:a24:7a94:: with SMTP id a142mr34766791itc.79.1555504287338; Wed, 17 Apr 2019 05:31:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Waheed Al-Barghouthi Date: Wed, 17 Apr 2019 14:31:15 +0200 Message-ID: To: Ruby developers X-ML-Name: ruby-core X-Mail-Count: 92317 Subject: [ruby-core:92317] Re: [Ruby trunk Misc#15723] Reconsider numbered parameters X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1407522509==" Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Content-Transfer-Encoding: 7bit --===============1407522509== Content-Type: multipart/alternative; boundary="0000000000007e550e0586b9103a" --0000000000007e550e0586b9103a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's great news. It makes more sense for a single argument. `@` on its own should be enough. But why it can't be like this? `@[0]` I think its more clear :) On Wed, Apr 17, 2019 at 2:13 PM wrote: > Issue #15723 has been updated by jeremyevans0 (Jeremy Evans). > > > As I expressed in the developer meeting today, after a lot of thought, I > believe if we want to support implicit block arguments, we should limit > support to a single argument, and use `@` to represent the argument. > > As Marc showed, blocks that accept a single argument are much more popula= r > than blocks that accept more than one argument. For blocks that accept > multiple arguments, referencing the arguments by position rather than by > name will make the code less understandable, not more. > > Most of the objections with `@` in regards to syntax are because the > references look like instance variables, and most Rubyists do not know th= at > `@1` is not a valid instance variable. Using a bare `@` should avoid or = at > least mitigate that problem. I don't know if there is a sigil other than > `@` that will work. `\` worked for the case where you are using a positio= n > number, but it will not work without that, because then it can be > interpreted as a line continuation. `%` and similar sigils that are bina= ry > operators cannot be used because they will be interpreted as a binary > operator: > > ```ruby > proc do > foo % > bar > end > # parsed as proc{foo().%(bar())} > ``` > > ---------------------------------------- > Misc #15723: Reconsider numbered parameters > https://bugs.ruby-lang.org/issues/15723#change-77660 > > * Author: sos4nt (Stefan Sch=C3=BC=C3=9Fler) > * Status: Feedback > * Priority: Normal > * Assignee: > ---------------------------------------- > I just learned that *numbered parameters* have been merged into Ruby > 2.7.0dev. > > For readers not familiar with this feature: it allows you to reference > block arguments solely by their *index*, e.g. > > ```ruby > [1, 2, 3].each { |i| puts i } > > # can become > > [1, 2, 3].each { puts @1 } > ``` > > I have an issue with this new feature: I think **it encourages sloppy > programming** and results in **hard to read code**. > > --- > > The [original proposal](https://bugs.ruby-lang.org/issues/4475) was to > include a special variable (or keyword) with a **readable name**, somethi= ng > like: > > ```ruby > [1, 2, 3].each { puts it } > > # or > > [1, 2, 3].each { puts this } > ``` > > Granted, that looks quite lovely and it actually speaks to me =E2=80=93 I= can > *understand* the code. And it fits Ruby: (quoting the website) > > > [Ruby] has an elegant syntax that is natural to read and easy to write. > > But the proposed `it` / `this` has limited application. It's only useful > when dealing with a single argument. You can't have multiple `it`-s or > `this`-es. That's why `@1`, `@2`, `@3` etc. were chosen instead. > > However, limiting the usefulness to a single argument isn't bad at at. In > fact, a single argument seem to be the limit of what makes sense: > ``` > h =3D Hash.new { |hash, key| hash[key] =3D "Go Fish: #{key}" } > > # vs > > h =3D Hash.new { @1[@2] =3D "Go Fish: #{@2}" } > ``` > Who wants to read the latter? That looks like an archaic bash program (no > offense). We already discourage Perl style `$`-references: (from [The Rub= y > Style Guide]( > https://github.com/rubocop-hq/ruby-style-guide#no-perl-regexp-last-matche= rs > )) > > > Don't use the cryptic Perl-legacy variables denoting last regexp group > matches (`$1`, `$2`, etc). Use `Regexp.last_match(n)` instead. > > I don't see how our code can benefit from adding `@1` and `@2`. > > Naming a parameter isn't useless =E2=80=93 it gives context. With more th= an one > parameter, naming is crucial. And yes, naming is hard. But avoiding prope= r > naming by using indices is the wrong way. > > So please reconsider numbered parameters. > > Use a readable named variable (or keyword) to refer to the first argument > or ditch the feature entirely. > > > > -- > https://bugs.ruby-lang.org/ > > Unsubscribe: > > --0000000000007e550e0586b9103a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's great news. It makes more sense for a sing= le argument. `@` on its own should be enough. But why it can't be like = this? `@[0]` I think its more clear :)

=C2=A0
On We= d, Apr 17, 2019 at 2:13 PM <merch-redmine@jeremyevans.net> wrote:
Issue #15723 has been updated by jeremyev= ans0 (Jeremy Evans).


As I expressed in the developer meeting today, after a lot of thought, I be= lieve if we want to support implicit block arguments, we should limit suppo= rt to a single argument, and use `@` to represent the argument.

As Marc showed, blocks that accept a single argument are much more popular = than blocks that accept more than one argument.=C2=A0 For blocks that accep= t multiple arguments, referencing the arguments by position rather than by = name will make the code less understandable, not more.

Most of the objections with `@` in regards to syntax are because the refere= nces look like instance variables, and most Rubyists do not know that `@1` = is not a valid instance variable.=C2=A0 Using a bare `@` should avoid or at= least mitigate that problem.=C2=A0 I don't know if there is a sigil ot= her than `@` that will work. `\` worked for the case where you are using a = position number, but it will not work without that, because then it can be = interpreted as a line continuation.=C2=A0 `%` and similar sigils that are b= inary operators cannot be used because they will be interpreted as a binary= operator:

```ruby
proc do
=C2=A0 foo %
=C2=A0 bar
end
# parsed as proc{foo().%(bar())}
```

----------------------------------------
Misc #15723: Reconsider numbered parameters
https://bugs.ruby-lang.org/issues/15723#change-7= 7660

* Author: sos4nt (Stefan Sch=C3=BC=C3=9Fler)
* Status: Feedback
* Priority: Normal
* Assignee:
----------------------------------------
I just learned that *numbered parameters* have been merged into Ruby 2.7.0d= ev.

For readers not familiar with this feature: it allows you to reference bloc= k arguments solely by their *index*, e.g.

```ruby
[1, 2, 3].each { |i| puts i }

# can become

[1, 2, 3].each { puts @1 }
```

I have an issue with this new feature: I think **it encourages sloppy progr= amming** and results in **hard to read code**.

---

The [original proposal](https://bugs.ruby-lang.org/issues/4475= ) was to include a special variable (or keyword) with a **readable name= **, something like:

```ruby
[1, 2, 3].each { puts it }

# or

[1, 2, 3].each { puts this }
```

Granted, that looks quite lovely and it actually speaks to me =E2=80=93 I c= an *understand* the code. And it fits Ruby: (quoting the website)

> [Ruby] has an elegant syntax that is natural to read and easy to write= .

But the proposed `it` / `this` has limited application. It's only usefu= l when dealing with a single argument. You can't have multiple `it`-s o= r `this`-es. That's why `@1`, `@2`, `@3` etc. were chosen instead.

However, limiting the usefulness to a single argument isn't bad at at. = In fact, a single argument seem to be the limit of what makes sense:
```
h =3D Hash.new { |hash, key| hash[key] =3D "Go Fish: #{key}" }
# vs

h =3D Hash.new { @1[@2] =3D "Go Fish: #{@2}" }
```
Who wants to read the latter? That looks like an archaic bash program (no o= ffense). We already discourage Perl style `$`-references: (from [The Ruby S= tyle Guide](https://githu= b.com/rubocop-hq/ruby-style-guide#no-perl-regexp-last-matchers))

> Don't use the cryptic Perl-legacy variables denoting last regexp g= roup matches (`$1`, `$2`, etc). Use `Regexp.last_match(n)` instead.

I don't see how our code can benefit from adding `@1` and `@2`.

Naming a parameter isn't useless =E2=80=93 it gives context. With more = than one parameter, naming is crucial. And yes, naming is hard. But avoidin= g proper naming by using indices is the wrong way.

So please reconsider numbered parameters.

Use a readable named variable (or keyword) to refer to the first argument o= r ditch the feature entirely.



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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=3Dunsubscribe= >
<http://lists.ruby-lang.org/cgi-bin/m= ailman/options/ruby-core>
--0000000000007e550e0586b9103a-- --===============1407522509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1407522509==--