https://issues.dlang.org/show_bug.cgi?id=19928
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- OS|Mac OS X |All --- Comment #6 from Steven Schveighoffer <[email protected]> --- The reason you can modify immutable in a constructor is because nothing else has access to it. As soon as you give access to it elsewhere, it can cause a problem. Andrei is correct, calling any function which allows access to the immutable provides a vector of breaking immutability. (In reply to RazvanN from comment #1) > I don't think this issue is valid. If we disallow modification of immutable > fields after a base class ctor is called then it will be impossible to > initialize that field after a super call, which in my opinion is > unacceptable behavior. It's tricky, and definitely difficult to deal with. It would disallow certain solutions that seem otherwise valid. But that might be the cost of having a correct immutable implementation. I will note that Swift enforces all members are initialized (look for 2-phase initialization) before calling a super ctor: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html Java is the opposite, it requires you call any super ctor FIRST before initializing members: https://stackoverflow.com/questions/15682457/initialize-field-before-super-constructor-runs But they also don't have a concept of immutable which is implicitly sharable. --
