On 13/08/10 09:51, Brad Roberts wrote:
On Thu, 12 Aug 2010, dsimcha wrote:
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical beauty, I find D's const/immutable system to be
utterly useless for all but the simplest use cases. I made a serious attempt
a while back to use it in a real multithreaded program. In hindsight it was
more trouble than it was worth, largely for three reasons:
1. It's difficult to create non-trivial immutable data structures, and often
impossible without relying on either unchecked casts or unnecessary copying.
2. Much generic code in Phobos (even things as simple as std.math.pow()
before I recently fixed it) behaves incorrectly when given const/immutable
data. This also applies to other libraries I use, including ones that I'm the
main author of, so I'm just as guilty of it as anyone. Given that noone,
including me, seems to be able to get const to interact well with generic
code, perhaps we need a language-level solution.
3. inout is currently so bug-ridden it's not even funny. (Though this is
clearly fixable long-term, once we get higher priority stuff off our plates.)
It would have probably been better if this was brought to a head sooner, but
it's better late than never. Do others agree that D's const system is
difficult to impossible to use properly? Has anyone successfully used D's
const system in a non-trivial setting despite these limitations? If so, was
it more trouble than it was worth in hindsight? How can these limitations be
worked around and/or fixed?
For discussions like this, I think it's essential to distinguish between
the language vs the runtime + core libraries. I recognize what matters is
the end result usability, but examining the layers independently is really
important.
So, which are you talking about (could well be both)?
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable reference to a const/immutable/shared object.
You can achieve this with pointers for arrays, structs and primitive
types, but not with classes because a class pointer is just a pointer to
a reference.
--
Graham St Jack
