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?
