From: "trans (Thomas Sawyer)" Date: 2013-02-14T10:17:09+09:00 Subject: [ruby-core:52241] [ruby-trunk - Feature #7849] Symbol#to_str Issue #7849 has been updated by trans (Thomas Sawyer). > If, for your needs, you were to define to_st on String & on Symbol, you could have the utility you desire. Yes, I thought about that. But concluded it was most likely unnecessary complexity when #to_str would work fine. You say "Bad idea". But show me why it is bad idea other then "them's the rules". I tried to think of a problem case, and the only one I can think of is using `foo.respond_to?(:to_str)` to identify Stringy things and very specifically not meaning to include Symbols. It's possible, but it's a fairly narrow proposition. Not the least reason being that one should never use `respond_to?` if one does not need to b/c it is a fragile approach. But more significantly, what is more likely to be used? This narrow usecase or Symbol#to_str? Clearly the later by far. And the former is easily solved with `&& !Symbol === foo`. ---------------------------------------- Feature #7849: Symbol#to_str https://bugs.ruby-lang.org/issues/7849#change-36264 Author: trans (Thomas Sawyer) Status: Open Priority: Normal Assignee: Category: core Target version: next minor Even though a Symbol is not technically an honest-to-goodness String, from the standpoint of simple practicality it would help to have Symbol#to_str defined. There are times when we want an argument to accept a String or a Symbol, but don't really want it to accept any type of object under the sun that responds to #to_s --which is just about anything. This is especially the case when writing DSLs. Having Symbol#to_str is the nice solution to this. Defining Symbol#to_str may be an exception to the rule, but it's one worth making. -- http://bugs.ruby-lang.org/