Project

General

Profile

Bug #13872

Duplicate assignment no longer silences "assigned but unused variable" warning

Added by segiddins (Samuel Giddins) 18 days ago. Updated 17 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.5.0dev (2017-09-04 trunk 59742) [x86_64-darwin16]
[ruby-core:82656]

Description

On ruby 2.4.1:

ruby -W -e 'def a; var = var = "foo"; end'

prints no warning

On ruby 2.5.0dev (2017-09-04 trunk 59742) [x86_64-darwin16]

ruby -W -e 'def a; var = var = "foo"; end'

prints warning -e:1: warning: assigned but unused variable - var

This feature was useful when the local binding would be passed to another scope (like to ERB), and those variables were only accessed via the binding

History

#1 [ruby-core:82679] Updated by ted (Ted Johansson) 17 days ago

Previously, foo = foo = "bar" was used as a workaround. Now that the workaround is "fixed", I see incoming PRs changing the workaround to foo = "bar"; foo = foo.

It would be nice if we had a way to handle these false positives directly, without having to resort to tricks. :-)

segiddins (Samuel Giddins) wrote:

On ruby 2.4.1:

ruby -W -e 'def a; var = var = "foo"; end'

prints no warning

On ruby 2.5.0dev (2017-09-04 trunk 59742) [x86_64-darwin16]

ruby -W -e 'def a; var = var = "foo"; end'

prints warning -e:1: warning: assigned but unused variable - var

This feature was useful when the local binding would be passed to another scope (like to ERB), and those variables were only accessed via the binding

#2 [ruby-core:82680] Updated by shevegen (Robert A. Heiler) 17 days ago

Well, the first could be solved if there is some way to also propagate (local) variables towards ERB
or other bindings. Like to have different binding "levels" available. Copy environments and stuff. :D
(Actually ... one could probably store stuff in ENV and have them then propagated? But admittedly that
is also another work around towards anyone just wanting to use local variables instead).

But I think that, to the topic at hand, there may also be cases where people may not have wanted
to do such assignments; could happen due to some quick copy/paste or so. So for these cases, I
think that the 2.5.x behaviour is better, though it also does not seem to distinguish between
same_name_variable = same_name_variable = 'something else' - the "did you mean" gem could also
ask a question such as "did you really mean to give the variable the same name again"? :-)

The "workaround" was probably never intended to be used or be meaningful; at the least I can
not think that matz would think that the above was ... well, revealing the intent.
(self-assignment of variables? By the way, I did not know this workaround), but I agree that
some people may have liked that workaround. Perhaps ruby core may consider if you could add
some alternative proposal without the double assignment?

I mean, if the major use case is in regards to bindings and local variables then perhaps some
other way to use/propagate variables like that could convince matz / the core team?

Also available in: Atom PDF