akr / fsij.org wrote:
> Recent Eric Wong's effort reminds me this issue.
> 
> I still think this issue is worth to consider.
> 
> Ruby 2.1 changed the semantics of "...".freeze to avoid string allocation.
> It is not used extensively, I feel.

Right, "...".freeze is too ugly IMHO.  Ruby should stay beautiful :)

> File scope directive provides a way to use frozen string literals with
> much fewer modification to programs.
> 
> Also, I think frozen string literals is a better programming style.
> It needs dup call ("...".dup) for string literals to be modified.

I also think needing to call "...".dup is ugly and will break much
existing code[1].

> It makes us to prevent unintentional modification and
> we can distinguish string literals to be modified or not, more easily.

My concern is optimizing Ruby for the typical script language users[2],
not the (few) Rubyists who understand VM internals.

I prefer we continue to improve Ruby, transparently:

* 2.1 (past)     - { "str" => ... }, "str".freeze
* 2.2 (done)     - h["str"] (= ...)
* 2.2 (planned)  - .{gsub/sub/tr/tr_s}(["str"]|/../, "str"), ==, %,
                   many more core (cfunc) methods

All of the above are transparent to existing code.

> I would like that future Ruby (Ruby 3.0?) will interpret string
> literals as frozen by default.
> This issue can be considered as a migration path.
> We can introduce file-scope directive now and change the default at
> future when most programs uses frozen string literals.

I am against this; especially as a default for 3.0[1].  File scope
directives makes refactoring and reorganization of code more difficult:
move a method to a new file and behavior changes.

I hope we can implement more optimization transparently in the compiler.
For example; we should be able to optimize more cases:

       def foo(a, b)
	 a.gsub(/baz/, b)
       end

       foo(a, "lit") # no dup if `a' is a string

I think we can also use use (internal) C-API changes to mark cfuncs as
taking const args.  It would be useful for things like Hash#merge!, too;
not just string literals.

[1] - Even for Ruby 3.0; I strongly favor maintaining backwards
      compatibility as much as possible in Ruby-land.
      1.8 -> 1.9 was very painful for some users (including myself)