On Thu, 08 May 2014 16:33:06 +0000 David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote: > > For what practical reason would that be the case? I know that > > the spec states "undefined behavior", but AFAICS, there is > > neither an existing, nor a theoretical reason, why this should > > fail: > > Compiler optimizations based on immutability. Or even just based on const. Optimizations based on const are going to be rarer, because other objects of the same type but which are mutable could refer to the same object and thus mutate it, but if the object is thread-local (as is the default), then there will still be some cases where the compiler will be able to assume that the object isn't mutated even if immutable isn't involved at all. If you're even attempting to cast away const and then mutate the object, you need to have a really good understanding of how the compiler could even theoretically optimize based on const (especially since even if an optimization isn't done now, and your code works, it could be added later and break your code). So, I'd strongly argue that casting away const from an object and mutating it is a fundamentally broken idiom in D. You may have a better chance of avoiding blowing your foot off if immutable isn't involve, but you still risk serious bugs. - Jonathan M Davis