https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112019-05-14T08:13:58ZRuby Issue Tracking SystemRuby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780062019-05-14T08:13:58Zsawa (Tsuyoshi Sawada)
<ul></ul><p>Why do the parentheses indicate that assignment is intended, and not comparison?</p> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780072019-05-14T09:08:12Zsos4nt (Stefan Schüßler)mail@stefanschuessler.de
<ul></ul><p>sawa (Tsuyoshi Sawada) wrote:</p>
<blockquote>
<p>Why do the parentheses indicate that assignment is intended, and not comparison?</p>
</blockquote>
<p>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.</p> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780082019-05-14T09:43:16Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>Personally I tend to try to avoid assignment-styles in if-clauses, but I do have to admit that<br>
I am also using it rarely. But in general I try to just write code that is simple to read at<br>
all times instantly and I am fine with breaking down statements into more lines. I also know of<br>
other ruby users trying to write just about everything into a single line using as few characters<br>
as possible. But anyway, I guess this is individual preferences differing between people, so on<br>
to the proposal.</p>
<p>Stefan wrote:</p>
<blockquote>
<p>And it's unfortunate that we can't make use of conditional assignments without getting warnings<br>
or turning off warnings.</p>
</blockquote>
<p>This taps into something that I think was mentioned before. I think I mentioned it too but I<br>
saw it in other discussions, e. g. how much control one may have over any warning.</p>
<p>It is possible to silence warnings within code too, e. g. using $VERBOSE, although that is not<br>
super-elegant in my opinion, but I use it myself too. I think the primary reason or objective<br>
for warnings is to indicate about code that may be problematic, so I assume the major reason<br>
for warnings is to help the developer at hand. This is good, but not all warnings are always<br>
great, at all times. Some more fine-tuned control may be useful. So coming from this point<br>
of view, I agree with the statement in the sense that I think ruby users should have more<br>
control over it. I am not sure how to best implement this though ... I compared it a bit to<br>
refinements, e. g. be able to say something like "ruby, ignore all warnings in this file<br>
related to if-clauses" or something like that. This could perhaps be implemented in she<br>
extended shebang-header, similar to frozen strings; or could be some other method call or<br>
something like that, a bit similar to refinements (although I do not use refinements myself,<br>
even though I think they are a great idea; the syntax confuses me). I have not really come<br>
up with a really good idea though. :\</p>
<p>But I agree with that statement in general, even if not necessarily with the functionality<br>
itself here (I am neutral on the suggestion example per se, that is don't really have any<br>
strong pro or con opinion; but I agree on the more general sentiment "more fine-tuned<br>
control over warnings").</p>
<blockquote>
<p>It would also allow the documentation to contain a warning-free example.</p>
</blockquote>
<p>I guess that is fine; perhaps when the documentation was written that warning was not<br>
there? Not sure, just trying to give examples; I guess ruby changed a little over the<br>
years.</p>
<p>sawa makes a good point nonetheless IMO. I think this is then really a lot to the<br>
individual preference of the ruby user at hand; the warning assumes one situation, which<br>
I think may be accurate for most people but it could indeed be not the case for the ruby<br>
user at hand. See the example I gave elsewhere about removing initialize and then adding<br>
your own initialize, where there may be valid examples where the warning would not be<br>
necessary; and valid examples where the warning would be useful.</p>
<p>I think another good example could be the did-you-mean gem. I have not tried to uninstall<br>
it but if you uninstall it, and run ruby code with a condition that could trigger its<br>
warning, then you sort of have a "toggle" system here, which I think is a bit related<br>
to show the example - e. g. the did-you-mean gem is useful in many situations but it<br>
may not always be useful or always be that useful to everyone, so by "uninstalling" they<br>
kind of have a slight toggle (aka use/not use it; I myself use it all the time even<br>
though the hint is not always useful, but I found it to be overly more useful to use<br>
it, as opposed to not use it).</p>
<blockquote>
<p>It's a convention used in C compilers. The explicit optional parentheses are seen as<br>
a hint that this is what the developer actually wants.</p>
</blockquote>
<p>I don't think you have to bring in the example of any other language; I am also not sure<br>
if it would fit, since languages are different. In my opinion the most compelling argument<br>
would be to see the case where a ruby user really would want to do something, and already<br>
knows that he/she wants to do so - in these cases, which may be a lot due to the individual<br>
style/preference, the warning at hand may indeed not be overly useful.</p>
<p>I think ultimately this is up how matz wants to view warnings in general, how fine-tuned<br>
the control should be (after all, more fine-tuned control would be nice but it can also<br>
mean adding more complexity, so there may always be trade-offs; and of course, to actually<br>
know what/how to implement too).</p>
<p>I can't think of a simple way to controls warnings though :( - I guess if we may have some<br>
simple way, somewhat similar to frozen-string literals true/false, that could solve quite<br>
a bit in this regard. We have some toggles, such as using -w or not using -w in .rb files;<br>
I use -w all the time (got used to it too much; I find -w very useful, even though some<br>
warnings are not so useful or even not good in all situations).</p> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780092019-05-14T10:35:52Zsos4nt (Stefan Schüßler)mail@stefanschuessler.de
<ul></ul><p>shevegen (Robert A. Heiler) wrote:</p>
<blockquote>
<p>I can't think of a simple way to controls warnings though :( - I guess if we may have some<br>
simple way, somewhat similar to frozen-string literals true/false, that could solve quite<br>
a bit in this regard.</p>
</blockquote>
<p>A per-file setting is too broad. Given:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">if</span> <span class="p">(</span><span class="n">a</span> <span class="o">=</span> <span class="n">foo</span><span class="p">)</span>
<span class="n">do_this</span> <span class="k">if</span> <span class="n">a</span> <span class="o">==</span> <span class="n">x</span>
<span class="n">do_that</span> <span class="k">if</span> <span class="n">a</span> <span class="o">=</span> <span class="n">y</span>
<span class="k">end</span>
</code></pre>
<p>I wanted Ruby to still warn me on the <code>a = y</code> part.</p> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780132019-05-15T06:49:30Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>sos4nt (Stefan Schüßler) wrote:</p>
<blockquote>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">if</span> <span class="n">a</span> <span class="o">=</span> <span class="n">object</span><span class="p">.</span><span class="nf">some_value</span>
<span class="c1"># do something to a</span>
<span class="k">end</span>
</code></pre>
<p>Running that code however results in a warning:</p>
<blockquote>
<p>warning: found = in conditional, should be ==</p>
</blockquote>
</blockquote>
<p>No, it doesn't.<br>
That warning is only when the RHS is a literal, but a method call doesn't cause the warning.</p> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780142019-05-15T07:00:20Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Is duplicate of</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/14562">Bug #14562</a>: Do not warn for assignment in conditionals inside ()</i> added</li></ul> Ruby master - Feature #15848: Silence warning when conditional assignments are wrapped in parentheseshttps://redmine.ruby-lang.org/issues/15848?journal_id=780162019-05-15T08:26:44Zsos4nt (Stefan Schüßler)mail@stefanschuessler.de
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>No, it doesn't.<br>
That warning is only when the RHS is a literal, but a method call doesn't cause the warning.</p>
</blockquote>
<p>It didn't occur to me the warning is aware of that. I should have tested with the actual example code. Thanks for the clarification nobu!</p>
<p>And thanks for closing it as a duplicate, I searched for one before posting but couldn't find any. (probably because it was already closed)</p>