DIP53 and DIP49 (ver2) - New definitions for qualified constructors and postblits

[Joseph Rushton Wakeling]

On 18/12/13 22:53, ilya-stromberg wrote:
> I understood your position, but it's bad analogy because we can have both
> `const` and `unique` postblits/constructors (at least in theory).
>
> I want to say that compiler can implicitly convert `mutable` and `immutable`
> types to the `const` type, but we can add `const` postblit/constructor for
> better control this cast (of course, only if we decide that it's really need).

I understand yours too, but isn't this a case where the theory gives us more 
than we need?  That is, we can already get a const instance using the 
currently-proposed const constructor, with no downside that I can see.

I don't particularly want to second-guess the future, but it seems to me like 
having distinct const and unique constructors would probably just lead to a 
confusing situation where either people over-specify (e.g. writing both 
const-specific and unique constructor where just unique would do, with risk of 
code duplication, extra maintenance burden, etc.) or where people assume that an 
object doesn't support something they want (e.g. "I can't instantiate a const 
instance because it doesn't have a const-specific constructor ...").

Unless there's a good application of a specifically const-specific 
postblit/constructor, it seems to me that the conflation in the DIP is helpful, 
because it simplifies the process of writing, understanding and using code at 
the cost of something which probably wouldn't be practically very useful.