Issue #14277 has been updated by jeremyevans0 (Jeremy Evans).


dsferreira (Daniel Ferreira) wrote:
> This is the ambiguity:
> 
> ```ruby
> alias_method :foo, :bar
> alias_method "foo", "bar"
> ```

This is not ambiguity.  The methods are designed to be used with symbols.  The methods also accept strings in order to be a little easier to use in some situations.

Many methods in ruby accept multiple types of arguments and convert one type to another to improve programmer happiness.

To say strings and symbols are ambiguous is to imply that it is not possible to differentiate the two.  That is not true in ruby.  Symbols have different purposes than Strings, and in all cases it is possible to determine which one is more appropriate, even if you allow both for ease of use.

> 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.

Just because there some cases where you can use either a string or a symbol does not imply that you can use a string in all cases where you can use a symbol, or vice-versa.  Many methods that work with strings do not accept symbols, as using a symbol does not make sense.  For example, `IO.read` doesn't accept a symbol, as using a symbol doesn't make sense semantically.

> 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.

I believe the separation of symbols and strings in ruby greatly increases the expressiveness of the language and allows the creation of libraries like Sinatra, Sequel, Cuba, and Roda.  All of those libraries, and many other libraries, rely on symbols and strings being separate in order to function, and the different handling for strings and symbols is a core part of the library.  I checked Rails and Rack and making symbols the same as strings would change the behavior of them as well (no `case Symbol` there, but check places where `is_a?(Symbol)` is used).

> 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?

If Symbols are kept at all, it doesn't make sense to change the current Symbol literal syntax to result in Strings.  Assuming Symbols are kept at all, another possible option would be to add an alternative string literal syntax that saves a character, since that seems to be the primary reason that people want to use symbol literals for strings.

> 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.

If you look at ruby code in the wild, `is_a?(Symbol)` seems even more common than `case Symbol`, and sometimes in places where symbol behavior differs from string behavior by design.
 
> Any drawbacks?

* Breaks backwards compatibility in ways that in some cases completely break the ways common libraries are currently used
* Reduces expressiveness
* Further reduces separation of concerns, merging identifiers (Symbol) into a class (String) already overloaded to handle both raw/binary data and text

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

As stated above, I don't see the point of using the current symbol literal syntax for strings if you are keeping symbols.  If you need to have symbols anyway, then the only reason to use the symbol syntax for strings is to save a single character.  In which case it would be better to introduce a new terser form of string literal.

I strongly urge matz to reject this for the same reasons he has rejected the previous requests for this (mis)feature.

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

* 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>