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

[ilya-stromberg]

On Thursday, 19 December 2013 at 09:52:15 UTC, Joseph Rushton 
Wakeling wrote:
> 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.

Yes, I think that REAL const-specific postblit/constructor can be 
useful, for example, for advanced dynamic typing.

For example, we can have reference-counting policy for some data 
object (for example, for manual memory management). So, we should 
create smart pointer with simple well-known rules: increase 
reference count if we create new smart pointer, decrease 
reference count if we destroy old smart pointer and destroy data 
object if reference count is equal zero.
Now assume that you need multithread support (it's also 
well-known problem). So, you must use synchronization (mutex 
and/or atomic operations) for every data object access because 
because another thread can modify data object.

Now assume that we have REAL const-specific postblit/constructor 
support. In this case we can separate `mutable` and `const` 
reference counts. If `mutable` reference count is equal 0 we can 
access data object witout any synchronization because nobody 
can't change data object (and it will be definetly faster because 
mutex and/or atomic operations is very slow).

So, REAL const-specific postblit/constructor can be really useful 
for advanced dynamic typing and optimization. Am I right?

Another question: for example, we will decide that we want to 
have REAL const-specific postblit/constructor support after 5-10 
years (who knows what happens with D in future?). What should we 
do in this case: introduce new `realconst` keyword only for REAL 
const-specific postblit/constructor? Would you like to be 
responsible for this decision?