Issue #16150 has been updated by Eregon (Benoit Daloze).


duerst (Martin D=FCrst) wrote:
> I didn't find the text "a possible incompatibility reported by one user" =
anywhere in this issue.

It's my interpretation and the only piece of information I had so far from =
https://github.com/heroku/heroku-buildpack-ruby/issues/833#issuecomment-548=
592514
That bug report is rather unclear, apparently even using latest Rails didn'=
t solve the issue, and previous comments on that issue are completely unrel=
ated.

> I think it's not a bad idea to have a bit of slack for version combinatio=
ns. If we put too many restrictions on what version of something can be com=
bined with what version of something else, we easily get into situations wh=
ere there are no viable combinations anymore.

I would think it's always advisable to update Rails before Ruby.
The other way around seems a recipe for more warnings and more issues.

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

* Author: headius (Charles Nutter)
* Status: Open
* 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 explicit=
ly request a *frozen* string.

For purposes of discussion I will call this to_frozen_string, which is a te=
rrible name.

This would reduce string allocations dramatically when applied to many comm=
on to_s calls:

* Symbol#to_frozen_string could always return the same cached String repres=
entation. This method is *heavily* used by almost all Ruby code that interm=
ingles Symbols and Strings.
* nil, true, false, and any other singleton values in the system could simi=
larly 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 al=
ways be the same.

A few ideas for what to call this:

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

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



-- =

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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>