Project

General

Profile

Feature #14385

Deprecate back-tick for Ruby 3.

Added by hsbt (Hiroshi SHIBATA) about 1 year ago. Updated 4 months ago.

Status:
Open
Priority:
Normal
Target version:
-
[ruby-core:90291]

Description

From https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20171212Japan#From-attendees

Matz hopes to deprecate backtick syntax(``) for Ruby 3. We should warn about it at Ruby 2.6 (or 2.7?)

We need to consider them.

  • warning message
  • warning level
  • ?

Related issues

Related to Ruby trunk - Misc #12751: Incompatibility of Ruby 3OpenActions

History

Updated by shevegen (Robert A. Heiler) about 1 year ago

Thank you for the early notice - there are now lots of entries for the developer meeting
compared to a few days ago. Looking forward to the (more important) results of the
meeting. :)

I agree with the summary. It would be nice if we could "connect" all deprecation
issues together. The wiki for the developer meeting mentions three so far (%?,
backtick (`), -K) - if any more come up, it would be helpful if we could keep
track of them, in particular when later developer meetings also discuss other
deprecations.

The reason I mention this is because ruby hackers can look what may change in
ruby 3.0 eventually and keep this in mind when writing new code, e. g. write
some code in a way that makes it possible for them to more easily adapt their
code to the 3.x era.

Updated by Hanmac (Hans Mackowiak) about 1 year ago

would that affect %x{} too or whould that be done later?

i mean in most cases they might not what i want and need to use exec or popen

Updated by nobu (Nobuyoshi Nakada) about 1 year ago

%x{} will not change.
Matz's intention is to use back-ticks for a different syntax, not to deprecate the command substitution feature.

Updated by Hanmac (Hans Mackowiak) about 1 year ago

nobu (Nobuyoshi Nakada) wrote:

%x{} will not change.
Matz's intention is to use back-ticks for a different syntax, not to deprecate the command substitution feature.

i am okay with that, imo %x is most cases still not the right for me

is there already any info for what this syntax (`) might be used for?

Updated by nobu (Nobuyoshi Nakada) about 1 year ago

Hanmac (Hans Mackowiak) wrote:

is there already any info for what this syntax (`) might be used for?

I haven't heard it.

Updated by normalperson (Eric Wong) about 1 year ago

nobu@ruby-lang.org wrote:

Matz's intention is to use back-ticks for a different syntax,
not to deprecate the command substitution feature.

I think that is dangerous to have the meaning of any syntax element
become something else, even removing it entirely would be less bad.

I have some scripts which are not used for several years at a
time, so they may never be run during the 2.x cycle. Having
back-tick do something entirely different in 3.x can give a
false positive on success, that potentially causes data loss or
corruption.

False positives is worse than complete failure of a script.

That said, I see back-ticks are used improperly all the time.
For example, I would support adding warnings and suggestions to
use system() instead of being used in a void context. Dangerous
interpolation would be one use case for keeping taint, even.

Updated by Eregon (Benoit Daloze) about 1 year ago

IMHO this is way too incompatible and using %x{} only makes it less nice/readable/intuitive.
What's wrong with the very convenient backtick notation ?

#8

Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • Related to Misc #12751: Incompatibility of Ruby 3 added

Updated by shevegen (Robert A. Heiler) about 1 year ago

I see back-ticks are used improperly all the time.
For example, I would support adding warnings and suggestions to
use system() instead of being used in a void context. Dangerous
interpolation would be one use case for keeping taint, even.

I am not sure if this is a good approach. What if someone really
just prefers the shorter rather than system()? I mean, it is not
a problem for me since I use
only in context of assigning it to
a variable, and then when I inspect at the variable. For example,
today, I was parsing the result of exiftools for a .pdf file
in ruby.

It's always a trade off how chatty ruby should be with its warnings,
especially when you can not or do not want to make certain suggested
changes. For example, what rubocop tells me by default about my
ruby code I usually do not agree with at all. :-)

Updated by shevegen (Robert A. Heiler) about 1 year ago

I have recently read something which may be incorrect; but perhaps it may
be correct too, I do not know. The comment I read was sort of meant as a
joke perhaps ... or it was a first april joke. But it's not quite first
april so I should better ask early (before first april!).

I did read recently that one reason why backtick ` may be deprecated
(if it is to be deprecated) is because it may be used for something else
in ruby 3.x.

I do not know whether this is true or not so perhaps it is best to ask on
the bug tracker here, so that other ruby hackers know whether this is only
a rumour or whether it is more than a rumour.

  • May this potential change in regards to backticks, if it is to come, also imply a change to the use of '::' scoping or semantics?

The reason why I ask is primarily because, to me, visually, it may make a
huge difference, if this were to be the case. If, on the other hand, no
change is planned in regards to '::', then of course it is no problem at
all for me since I can keep on using '::' in ruby 3.x as well.

For example, when frozen strings were added, ruby hackers could (and still
can) use a "magic comment" to decide whether to use them in a given .rb
file or not. I make use of this a LOT and this was a good/neutral change
(for me) in the sense as I can decide (and control) which syntax to
prefer,

For example, these two syntax variants:

string = ''

versus

string = ''.dup

To me, visually, the first line is much cleaner than the second, so I prefer
it of course. What is good here is that the old variant still works fine
and I can specify this in the comment/post-shebang section on top of the
ruby file in question.

However had, I also understand performance improvements made to ruby and I am
using the second variant, with .dup, a lot as well - in particular in libraries
that may be re-used by lots of other projects. Or when a ruby project is fairly
large, then I often use frozen strings. Although I have not made use of
extensive benchmarking, I am reasonable certain that the speed gains through
frozen strings alone, were quite significant in the ruby code that I use.

I like having this flexibility a lot. I can pick cherries - or cake. Rather
than pick only cherries; or only a cake. :D

That is also why I am somewhat anxious about any change made to '::'. I do
not really mind losing Kernel backtick in the end, even though I like it and
use it a lot; but a change to '::' would impact me much more significantly.

Either way, I think staying informed about any change here may be interesting
to other ruby hackers as well, so thanks to all among the core team to keep
the ruby users informed. (I myself much prefer being informed early rather
than late, even if nothing has been finalised yet and everything is still
an idea only).

Updated by nrodriguez (Nicolas Rodriguez) 4 months ago

Eregon (Benoit Daloze) wrote:

IMHO this is way too incompatible and using %x{} only makes it less nice/readable/intuitive.
What's wrong with the very convenient backtick notation ?

You use the same symbol "`" for the begining and the end of the instruction which is not a good thing to do when you design a programming language as it creates ambiguities.
For example with this syntax you can't nest multiple calls.
In Bash $() is prefered over backticks for that reason.
How would you express such a call with backticks without ambiguities :

foo=$(echo $(whoami))
echo $foo

The example is trivial but I think you got the point ;)

Also available in: Atom PDF