[ruby-core:82615] [Ruby trunk Bug#13857][Rejected] frozen string literal: can freeze same string into two unique frozen strings

Issue #13857 has been updated by nobu (Nobuyoshi Nakada).

Status changed from Open to Rejected

chucke (Tiago Cardoso) wrote:
> Running an interpreter with `--enable-frozen-string-literal` on, I get the following:
> 
> ```ruby
> > c.downcase.object_id #=> 70303430619560  SO SO!
> > c.downcase.freeze.object_id #=> 70303430601780  BAD!
> ```

These are not literals, so not subjects of frozen-string-literal.

BTW:

> ```ruby
> request["Content-Type"] = "text/html" #=> key stored in request will be "content-type"
> ```
> 
> will create more allocations than expected.

Hash key strings are deduped in the trunk already.

```
$ ruby -v --enable-frozen-string-literal -e 'request = {}; key = "Content-Type".downcase; request[key] = "text/html"; newkey = request.keys[0]; p key.equal?(newkey), newkey.equal?("content-type")'
ruby 2.5.0dev (2017-08-31 trunk 59695) [universal.x86_64-darwin15]
false
true
```


----------------------------------------
Bug #13857: frozen string literal: can freeze same string into two unique frozen strings
https://bugs.ruby-lang.org/issues/13857#change-66440

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>