Issue #13857 has been updated by chucke (Tiago Cardoso). Or maybe a String#freeze which returns an already existing frozen literal if such already exists. I think that the #downcase result makes sense, and would break existing code otherwise. To sum it up, this is what I think could make sense: ``` > c = "bang" #=> frozen literal enable, this one is frozen > c.object_id #=> 70303434940940 GOOD! > c.downcase #=> "bang" > c.downcase.object_id #=> 70303430619560 SO SO! > c.downcase.freeze.object_id #=> 70303434940940 GOOD!!! ``` I don't see currently a real world use case where that would break code. And I also can't evaluate the feasibility of the feature, as I don't know the source code that well. But if there's an hash table where literals are stored, there could be a possibility that calling `#freeze` could do a lookup, replace with frozen literal, or freeze otherwise. ---------------------------------------- Bug #13857: frozen string literal: can freeze same string into two unique frozen strings https://bugs.ruby-lang.org/issues/13857#change-66449 * Author: chucke (Tiago Cardoso) * Status: Rejected * Priority: Normal * Assignee: * Target version: * ruby -v: 2.3.4, 2.4.1 * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- Running an interpreter with `--enable-frozen-string-literal` on, I get the following: ```ruby > "bang".object_id #=> 70303434940940 GOOD! > "bang".object_id #=> 70303434940940 GOOD! > "bang".object_id #=> 70303434940940 GOOD! > c = "bang" > c.object_id #=> 70303434940940 GOOD! > c.downcase #=> "bang" > c.downcase.object_id #=> 70303430619560 SO SO! > c.downcase.freeze.object_id#=> 70303430601780 BAD! ``` This ticket concerns the last two examples. In the case of performing an operation on the string, it makes sense to return a new string, even if the result is the same. However, I think that the last one could be done differently, in that the frozen result of the downcased value should be the original literal. I didn't see yet how the frozen string literals are implemented, so this might be dependent on it, but I think that this misses a few optimization use cases. One notable example is keeping a headers hash from an http library. `net/http` keeps a version of the headers hash with the keys downcased, only to capitalize them on send. Something like this: ```ruby request["Content-Type"] = "text/html" #=> key stored in request will be "content-type" ``` will create more allocations than expected. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>