Nobuyoshi Nakada <nobu / ruby-lang.org> wrote:
> (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.

So can we move this optimization to the parser instead?  I think Sam means:

	# optimized literal by parser.  This may use pooled string since
	# the string never existed in ObjectSpace before this line of code:
	"string".freeze


However, if .freeze operates on a variable (and not literal):

	# leave this optimized by parser to avoid incompatibility
	a = "string"
	a.freeze => preserve existing behavior

> > 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

Yes, this scares me if a.freeze made 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.

Agreed.