Feature #15848: Silence warning when conditional assignments are wrapped in parentheses

• Status: Rejected
• Assignee: -
• Target version: -

[sos4nt (Stefan Schüßler)]

Sometime it's convenient to have an assignment in an if-condition. The Ruby 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#label-if+Expression

if a = object.some_value
  # do something to a
end

Running that code however results in a warning:

warning: found = in conditional, should be ==

It's very unfortunate that the Ruby docs contain example code that the parser complains about. And it's unfortunate that we can't make use of conditional 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.

if a = object.some_value
  # warning
end

if (a = 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.

[sawa (Tsuyoshi Sawada)]

Why do the parentheses indicate that assignment is intended, and not comparison?

[sos4nt (Stefan Schüßler)]

sawa (Tsuyoshi Sawada) wrote:

Why do the parentheses indicate that assignment is intended, and not comparison?

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.

[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 lines. I also know of
other ruby users trying to write just about everything into a single line using as few characters
as possible. But anyway, I guess this is individual preferences differing between people, so on
to the proposal.

Stefan wrote:

And it's unfortunate that we can't make use of conditional assignments without getting warnings
or turning off warnings.

This taps into something that I think was mentioned before. I think I mentioned it too but I
saw it in other discussions, e. g. how much control one may have over any warning.

It is possible to silence warnings within code too, e. g. using $VERBOSE, although that is not
super-elegant in my opinion, but I use it myself too. I think the primary reason 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 warnings 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 should have more
control over it. I am not sure how to best implement this though ... I compared 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 implemented 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 refinements 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 the functionality
itself here (I am neutral on the suggestion example per se, that is don't really 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 warning was not
there? Not sure, just trying to give examples; I guess ruby changed a little 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 situation, 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 and then adding
your own initialize, where there may be valid examples where the warning would 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 tried to uninstall
it but if you uninstall it, and run ruby code with a condition that could trigger its
warning, then you sort of have a "toggle" system here, which I think is a bit related
to show the example - e. g. the did-you-mean gem is useful in many situations but it
may not always be useful or always be that useful to everyone, so by "uninstalling" they
kind of have a slight toggle (aka use/not use it; I myself use it all the time even
though the hint is not always useful, but I found it to be overly more useful 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 compelling argument
would be to see the case where a ruby user really would want to do something, and already
knows that he/she wants to do so - in these cases, which may be a lot due to 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, how 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 course, to actually
know what/how to implement too).

I can't think of a simple way to controls warnings though :( - I guess if we may have some
simple way, somewhat similar to frozen-string literals true/false, that could 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).

[sos4nt (Stefan Schüßler)]

shevegen (Robert A. Heiler) wrote:

I can't think of a simple way to controls warnings though :( - I guess if we may have some
simple way, somewhat similar to frozen-string literals true/false, that could solve quite
a bit in this regard.

A per-file setting is too broad. Given:

if (a = foo)
  do_this if a == x
  do_that if a = y
end

I wanted Ruby to still warn me on the a = y part.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Rejected

sos4nt (Stefan Schüßler) wrote:

if a = object.some_value
  # do something to a
end

Running that code however results in a warning:

warning: found = in conditional, should be ==

No, it doesn't.
That warning is only when the RHS is a literal, but a method call doesn't cause the warning.

[nobu (Nobuyoshi Nakada)]

• Is duplicate of Bug #14562: Do not warn for assignment in conditionals inside () added

[sos4nt (Stefan Schüßler)]

nobu (Nobuyoshi Nakada) wrote:

No, it doesn't.
That warning is only when the RHS is a literal, but a method call doesn't cause the warning.

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!

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)