On Thursday, 18 February 2016 at 12:03:00 UTC, Walter Bright
wrote:
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a
const object.
Contrary to your suggestion, headconst won't help with that.
Of course it will:
headconst pointer -> pointer -> refcount
-> const pointer -> ... constant stuff ...
Sure, until you need to put that headconst pointer in a const
object or pass it to a function that takes const. Then the whole
thing is const, and the refcount doesn't work. Remember that C++
has headconst, and it still needs the mutable keyword in order to
solve these problems. Also, adding headconst is suddenly going to
create this dichotomy between const and headconst where you have
to figure out which to use and where they really don't interact
nicely, because you can't pass a const object to something that
takes headconst, and if you do pass a headconst object to
something that takes const, then all of the stuff like
ref-counting stops working. In a way, we'd be forking D between
const and headconst. Some code would use one, and some code would
use the other. And neither of them really solves the problem that
the mutable keyword solves. Neither of them allows for any kind
of logical const, and _that_ really is the problem that people
keep complaining about and want solved.
headconst may solve the extern(C++) problem, but it really
doesn't solve the problems we have with const. At best, it
reduces them slightly while introducing a whole extra set of
complications to an already complicated language.
- Jonathan M Davis
