Issue #17104 has been updated by duerst (Martin D=FCrst).


bughit (bug hit) wrote in #note-11:
> > However in my view what defines a literal, is the use of a specific syn=
tax, so ""
> =

> There is only one reason for freezing literals, to be able to intern them=
 and reduce allocation. In fact the feature is poorly named, after the cons=
equence(freezing), not the cause (interning).

My understanding is that another reason is avoidance of alias effects. It's=
 easy to write code that when cut down to the essential, does this:
```
a =3D b =3D "My string"
a.gsub!(/My/, 'Your')
```
and expects `b` to still be "My string". Freezing makes sure this throws an=
 error.

(This is not an argument for or againts freezing interpolated strings.)


----------------------------------------
Feature #17104: Do not freeze interpolated strings when using frozen-string=
-literal
https://bugs.ruby-lang.org/issues/17104#change-87013

* Author: bughit (bug hit)
* Status: Open
* Priority: Normal
----------------------------------------
```rb
#frozen_string_literal: true

def foo(str)
  "#{str}"
end

fr1 =3D 'a'
fr2 =3D 'a'
fr1_1 =3D foo(fr1)
fr2_1 =3D foo(fr2)

puts fr1.__id__, fr2.__id__, fr1_1.__id__, fr2_1.__id__

puts fr1_1 << 'b'
```

Isn't the point of frozen literals to avoid needless allocations? But inter=
polated strings are allocated each time, so freezing appears pointless. =





-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>