From slices to perfect imitators: opByValue

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu May 8 18:10:07 PDT 2014


On Thu, 08 May 2014 16:33:06 +0000
David Nadlinger via Digitalmars-d <digitalmars-d at 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


More information about the Digitalmars-d mailing list