From: merch-redmine@... Date: 2019-03-27T23:04:54+00:00 Subject: [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: