[ruby-core:95119] [Ruby master Feature#16150] Add a way to request a frozen string from to_s

[headius@headius.com]

Issue #16150 has been updated by headius (Charles Nutter).


I'm glad to see some smaller parts of this are moving forward. A few updates from my end (JRuby):

* Frozen strings from Symbol etc:

We are on board with making Symbol, nil, true, false, and Module all return frozen strings, and have an open PR to do this for Symbol right now: https://github.com/jruby/jruby/pull/5868

* String#to_s concerns:

Right now since it returns self, it may be frozen or unfrozen, so you are NEVER safe mutating the result of to_s directly. With the changes above, even more types will start returning frozen strings. I feel like we need a way to audit the mutation of to_s results we want to make frozen in the future, similar to the --debug:frozen-string-literal feature that prints out where a frozen string came from if you try to mutate it.

I guess my logic boils down to this right now:

* to_s often returns a frozen string right now.
* to_s will return more frozen strings in the future if these PRs make it into 2.7.
* Both now and in the future, it is not safe to mutate the results of a to_s.
* So, let's give people a way to find these mutations as part of 2.7, so we can help eliminate such cases.

----------------------------------------
Feature #16150: Add a way to request a frozen string from to_s
https://bugs.ruby-lang.org/issues/16150#change-81753

* Author: headius (Charles Nutter)
* Status: Assigned
* Priority: Normal
* Assignee: Eregon (Benoit Daloze)
* Target version: 
----------------------------------------
Much of the time when a user calls to_s, they are just looking for a simple string representation to display or to interpolate into another string. In my brief exploration, the result of to_s is rarely mutated directly.

It seems that we could save a lot of objects by providing a way to explicitly request a *frozen* string.

For purposes of discussion I will call this to_frozen_string, which is a terrible name.

This would reduce string allocations dramatically when applied to many common to_s calls:

* Symbol#to_frozen_string could always return the same cached String representation. This method is *heavily* used by almost all Ruby code that intermingles Symbols and Strings.
* nil, true, false, and any other singleton values in the system could similarly cache and return the same String object.
* The strings coming from core types could also be in the fstring cache and deduplicated as a result.
* User-provided to_s implementations could opt-in to caching and returning the same frozen String object when the author knows that the result will always be the same.

A few ideas for what to call this:

* `to_fstring` or `fstring` reflects internal the "fstring" cache but is perhaps not obvious for most users.
* `to_s(frozen: true)` is clean but there will be many cases when the kwargs hash doesn't get eliminated, making matters worse.
* `def to_s(frozen = false)` would be mostly free but may not be compatible with existing to_s params (like `Integer#to_s(radix)`

This idea was inspired by @schneems's talk at RubyConf Thailand, where he showed significant overhead in ActiveRecord from Symbol#to_s allocation.



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