Issue #7854 has been updated by cabo (Carsten Bormann).


Let me just point out that this is the right way to solve a problem that we have in Ruby-based protocol implementations.
Right now, there is no safe way on the Ruby level to use symbols to represent strings coming in on an unchecked interface.
Of course, at the API level, I can easily use rb_check_id().  
The fact that this API exists should alert you to the fact that something is missing at the language level.

Kudos to Matthew for making this available as a gem for now.
I'm not too wild about #interned as the name, but I'm used to Ruby method names being slightly idiosyncratic.

??? This needs to go into Ruby core sooner than later.

The "alternatives" mentioned:
#7791 is a pipe dream (well, something like it could be made to work with an allocator region concept).  
#7839 is serious damage (it could also be implemented on top of a global allocator region setting, which is still damage).

But why allocate at all if you *know* you don't want to?

----------------------------------------
Feature #7854: New method Symbol[string]
https://bugs.ruby-lang.org/issues/7854#change-40339

Author: Student (Nathan Zook)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor


I propose a new class method [] on Symbol.  If a symbol s already exists such that s.to_s == string, then s is returned.  If not, nil is returned.

The inspiration for this method is a question I was asked, and the answer I was given:  "Why would you want to turn a tainted string into a symbol?"  "I don't--I want to access an existing symbol with tainted data".  Symbol[] accesses the symbol table like hash[] accesses the elements of a hash.

I believe that this completely addresses the problems behind tickets #7791 and #7839.  I believe that it is a more intuitive solution than my proposal #7795, and I believe that this will also be useful for YAML.safe_load and similar initiatives.



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