On 12/19/2013 02:27 AM, Kenji Hara wrote:
2013/12/19 Joseph Rushton Wakeling <[email protected] <mailto:[email protected]>>And you have this(...) const (aka "unique"), which can be used to construct both immutable and mutable instances. It seems to me that this is a very natural relation to the existing interpretation of mutable, immutable and const variables by the language, and e.g. the way that immutable, mutable and const function parameters are addressed. That's right. When 'const' constructor/postblit is called, the constructing object qualifier is either mutable or immutable, even if it is not visible inside const constructor/postblit. ...
That is how to treat a 'wildcard', and not a supertype. The semantics of the new const constructor are the same as for the existing inout constructor.
---- I tweaked the descriptions in DIPs, about Const Constructor/Postblit concept. - I mostly removed words "unique constructor" and "unique postblit", because they would just increase reader's confusion. DIPs can describe intrinsic concepts without these words. - I added following sections in DIPs: Why 'const' postblit will called to copy arbitrary qualified object? http://wiki.dlang.org/DIP49#Why_.27const.27_postblit_will_called_to_copy_arbitrary_qualified_object.3F Why 'const' constructor will be called to create arbitrary qualified object? http://wiki.dlang.org/DIP53#Why_.27const.27_constructor_will_be_called_to_create_arbitrary_qualified_object.3F There's no violation against the widely known "const method" concept. Kenji Hara
Well, a constructor can be thought of as yielding a result. A const method returning 'this' cannot return an 'immutable' object. I do understand your rationale. What I am saying is that the DIP adds a wildcard meaning to 'const' that was not previously there, and I consider this to be more of a weakness than a strength.
