Issue #14277 has been updated by shevegen (Robert A. Heiler).


> I use the term "Ambiguity" to emphasise the grey area where ruby developers
> are using strings and symbols interchangeably without any concerns about
> the differences between the two types of objects.

This is a general problem.

I personally think that ruby would be simpler without ... Symbols. :)

But people have been using symbols and symbols were available so I guess
matz felt that symbols have a valid use case (speed, performance, lightweight
and so forth).

I personally like symbols. I use them very happily, most definitely in ways
others may not use. Like some_method(:ignore_the_cats) and handling these
cases within the method.

I also agree with Martin - while it is just a tiny difference, it is easier
to write :foo than 'foo'. It may not be of a primary concern, but I like
typing less.

And I agree as well with as to what Martin wrote that ultimately matz has
to decide whether to make a change or not concerning the usage
pattern/frequency of symbols. That also dates back to the pickaxe IMO -
the old pickaxe wrote that using symbols as keys in a hash is much better
aka faster or less memory use. But that was before frozen strings existed
by default, so I am not sure if this still applies or not ... lots of
knowledge becomes outdates.

By the way, I have no problem if

    alias_method "foo", "bar"

would become deprecated. I am not even using alias_method at all in the
first place, simply because I don't like it. Just like tenderlove is a
puts debugger, and I am a pp debugger, I am an "alias foo bar" person,
even though alias and alias_method are not completely the same. I love
typing less, usually. :D

I think Koichi Sasada referred to the amount of changes required, compared
to the amount of real gain, in the symbol-situation. Matz also gave a
presentation some time ago about good and bad changes. I have no problem
with change if the change makes something better or improves on parts of
ruby - speed increases (but I prefer pretty code over min-max speed),
did-you-mean gem, omitting require 'pp' and things like that. Some changes
are harder ones; encoding is not a real issue to me anymore, but it simply
is different compared to the ruby 1.8.x era. Requires me to think more
about string1 versus string2 that may have different, thus incompatible,
encodings. (The way I work around this in my own projects is by usually
specifying the main encoding to be used, in a constant; and then enforcing
that in my project. This may be optional if I would use Unicode instead
but I rarely do so, for reasons that take too long to explain. My main
point here is just the added amount of code that one may have to deal
with. Unicode at the least has emojis which I can't resist using; it is
also why I keep most of my larger projects flexible. If I want to switch
to unicode one day, I should be able to do so easily, by just changing
a single constant.) 

To some of your suggestions:

> Use current symbols syntax as yet another strings syntax and stop
> using Symbols?

As I wrote about above, I would not mind if symbols would not exist
in the first place, largely as it may make ruby simpler. So it is
not as if I would be completely opposed to your idea. BUT, since
I also really like Symbols, or primarily, the syntax it has, I also
don't really want to stop using them. If they are treated internally
like string objects or string-like objects, I possibly would not
mind really, simply because I could keep on using the syntax. But
I am also wary of change just for sake of change alone.

> Use current symbols syntax as yet another strings syntax and start
> use Symbols with a new syntax?

This sounds really awful - I hope you don't take it personal but 
this would probably be the worst of all suggestions. What would be
the net gain, just using a new syntax here? Would old code break
or require changes?

You also did not suggest an alternative syntax to that specifically.

What syntax would you propose to then use Symbols? Would :foo still
be available or would you remove it?

Syntax is also important. When I realized that @@foo is not really
needed because @foo works just fine on a "module-level instance"
(module Foo; @foo = 42; def self.foo?; @foo etc...) I stopped 
using @@foo, largely because the syntax was not appealing to me.

Unless one wants to use unicode for defining symbols, we do not
have that many characters to choose from.

> Use current symbols syntax as yet another strings syntax
> and use Symbols purely as a class?

Similar problem to the above.

Anyway, I don't want to discourage you since I understand that
this is probably harder to change compared to, say, 10 years
ago or so (change takes time too and we did not have frozen
strings back then). But to be honest, I do not really see any
real net advantage in the proposal alone here.

I think this is an area where matz has to decide either way since
it is somewhat more difficult, IMO, and only he knows how ruby
should be in the end.

I also agree that it could only be for ruby 3.x to change. ko1 
only gave one use case but I think there are more - in my code
I sometimes do "if object.is_a? Symbol" as opposed to whether
it is a String. Admittedly the code may be simpler if symbols 
would not exist in the first place - but since they do, and in
your examples symbols would still remain, I'd be hard pressed to
really want to have to lose symbols altogether.

There also have been some other issue requests where methods were
added to Symbols, so I really think that this is a large topic
altogether.

> As a ruby developer when I use an API I tend to expect that
> both strings and symbols are accepted since that has become
> the standard way of doing things in ruby land like the
> example highlights.

That depends on the API. To me it would be weird if an API rejects
a symbol input just because it is a symbol, if both strings and
symbols exist.

