From: localhostdotdev@... Date: 2019-03-28T11:55:00+00:00 Subject: [ruby-core:92034] [Ruby trunk Bug#15732] Strict mode Issue #15732 has been updated by localhostdotdev (localhost .dev). So, the main thing I was thinking about is passing blocks that then get silently ignored. I was thinking a good way to solve this would be to have a strict mode, and then I tried to come up with things that could be in a strict mode too. The blocks not being used issues is already being discussed and worked on (but I wasn't aware of that). - About $1, $2, etc. I'm not a fan of global variables that any random piece of code can change, e.g. you do a =~ then a gem does a =~ and now your $1, $2, ... are randomly filled. - I'm aware I can use monkey patching to solve most issues - I meant using a(begin:, end:, for:) but actually the alternative (args as a hash) would then let the caller use any parameter name, so not in favor of that anymore - And yes using `def user(user); user.to_s; end` is quite confusing to the reader but this is the kind of things linters are for so that's fine (also should have re-read my original message, there is a few typos there) Anyway, the main thing was about silently ignoring ruby blocks, so I'm okay for this issue to be closed. Thinking about this, most of these issues are solved by linters already. ---------------------------------------- Bug #15732: Strict mode https://bugs.ruby-lang.org/issues/15732#change-77358 * 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: