The Status of Const

[Graham St Jack]

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