On 2/17/2016 3:12 PM, Jonathan M Davis wrote:
On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright wrote:
It would seem that implementing headconst as a type constructor would let
people who wanted mutable members have their way, without introducing
backdoors in const.
I really don't see how that's the same thing at all. The main problems with
const pop up when what folks need is something like C++'s mutable, because they
need to be able to do something like a reference count or a mutex which is not
really part of the logical state of the object but is still part of the object.
Having some form of non-transitive const allows for things like a const pointer
to non-const data, but it doesn't help at all when what you need to do is treat
most of the object as const while treating a small portion of it as mutable.
Sure, that's not completely transitive, because parts of the object are mutable,
but it's specific parts of the object, not which part of a pointer declaration
is const and which isn't. Maybe I'm missing something, but I don't see how
adding non-transitive const to D in order to solve the C++ declaration problem
would help at all with the complaints that folks have with D's const. The
complaints with D's const are almost entirely about the lack of backdoors (be
they well-defined like a mutable attribute or a free-for-all like casting away
const and mutating).
If the headconst was one level up, the struct can have mutating members.
