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.
