Issue #14277 has been updated by duerst (Martin Drst).


dsferreira (Daniel Ferreira) wrote:

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

Koichi has given a challenge, most probably because he thinks it's very difficult if not impossible. Koichi only wrong "we can consider again".

So there are no "rules" that symbols and strings will be collapsed when certain well-defined conditions are met. In the end, the only rule is that Matz will have to decide.

Anyway, to me this looks similar to somebody coming e.g. from JavaScript or JSON and asking when Integers and Floats will be merged. JavaScript and JSON don't distinguish Integers and Floats (although some JavaScript implementations try to make the distinction under the hood for efficiency). JavaScript and JSON also don't distinguish between Symbols and Strings.

Teaching programming, and looking back at my own experience, I know that many people have difficulties at first to distinguish Integers and Floats (or whatever that's called in a different language). However, it's not too difficult to get the distinction after a little bit of time. That's the same for Symbols and Strings.

However, Ruby distinguishes Integers and Floats, and it distinguishes Symbols and Strings. While the former distinction is more popular among programming languages, the later distinction is available in quite a few, too, and came from Lisp, on of the oldest high-level programming languages.

And just in case somebody cares, I have a library where the distinction between Symbol and String is crucial (and easy to understand). So I'm not supporting such a change, even if the general transition issues could be handled.

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

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