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
