[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116011] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
From:
"matheusrich (Matheus Richard) via ruby-core" <ruby-core@...>
Date:
2024-01-04 16:27:36 UTC
List:
ruby-core #116011
Issue #18035 has been updated by matheusrich (Matheus Richard).
I'm not sure this was already mentioned, but this feels related to 3.2's Data class.
If this is accepted, should Data classes all be immutable? To quote [the docs](https://docs.ruby-lang.org/en/3.2/Data.html):
> Data provides no member writers, or enumerators: it is meant to be a storage for immutable atomic values. But note that if some of data members is of a mutable class, Data does no additional immutability enforcement:
>
> ```rb
> Event = Data.define(:time, :weekdays)
> event = Event.new('18:00', %w[Tue Wed Fri])
> #=> #<data Event time="18:00", weekdays=["Tue", "Wed", "Fri"]>
>
> # There is no #time= or #weekdays= accessors, but changes are
> # still possible:
> event.weekdays << 'Sat'
> event
> #=> #<data Event time="18:00", weekdays=["Tue", "Wed", "Fri", "Sat"]>
> ```
----------------------------------------
Feature #18035: Introduce general model/semantic for immutability.
https://bugs.ruby-lang.org/issues/18035#change-106004
* 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.
Proposed PR: https://github.com/ruby/ruby/pull/4879
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/