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 shan (Shannon Skipper). Dan0042 (Daniel DeLorme) wrote in #note-3: Ah, I misunderstood the intention but should have caught on with the second "does not lead to an error." 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/