From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 9FD131F453 for ; Tue, 6 Nov 2018 01:21:37 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 1D98112164D; Tue, 6 Nov 2018 10:21:34 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 7C39312113B for ; Tue, 6 Nov 2018 10:21:31 +0900 (JST) Received: by filter0051p3las1.sendgrid.net with SMTP id filter0051p3las1-5444-5BE0EC97-2F 2018-11-06 01:21:28.047761031 +0000 UTC m=+442648.013858830 Received: from herokuapp.com (ec2-184-73-18-149.compute-1.amazonaws.com [184.73.18.149]) by ismtpd0002p1iad2.sendgrid.net (SG) with ESMTP id 4iS56dcmQB-JovNzYXJ2YA for ; Tue, 06 Nov 2018 01:21:27.989 +0000 (UTC) Date: Tue, 06 Nov 2018 01:21:28 +0000 (UTC) From: lyoneil.de.sire@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65101 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15236 X-Redmine-Issue-Author: ignatiusreza X-Redmine-Sender: ignatiusreza X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6tya74GVXnYeogDDUtoqrOFVOZt2SdPrgYNv 6NePjBK7K9eBRXWPEvw3OHSG6z3YJ64De9T4Wphd7HkonIGR/QxrOkn0m8hjiMyMdDj6xEIpnBAl2I ZbEU9wYtjUVr3P201uACghjM+DSxB/1Twm6nAHEktCBXCN0wus8Huu/hkg== X-ML-Name: ruby-core X-Mail-Count: 89716 Subject: [ruby-core:89716] [Ruby trunk Feature#15236] add support for hash shorthand 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15236 has been updated by ignatiusreza (Ignatius Reza Lesmana). blakewest (Blake West) wrote: > Hi all, > I've really wanted a feature like this for a long time. I find myself often using named arguments, which I love for the clarity. But then the callers often have variables of the same name as the parameter name, making it more verbose. eg. `foo(bar: bar, baz: baz)`. If one concern here is that `{a, b, c}` looks like set syntax, then I'd be curious to get opinions on a different syntax I had thought about for a while. The general idea is to extend the `%w` idea for hashes. For example, we could do `%h{foo bar baz}` which would expand into `{foo: foo, bar: bar, baz: baz}`. In both the "%w" and "%h" cases, we're allowing for a more concise version of an often used pattern. > I think the downside is using a `%h` syntax feels "separated" from the typical hash syntax. Using a straight `{a,b,c}` is "cleaner" as there are fewer characters, and may be more intuitive to some. > But similarly, I think that actually the upside of this syntax is it's more "separated". As Matz points out, the `{a,b,c}` syntax could look like set syntax, and as shevegen points out, it could be confusing for beginners. Neither of these problems would exist using %h, as it would pretty clearly be a "special" syntax, used by people who know what it's doing. Also, using `%h{}` would enable not having to use commas, which could make it even more compact > > I'll leave with a few more examples of what I'd be suggesting. > > ~~~ ruby > def foo(param1:, param2:) > param + param2 > end > > param1 = 7 > param2 = 42 > > foo(%h{param1 param2}) > > def respond_with(resource, options) > meta = extract_meta(resource, options) > etc = extract_etc(resource, options) > > %h{ resource meta etc } > end > > # destructuring could obviously be left for later. > %h{data meta etc} = {data: [1,2,3], meta: {mobile: true}, etc: "more info"} > ~~~ > > Thoughts? osyo (manga osyo) wrote: > hi, blakewest. > I proposaled it. > https://bugs.ruby-lang.org/issues/14973 > I need to consider an implementation that does not use `#eval`. I like this :+1: `{ a, b, c }` looks a bit cleaner to me, probably because of my familiarity with es6 syntax, so it require less context switching.. but if it is considered confusing to some, `%h{a b c}` also works for me.. ---------------------------------------- Feature #15236: add support for hash shorthand https://bugs.ruby-lang.org/issues/15236#change-74761 * Author: ignatiusreza (Ignatius Reza Lesmana) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- PR in github: https://github.com/ruby/ruby/pull/1990 inspired by javascript support for object literal shorthand notation `{ a }`, which will be expanded into `{ a: a }`.. to avoid ambiguity, this shorthand is only supported when hash is defined with `{ }` notation.. in other situation where the brackets is optional, e.g. function call, we still need to write it in full (`m(a : a)` instead of `m(a)`, or `m(a, b, c: c)` instead of `m(a, b, c)`.. -- https://bugs.ruby-lang.org/