[ruby-core:92023] [Ruby trunk Bug#15732] Strict mode

Issue #15732 has been updated by jeremyevans0 (Jeremy Evans).


localhostdotdev (localhost .dev) wrote:
> A lot of issues could be easily prevented with a strict mode, for instance:
> 
> - Passing a block to a method that doesn't accept blocks could raise an exception, e.g. methods would be required to explicitly ask for a block (def a(..., &block))

This is being discussed in #15554.

> - $1, $2, etc. variables when matching with a regex would not be created

Not sure why these would be an issue (performance?).  You can use `String#match?` if you want to avoid it.

> - Could throw error when re-assigning constant

There is already a warning for this, is there a reason it would need to be an error? You can already turn it into an error:

```ruby
def Warning.warn(s)
  raise s if s.match?(/: warning: already initialized constant /)
  super
end
```

> And maybe more controversial:
> 
> - Using reversed keywords as argument names

Already a SyntaxError, assuming you meant method argument name:

```ruby
def x(begin)
end
```

Maybe you meant method name and not method argument name?  Sometimes the method name that makes the most sense is a reserved keyword.  Considering that there are core ruby classes that do this (`Range#begin`, `Range#end`), I'm not sure how this would work.

> - Using method name as argument name

Such as this?:

```ruby
def foo(foo)
  foo
end
```

I don't see this pattern used much, but it doesn't seem to cause a problem.  Any reason why you would want to disallow argument names that are the same, but not local variables that are the same?:

```ruby
def foo(bar)
  foo = bar
  foo
end
```

> - Using ambitious class/constant/method names (e.g. `class A; end; class B; class A; def me; A; end; end`

I'm guessing you meant ambiguous?  This actually isn't ambiguous, you just need to know how constant lookup is preformed.

> I'm sure there is more, using things rubocop does for instance: https://github.com/rubocop-hq/rubocop/blob/master/manual/cops.md
> 
> I could be implemented as a magic header, e.g. `# strict_mode: true`.

This proposed collection of behavior changes added by a strict mode seems mostly arbitrary to me.  And I don't think we want to add more magic headers if we can avoid it.  Some of these things happen at run time and not parse time, and a magic header doesn't work well for that.  For example:

a.rb:
```
# strict_mode: true
class B
  class A
    def me
      A
    end
  end
end
```

b.rb:
```
require_relative 'a'
A = B
A::A.me{|x| x}
```

Does this trigger an error for "ambiguous" constants, even though file `b.rb` doesn't use strict mode and when `a.rb` was parsed, the constant wasn't "ambiguous"?  How about for passing a block to the `me` method that doesn't accept a block?

----------------------------------------
Bug #15732: Strict mode
https://bugs.ruby-lang.org/issues/15732#change-77348

* Author: localhostdotdev (localhost .dev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
A lot of issues could be easily prevented with a strict mode, for instance:

- Passing a block to a method that doesn't accept blocks could raise an exception, e.g. methods would be required to explicitly ask for a block (def a(..., &block))
- $1, $2, etc. variables when matching with a regex would not be created
- Could throw error when re-assigning constant

And maybe more controversial:

- Using reversed keywords as argument names
- Using method name as argument name
- Using ambitious class/constant/method names (e.g. `class A; end; class B; class A; def me; A; end; end`

I'm sure there is more, using things rubocop does for instance: https://github.com/rubocop-hq/rubocop/blob/master/manual/cops.md

I could be implemented as a magic header, e.g. `# strict_mode: true`.

This is obviously a similar idea from Javascript's strict mode: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode



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

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>