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: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>