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.1 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,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.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 9998B1F461 for ; Tue, 14 May 2019 09:43:25 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0828812092F; Tue, 14 May 2019 18:43:19 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 9BB331208CC for ; Tue, 14 May 2019 18:43:16 +0900 (JST) Received: by filter0135p3mdw1.sendgrid.net with SMTP id filter0135p3mdw1-5693-5CDA8DB5-A 2019-05-14 09:43:17.156991479 +0000 UTC m=+56600.732290527 Received: from herokuapp.com (unknown [52.72.240.185]) by ismtpd0053p1mdw1.sendgrid.net (SG) with ESMTP id R_tyw3O2QSadUYP66TFHpQ for ; Tue, 14 May 2019 09:43:17.035 +0000 (UTC) Date: Tue, 14 May 2019 09:43:17 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68128 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15848 X-Redmine-Issue-Author: sos4nt X-Redmine-Sender: shevegen 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: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0z8AlbdYT4yfVjS0oxFlT?= =?us-ascii?Q?DS0E=2F4R4JHh9XdnS4U3BinsaL=2FEwW5hjf0Vu+KU?= =?us-ascii?Q?75JeB91=2FWC5EtLbmWOjp=2F5o5wk2JX7w0gMIoxqt?= =?us-ascii?Q?H5wRh3rFvyvzMfdLQ6SrHqodOgathcLOkJiN2O=2F?= =?us-ascii?Q?vGOwJNS0674sOmY3SYZixaz2YncglruELRA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92645 Subject: [ruby-core:92645] [Ruby trunk Feature#15848] Silence warning when conditional assignments are wrapped in parentheses 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15848 has been updated by shevegen (Robert A. Heiler). Personally I tend to try to avoid assignment-styles in if-clauses, but I do= have to admit that I am also using it rarely. But in general I try to just write code that is = simple to read at all times instantly and I am fine with breaking down statements into more l= ines. I also know of other ruby users trying to write just about everything into a single line u= sing as few characters as possible. But anyway, I guess this is individual preferences differing b= etween people, so on to the proposal. Stefan wrote: > And it's unfortunate that we can't make use of conditional assignments wi= thout getting warnings > or turning off warnings. This taps into something that I think was mentioned before. I think I menti= oned it too but I = saw it in other discussions, e. g. how much control one may have over any w= arning. It is possible to silence warnings within code too, e. g. using $VERBOSE, a= lthough that is not super-elegant in my opinion, but I use it myself too. I think the primary r= eason or objective for warnings is to indicate about code that may be problematic, so I assume= the major reason for warnings is to help the developer at hand. This is good, but not all wa= rnings are always great, at all times. Some more fine-tuned control may be useful. So coming = from this point of view, I agree with the statement in the sense that I think ruby users sh= ould have more = control over it. I am not sure how to best implement this though ... I comp= ared it a bit to refinements, e. g. be able to say something like "ruby, ignore all warnings= in this file = related to if-clauses" or something like that. This could perhaps be implem= ented in she = extended shebang-header, similar to frozen strings; or could be some other = method call or something like that, a bit similar to refinements (although I do not use re= finements myself, even though I think they are a great idea; the syntax confuses me). I have = not really come up with a really good idea though. :\ But I agree with that statement in general, even if not necessarily with th= e functionality itself here (I am neutral on the suggestion example per se, that is don't r= eally have any strong pro or con opinion; but I agree on the more general sentiment "more = fine-tuned = control over warnings"). > It would also allow the documentation to contain a warning-free example. I guess that is fine; perhaps when the documentation was written that warni= ng was not there? Not sure, just trying to give examples; I guess ruby changed a littl= e over the years. sawa makes a good point nonetheless IMO. I think this is then really a lot = to the = individual preference of the ruby user at hand; the warning assumes one sit= uation, which I think may be accurate for most people but it could indeed be not the case= for the ruby user at hand. See the example I gave elsewhere about removing initialize an= d then adding your own initialize, where there may be valid examples where the warning wo= uld not be necessary; and valid examples where the warning would be useful. I think another good example could be the did-you-mean gem. I have not trie= d to uninstall it but if you uninstall it, and run ruby code with a condition that could t= rigger its warning, then you sort of have a "toggle" system here, which I think is a b= it related = to show the example - e. g. the did-you-mean gem is useful in many situatio= ns but it may not always be useful or always be that useful to everyone, so by "unins= talling" they kind of have a slight toggle (aka use/not use it; I myself use it all the t= ime even = though the hint is not always useful, but I found it to be overly more usef= ul to use it, as opposed to not use it). = > It's a convention used in C compilers. The explicit optional parentheses = are seen as > a hint that this is what the developer actually wants. I don't think you have to bring in the example of any other language; I am = also not sure if it would fit, since languages are different. In my opinion the most comp= elling argument would be to see the case where a ruby user really would want to do somethin= g, and already knows that he/she wants to do so - in these cases, which may be a lot due t= o the individual style/preference, the warning at hand may indeed not be overly useful. I think ultimately this is up how matz wants to view warnings in general, h= ow fine-tuned the control should be (after all, more fine-tuned control would be nice but= it can also mean adding more complexity, so there may always be trade-offs; and of cour= se, to actually know what/how to implement too). I can't think of a simple way to controls warnings though :( - I guess if w= e may have some simple way, somewhat similar to frozen-string literals true/false, that cou= ld solve quite a bit in this regard. We have some toggles, such as using -w or not using -= w in .rb files; I use -w all the time (got used to it too much; I find -w very useful, even= though some warnings are not so useful or even not good in all situations). ---------------------------------------- Feature #15848: Silence warning when conditional assignments are wrapped in= parentheses https://bugs.ruby-lang.org/issues/15848#change-78008 * Author: sos4nt (Stefan Sch=FC=DFler) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- Sometime it's convenient to have an assignment in an `if`-condition. The Ru= by documentation even contains an example showing this *"most common use of= side-effect"* practice: http://ruby-doc.org/core-2.6.3/doc/syntax/control_expressions_rdoc.html#lab= el-if+Expression ```ruby if a =3D object.some_value # do something to a end ``` Running that code however results in a warning: > warning: found =3D in conditional, should be =3D=3D It's very unfortunate that the Ruby docs contain example code that the pars= er complains about. And it's unfortunate that we can't make use of conditio= nal assignments without getting warnings or turning off warnings. I propose an obvious change to the current warning mechanism: **Don't show the warning when the assignment is wrapped in parentheses.** ```ruby if a =3D object.some_value # warning end if (a =3D object.some_value) # no warning end ``` This is the way RoboCop already works and it's also a known workaround from= other languages. It would also allow the documentation to contain a warning-free example. -- = https://bugs.ruby-lang.org/ Unsubscribe: