[ruby-core:116565] [Ruby master Feature#20235] Deprecate CHAR syntax
Issue #20235 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by rubyFeedback (robert heiler). I think the first time - and probably the only time - I heard about the ?a syntax: ?a # => "a" ?b # => "b" ?c # => "c" was in the pickaxe book. I believe there was a chapter in the bookaxe that mentioned the ? syntax along with .chr and .ord, or something like that. I don't recall ever having used that syntax again in like 15 years ago, so from that point of view I agree with Dan0042. Then again I don't know all possible use cases, but provided there are no substantial use cases then Dan0042 may have a point. p $stdin.closed?=>true leads to an error whereas p $stdin.closed? =>true does not lead to an error. Although perhaps the parser could differentiate between these two use cases; but the basic question is still how useful ?a and how popular it may still be. Perhaps there is some way to find out how often ruby users use the ?char syntax? I can not recall any gem using it actually. ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106584 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by shan (Shannon Skipper). A `$stdin.closed?#=>true` would work as expected. You can't generally follow Ruby code immediately with an uncommented `=>` designating a return value and have it not break. It made sense to maintain character literals for compatibility between Ruby 1.8 and 1.9, since String#[] and the character literal both returned an ordinal. So with `string = 'a'` a `string[0]` would be `97` like an `?a` literal. In the time where Ruby 1.8 and Ruby 1.9 were both a thing, using character literals was strongly discouraged in Ruby 1.9 due to a likely incompatibility with 1.8. Now that 1.8 is long gone, a character literal is now once again perfectly safe. What I question is whether we should resume using character literals, since they're now fine to use, or whether their continued existence was purely for 1.8 compat and they should be deprecated and retired. It would be really nice to document which is the case. ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106585 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by Dan0042 (Daniel DeLorme). @shan it's not "an uncommented `=>` designating a return value", it's (supposed to be) a hash literal like `p 1=>2`. With spaces maybe it's more obvious: `p $stdin.closed? => true` In ruby 1.8 character literals were useful for things like `"hello"[1] == ?e`. But nowadays there's not a single reason to use `?e` instead of `"e"`. ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106590 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by shan (Shannon Skipper). Dan0042 (Daniel DeLorme) wrote in #note-3:
@shan it's not "an uncommented `=>` designating a return value", it's (supposed to be) a hash literal like `p 1=>2`. With spaces maybe it's more obvious: `p $stdin.closed? => true`
Ah, I misunderstood the intention but should have caught on with the second "does not lead to an error."
In ruby 1.8 character literals were useful for things like `"hello"[1] == ?e`. But nowadays there's not a single reason to use `?e` instead of `"e"`.
Yeah, agree on their use in 1.8 and why they were carried forward in 1.9 for compatibility. On the other hand, a `?e` or `?\n` can look crisp compared to a `'e'` or `"\n"`, make it clear to the reader on quick glance that it's a single character. Since some folk still use them for stylistic reasons there would be some compatibility issues removing them. If they were *only* kept for 1.8 compatibility it might be nice to document that and deprecate them now that 1.8 compatibility is a moot point. On the other hand, TIMTOWTDI and with no worry about Ruby 1.8 anymore so they could just be embraced as a safe and predictable alternative to String literals for single characters. I'm curious if Matz intends them to continue to be used and be a future part of the language or would discourage all modern usage? ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106591 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by nobu (Nobuyoshi Nakada). Maybe want to parse `closed?=>true` as `(closed?)=>true`? If only it is, `?c` syntax doesn't feel to need to be removed. ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106605 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by mame (Yusuke Endoh). Currently, `!` and `?` are interpreted as a part of the method name unless they are followed by `=`. This trick is needed to interpret `foo!=bar` as `foo != bar`, not a method name `foo!`. I think this trick is not needed very much for `?`, so we may relax the condition to allow `?` followed by `=` as a method name. The following patch will solve the original issue. ```diff diff --git a/parse.y b/parse.y index 6836576d80..4db724a289 100644 --- a/parse.y +++ b/parse.y @@ -10657,7 +10657,7 @@ parse_ident(struct parser_params *p, int c, int cmd_state) if (tokadd_mbchar(p, c) == -1) return 0; c = nextc(p); } while (parser_is_identchar(p)); - if ((c == '!' || c == '?') && !peek(p, '=')) { + if ((c == '!' && !peek(p, '=')) || c == '?') { result = tFID; tokadd(p, c); } ``` However, note that the following code would still violate the OP's expectation. ```ruby p $stdin.raw!=>true ``` ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106606 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
Issue #20235 has been updated by Dan0042 (Daniel DeLorme). I agree, it would be good to fix the parsing. At least that's as a bugfix that can be done now. In the long term I think warning about char literals would also be a good thing. Because I stumbled on a problem with `p $stdin.closed?=>true` its make me a bit paranoid about what other problems might be there because of char literals, hidden? Regarding `p $stdin.raw!=>true` that's not related to char literals but I think it should be fixed also. Maybe: ```diff diff --git a/parse.y b/parse.y --- a/parse.y +++ b/parse.y @@ -10657,7 +10657,7 @@ parse_ident(struct parser_params *p, int c, int cmd_state) if (tokadd_mbchar(p, c) == -1) return 0; c = nextc(p); } while (parser_is_identchar(p)); - if ((c == '!' || c == '?') && !peek(p, '=')) { + if (c == '?' || (c == '!' && (!peek(p, '=') || peek_n(p, '>', 1) || peek_n(p, '=', 1) || peek_n(p, '~', 1)))) { result = tFID; tokadd(p, c); } ``` ---------------------------------------- Feature #20235: Deprecate CHAR syntax https://bugs.ruby-lang.org/issues/20235#change-106618 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- I propose deprecating the `?c` syntax. It served a purpose in ruby <= 1.8, but no longer. The reason I'm proposing this is because today I ran into this error: ```ruby p $stdin.closed?=>true # comparison of String with true failed (ArgumentError) ``` I was completed mystified, and had to resort to Ripper to figure out what's going on ``` p *Ripper.lex("p $stdin.closed?=>true") [[1, 0], :on_ident, "p", CMDARG] [[1, 1], :on_sp, " ", CMDARG] [[1, 2], :on_gvar, "$stdin", END] [[1, 8], :on_period, ".", DOT] [[1, 9], :on_ident, "closed", ARG] [[1, 15], :on_CHAR, "?=", END] #OOOOHH!!!!! [[1, 17], :on_op, ">", BEG] [[1, 18], :on_kw, "true", END] ``` We don't have to commit to a removal schedule right now, but I think it would at least be good to print a deprecation message if $VERBOSE. -- https://bugs.ruby-lang.org/
participants (5)
-
Dan0042 (Daniel DeLorme) -
mame (Yusuke Endoh)
-
nobu (Nobuyoshi Nakada)
-
rubyFeedback (robert heiler)
-
shan (Shannon Skipper)