From: shevegen@... Date: 2019-09-07T11:27:27+00:00 Subject: [ruby-core:94826] [Ruby master Feature#16150] Add a way to request a frozen string from to_s Issue #16150 has been updated by shevegen (Robert A. Heiler). Just a short comment - I originally had to write more, but I think my statement would be too diluted. > Also, to_s definitions for user classes seem likely to already return > a frozen String simply because they might use a String literal > (interpolated or not) for it and frozen-string-literal: true. IMO, it currently can not be assumed to hold true because there may also be frozen-string-literal: false settings, and frozen strings are not yet the default nor will be in ruby 3.0, so I would not assume this the case right now. This may change in the future, but right now I think it would confuse people if to_s and to_str do NOT return a string or string-like object; and if a string is returned, it may be frozen, despite frozen-string literals set to false. The latter would qualify as a bug in my opinion. I have no specific opinion about the suggested APIs, but the names are a bit strange; or a bit cumbersome. "fstring" reads a bit like "formatted string". Oddly enough, I think #to_z is a bit better simply because it is shorter, but people may still ask why the "z" is there. I guess to_f was not offered as suggestion for frozen, due to it already meaning to a float representation. :) But in general, I don't really have any pro or con opinion either way. (Most of the suggestion seems to be more inspired about speed/efficiency and less about specific end-user use.) ---------------------------------------- Feature #16150: Add a way to request a frozen string from to_s https://bugs.ruby-lang.org/issues/16150#change-81447 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal * Assignee: * 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/ Unsubscribe: