On 05/23/13 16:02, Steven Schveighoffer wrote: > On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina <[email protected]> wrote: > >> On 05/23/13 15:12, Don wrote: >>> On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote: > >>>> struct Packet(uint TYPE) { >>>> immutable uint type = TYPE; >>>> // ... >>>> } >>> >>> But that allows you to write: >>> >>> auto w = Packet!(7)(6); >>> >>> which sets type to 6 ! >> >> No, it doesn't - this is why the "const and initialized, but still mutable" >> class >> is a bad idea. Modifying already initialized immutable data needs to be >> forbidden. > > There is a misconception here. The data is not fully initialized when the > ctor is called, it's just that the memory where the instance lives happens to > have a bit pattern in it with the value 7 when the ctor gets it. > > It's no different than a non-default initialized immutable being > "initialized" to 0 first before you set it. It's just you get to define the > bit pattern instead of using 0. > > In order to disable the behavior above, you have to disable the default ctor, > define a non-default ctor, or generate using a static method/function.
If it wasn't clear - it is about the _language_, not what some compiler currently happens to do. Being able to mutate /initialized/ immutables is a bad idea. IOW you should not be able to modify 'Packet.type' above. Keep in mind that modifying Packet.type is illegal /right now/. Even from a ctor or static-ctor. This does not need to change when such fields are no longer always implicitly static. While allowing re-initialization of immutables from a ctor is possible, it does not really give you much, while weakening const. (eg by making CT evaluation of such fields impossible). artur
