From: Nobuyoshi Nakada <nobu@...>
Date: 2013-10-14T12:51:42+09:00
Subject: [ruby-core:57842] Re: [ruby-trunk - Feature #8992] Use String#freeze and compiler tricks to replace "str"f suffix

(13/10/14 8:40), sam.saffron (Sam Saffron) wrote:
> Issue #8992 has been updated by sam.saffron (Sam Saffron).

Thank you for summarizing.

> There are 3 things being discussed here, I think it is fairly important we split them out.
> 
> 1. Parser optimisation for "string".freeze

> 1) is completely doable with little side-effects. My caveat is that if #1 is the only thing done, the semantics for #freeze depend on the invocation. That said, this is minor. I totally accept that and prefer "string".freeze to "string"f. 

It's a part of byte-code optimization, not parser.  Since we have done
it already for several methods, no problem there.

> 2. Unconditionally have #freeze return a pooled string
> 3. Change the semantics of #freeze so it amends the current object and operates like .NET / Java intern does.

> 2) without 3) really scares me. 
> 
> Imagine the odd semantics:
> 
> a = "hello"
> a.freeze # freezes one RVALUE in memory and returns a different RVALUE
> 
> 
> As to 3) I don't think it can be implemented in MRI. If an RVALUE is moved in memory, MRI is going to have to crawl the heap and rewrite all the RVALUE that hold a ref to it, it does not keep track of this internally.

Totally agree.

2+3 is wrong idea, I think.