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)?

Reply via email to