[dmd-beta] dmd 2.063 beta

[Sönke Ludwig]

Am 30.04.2013 02:42, schrieb Kenji Hara:
> First of all, this is a new feature from 2.063 - qualified constructor
> support.
> In the definition of the class Test, mutable constructor this() could
> construct only non-shared objects. Then you cannot create shared
> object by using it.
> (...)
> One proper way is adding shared constructor overload. Now it would be
> correctly selected for the construction.
> (...)
> One another way is make the constructor 'pure'. If a pure constructor
> satisfies some conditions, it would become to 'unique constructor'.
> (...)
> In default, this() is used for non-shared mutable object.
> But pure attribute enforces that the constructed object does not hold
> any "non-shared mutable global data" implicitly, then compiler can
> guarantee that the constructed object is unique.
> Unique object can be convertible to any qualifier, then implicit
> conversion to shared is accepted.
>

Thank you for the explanation! Disallowing global data makes a lot of
sense for constructing immutable objects. But for shared objects,
shouldn't the compiler rather just disallow accessing any non-shared
fields (and methods) on a shared object?

If that is enforced (and that needs to be enforced anyway AFAICS), there
should be no way to accidentally reference unshared global data from
shared code. Thus, allowing to use unshared constructors for shared
objects should not result in unsafe code and can be allowed. The only
thing would be that the freshly initialized data is not accessible after
construction - but this is actually very useful/necessary to make the
lock()-scenario safe.

By the way (not specifically targeted at you, Kenji), while I reworked
parts of my code to be "pure", it became very obvious that the direction
we are heading becomes really involved without pure by default.
Everything is littered with "pure" annotations and many of the most
important parts of Phobos are impure (e.g. Appender should be able to be
weakly pure), to the point that it seems impractical to use in a larger
setting. If there was something like "@impure", it would be possible to
put a "pure:" at the top of each module and only explicitly handle the
impure code blocks, making it far more manageable without breaking
backwards compatibility.

I don't remember discussions about this, but I think this needs to get
priority as "pure" feels more and more self-contradictory in that it is
an opt-in feature (and thus typically only used when necessary), but at
the same time is required for all kinds of basic language functionality
(now also for unique expressions). If it is vital for so many things, it
should really be the default (of course not possible without breaking
backwards compatibility), or at least be able to come close to being the
default.

Best regards,
Sönke