On Wednesday, 17 February 2016 at 11:56:29 UTC, Andrei
Alexandrescu wrote:
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and
full of holes.
I thought it was the constructors and postblit that are the
matter. (It may seem I'm on a snarky streak, but I do think
that's the remaining issue with immutable). -- Andrei
Yes, those are design problems with D's const that we really need
to figure out how to fix, but they're not necessarily what people
complain about. Many folks want to be able to do things like lazy
initialization or caching or have a mutable reference count in a
const/immutable object. The problems that usually come up
basically boil down to folks wanting logical const rather than
the compiler actually guaranteeing that data cannot be mutated
via a const reference to that data without violating the type
system. Lots of people basically want holes in const, because
that's what C++ has, and not having holes in const prevents a
number of potentially useful idioms (heck, you were trying to get
around it with a container that you posted in the main newsgroup
semi-recently and in RCString when you posted about it in
dlang-study the other day).
We need to solve the constructor/postblit issues in order for D's
const to really work like it's supposed to, but even if that
problem were solved, the basic tenet of D's design for const -
that it has no backdoors - is what really makes it so that many
folks avoid const completely, whereas others use it but violate
the type system by casting away const and mutating, not realizing
that unlike C++, it's undefined behavior in D.
Regardless of whether Walter's (and thus D's) stance on const is
the right one, it clearly doesn't jive with what a lot of folks
(particularly those from C++) are looking for or expecting.
- Jonathan M Davis
