Issue #10661 has been updated by Myron Marston.


> You can use `rand()`.

Good point.  I'm so used to calling arg-less methods without parens that I didn't even think of that here!  I'll probably use that rather than renaming variables or `let` declarations in the 500+ warnings I'm fixing in the RSpec suites.

That said, I've always liked that Ruby supports the same syntax for local variables as for an arg-less message send to `self`.  Avdi's screencast on barewords explains how this can be helpful to be able to refactor from a local to a helper method:

http://devblog.avdi.org/2012/10/01/barewords

This is basically the entire idea of `let` in RSpec -- when you've got the duplication of creating the same named object in multiple specs as a local variable, you can extract that object definition into a `let` with the same name and not have to update the referencing syntax.  This new warning makes `let` much less usable for RSpec and Minitest::Spec users who run with warnings enabled, as they may get warnings when doing this refactoring if the same name is used by a local variable earlier in the file (which may be a different context that creates the collaborator object with different parameters or whatever).

> Any idea of less-strict form?

That's a hard one. Given that it is implemented in the parser, I don't see how it could know there is a method def and that it should therefore not warn.  I think this issue shows a weakness in Ruby's warning system: it's all or nothing.  This warning is helpful in some circumstances, but harmful in others (IMO) since it inhibits bareword refactorings, so it would be nice to be able to opt-out of this warning while still running with the rest of Ruby's warnings enabled.  Could the magic comment system (used to set a file's encoding) be used to opt-out of specific warnings?

If that's not feasible, my preference would be to see this removed, as I think being able to refactor between local variables and methods (such as RSpec's and Minitest's `let` system) is very useful and any warning that inhibits that is, IMO, harmful.  Plus, in almost 8 years of doing Ruby, I can't think of a single time I ever hit a situation where this warning would have helped me.

I can completely understand if you're not willing to remove this warning, though!

Thanks for being willing to engage on this so promptly.

----------------------------------------
Bug #10661: The "possible reference to past scope" warning is quite frustrating and is forcing me to change my variable names from what I want
https://bugs.ruby-lang.org/issues/10661#change-50656

* Author: Myron Marston
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin12.0]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
I find the change in r48986 to be quite frustrating.  It's forcing me to change many of my variable and/or method names if I want to keep my ruby code warning free (which is a thing we enforce in the RSpec code base).

The problem I see is that, in my experience, it's quite common to use the same name for a local variable in one part of a file that you later use for an arg-less method name at a later part in the file.

Consider this ruby command:

~~~
ruby -w -e '[1, 2, 3].sample.tap { |rand| puts "Random value: #{rand}" }; puts "Another random value: #{rand}"'
~~~

This produces:

~~~
-e:1: warning: possible reference to past scope - rand
Random value: 1
Another random value: 0.7483347748677992
~~~

Changing the `rand` call to `self.rand` is one solution I would consider to avoid the warning, but it doesn't work here because `rand` is `private` (as it comes from `Kernel`), so I'm forced to change the block local variable name to a name I do not want.

In RSpec it's an even bigger issue as it's quite common to have a common name for a certain collaborator role in your tests where in some cases there's a helper method (often defined using `let`) that exposes an object for that role and in other tests you might build it in-line and assign it to a local.  In our rspec-mocks test suite, we had 280 warnings from this.  I went through and changed many variable and method names to names I do not like as much (e.g. `the_dbl` instead of `dbl` or `klazz` instead of `klass`) simply to avoid this warning:

https://github.com/rspec/rspec-mocks/commit/3b909ed1a951bbca340ea98c27ab65da7f43881c

While I can understand the kinds of errors this warnings helps you avoid, I think that it is too strict and noisy in its current form.




-- 
https://bugs.ruby-lang.org/