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 _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
