From: "Eregon (Benoit Daloze)" <noreply@...>
Date: 2021-10-21T09:20:42+00:00
Subject: [ruby-core:105723] [Ruby master Feature#18035] Introduce general model/semantic for immutable by default.

Issue #18035 has been updated by Eregon (Benoit Daloze).


Use cases:
* Actually have a way to express immutable/deeply frozen in Ruby. Right now there is no way, and `freeze` is only shallow.
* Immutability has many benefits, easier to reason about, no data races possible, clarifies a lot the behavior of a class, possible to cache safely based on immutable keys, etc.
* Right now immutability is only for core classes, but of course it is useful for user code too.

Multiple proposalts for deep_freeze were already done, showing people want it:
* https://bugs.ruby-lang.org/issues/18148 as an inefficient way to deep_freeze, but we can make it faster and more direct
* https://github.com/dkubb/ice_nine as a gem to deep freeze, but we could be much faster by having the mechanism/flag part of the VM
* https://bugs.ruby-lang.org/issues/17145 we tried to concile deep_freeze + shareable, it did not work out because shareable has weird exceptions. Yet everyone understands what "immutable" means and users want that, shareable is only meaningful for Ractor.
* https://bugs.ruby-lang.org/issues/12008 another proposal for deep_freeze, see motivation in the description.
* https://bugs.ruby-lang.org/issues/2509 12-years ago issue. Rejected regarding freezing classes, but it's clear now that `obj.deep_freeze` should not freeze the class (no benefit to that for anyone).

----------------------------------------
Feature #18035: Introduce general model/semantic for immutable by default.
https://bugs.ruby-lang.org/issues/18035#change-94223

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby.

I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc.

I don't have any particular preference but:

- We should establish consistent patterns where possible, e.g.
  - Objects created by `new` are mutable.
  - Objects created by literal are immutable.

We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method?

Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems.

I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g.


```ruby
module Immutable
  def new(...)
    super.freeze
  end
end

class MyImmutableObject
  extend Immutable

  def initialize(x)
    @x = x
  end
  
  def freeze
    return self if frozen?
    
    @x.freeze
    
    super
  end
end

o = MyImmutableObject.new([1, 2, 3])
puts o.frozen?
```

Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient.

I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals.



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

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