The Status of Const

[Graham St Jack]

I have tried using const/immutable/shared several times, and am 
currently in the process of giving it another shot, with much more 
success that before, but it is hard work.

The major language hassle for me is that a class reference has the same 
const/immutable/shared type as the object is refers to, unlike pointers. 
I know that Rebindable is a workaround, but I don't find it satisfactory 
- essentially it uses brute-force casting to defeat the type system, and 
isn't syntactically identical to the bound type.

The data I pass between threads has to pass the !hasAliasing test, and I 
haven't found a practical way to make it work for classes. What works 
best for me is a struct with a pointer to immutable data like so:

struct Foo {
     struct Payload {
         ...
    }
    immutable(Payload)* payload;
    ...
}

Foo can then be passed, contained by value and assigned to, just like 
any other value type. Containing an immutable instance of Foo is ok too, 
if you need another layer of !hasAliasing. I tend to define all my 
non-trivial building-block data types this way, and pass them by value.

With careful design of my multi-threaded code, I can define a set of 
messages to pass between threads that don't need to contain complex data 
structures. The resultant design is always an improvement over the more 
complex interface that first comes to mind, so I find that the type 
system is pushing me in a good direction.

The next big hurdle (as you pointed out) is that druntime and phobos 
aren't designed for const/immutable/shared. For example, InternetAddress 
fails the !hasAliasing test, and concurrency Mailboxes defeat the type 
system rather than being shared themselves, and don't insisting that 
message parameters have to be !hasAliasing. So far I have had to 
implement my own concurrency, socket and condition modules to overcome 
these issues, and I'm sure those are just the beginning.

So there are plenty of bumps in the road, but it does look like it is 
finally possible to use const/immutable/shared if you are determined 
enough. That said, it needs to be way, way easier before wide adoption.

The library issues can be addressed easily enough - It didn't take me 
long to pull off versions that worked ok (Linux only I'm afraid). 
However, the issue with classes doesn't look so easy, and that seriously 
limits what can be passed in messages.

Is there any plan to introduce some way of having a mutable reference to 
an immutable class object on the heap? Do others see this as a problem 
at all?

On 13/08/10 08:26, 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?
>    


-- 
Graham St Jack