Would an API make sense if it distinguishes between 'cat' and :cat
alone? It sounds a lot more as an opinionated API aimed for purism
rather than practical use. I agree that people may spend time 
asking these questions (when to use symbols and when to use strings),
so I am not against saying to remove symbols altogether IF this 
would lead to a simpler language (if I could still use :foo) - but
if that is not done, then I'd also rather retain the way how ruby
uses both. It may not be as elegant or pure as compared to the
situation where we'd have no symbols, but I just do not see the 
net gain really.

> When an API doesn't met that expectation things get confusing.

It's simple for APIs to handle both symbols and strings.

I know that because I am using it in my code.

I do, however had, also agree that it would be simpler if ruby hackers
would not have to decide between either one. Less brain-power to
process. But it's hard to change at this moment in time IMO. So I am
somewhat against the proposal, even though I agree with it
somewhat. :)

> I believe I'm not the only one to have this mind map inferring from
> previous discussions.

This may well be but you can find opinions on either side of
string-versus-symbol discussion. :)

> Plus I believe that would kill ruby as a language. People
> would go away for good in my opinion because the chaos
> would be even worst.

This is not a good design goal.

People will always tend to use this or that language, for this or
that reason. With more choice comes more fragmentation in general.
And I very much doubt that the string-versus-symbol debate is why
people pick any other language. I also don't think that people often
act in a very logical manner - often they make a decision and then
just reason to support that decision no matter what.

It's how many people "work". ;) (Though that is not to say that
they may not have valid reasons for using other languages. Speed
issue is one I may tend to agree with IF it is important to
someone).

There is simply more competition these days IMO. You can also see
it in perl; but even PHP has lost grounds in the last ~6 years,
largely due to javascript alone IMO.

> Now if we accept both syntaxes in the same way and treat them
> always as strings we would remove all the extra work we are
> having currently to handle the existing differences.

This may be one approach but you also wrote above in two of your
three examples that the syntax may change or a new syntax may
be added; or that symbols may still be available, just with another
syntax. So I am confused now. Which variant do we prefer or talk
about now?

Also note that new syntax for symbols creates new/more complexity
as well. Better to not have symbols at all in this case ;) - but
as long as they exist, I like the way as it is largely because 
it has been that way for a really long time.

> Wouldn't you be able to use Symbols and the same logic with
> solutions 2. or 3. in place?

But your solution requires changes there still, right?

I am not entirely sure where the real net gain is, unless you
refer to the case where there would not be any new syntax for
symbols.

----------------------------------------
Feature #14277: Improve strings vs symbols ambiguity
https://bugs.ruby-lang.org/issues/14277#change-69155

* Author: dsferreira (Daniel Ferreira)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
This is the ambiguity:

```ruby
alias_method :foo, :bar
alias_method "foo", "bar"
```

Ruby developers are using strings and symbols interchangeably as if they were the same thing.
This is happening in ruby core, in ruby gems and in ruby applications.

---

This discussion as started 5 years ago in two separate feature requests (both rejected): 
* [5964](https://bugs.ruby-lang.org/issues/5964)
* [7792](https://bugs.ruby-lang.org/issues/7792)

I believe ruby will be much better once the ambiguity between strings and symbols is resolved for good
and ruby 3.0 is a very good opportunity to do so.

From further discussions I got a light of hope that a solution may be accepted if certain conditions are met.
Specifically, a clear transition path that could lead the community towards the break of backwards compatibility.

In the issue [Make symbols and strings the same thing](https://bugs.ruby-lang.org/issues/7792)

ko1 (Koichi Sasada) wrote:

> Please consider transition path for users who are using symbol and string difference like:
> 
> key = ...
> ...
> when key
> case String
> ...
> case Symbol
> ...
> end
> How to find out such programs?
> 

he also wrote:

> If you (or someone) find out any good transition path, we think we can consider again.

Can we discuss here what are the rules that would allow the transition path solution to be accepted?

Also what solutions for the problem are we envisioning?

1. Use current symbols syntax as yet another strings syntax and stop using Symbols?
2. Use current symbols syntax as yet another strings syntax and start use Symbols with a new syntax?
3. Use current symbols syntax as yet another strings syntax and use Symbols purely as a class?

From the challenge presented by Koichi I understand that the transition path to be accepted must allow the current code to raise a warning for the situation where the Symbol is not anymore a Symbol but a String.

Is this assumption correct?

If this is the case then all we need is to make `String::===(foo)` and `Symbol::===(foo)` to raise warnings every time `foo` is a string and it was created using former symbol syntax.

This means the `foo` object needs to contain encapsulated the information of the syntax used to define it.

Any drawbacks?

NOTE: (I'm only considering solutions 2. and 3. for the purpose of this analysis. Meaning Symbol class will still exist.)



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>