Walter is right about transitive readonly - here's the alternative

[Bill Baxter]

Janice Caron wrote:
> ... - - - - conclusion - - - -
> 
> This is a viable, threadsafe alternative to both intransitive const
> and logical const.
> 
> It allows us to build all of the real-world use-cases that have been
> suggested a need for intransitive const or logical const.
> 
> You get three new keywords:
> * shared
> * readable
> * writable
> 
> You have to learn a new discipline to use these features, but it's not that hard

This proposal seems to me basically like 'synchronized' on steroids. So 
why not just use the word 'synchronized' instead of 'shared'?

If you'll allow me to just give a summary of the proposal, it does two 
main things -- first, it extends 'synchronized'(aka 'shared'), allowing 
you to apply it to values and aggregates.  And secondly it refines the 
notion of synchronized to include a distinction between read-only locks 
and read-write locks.

Your readable/writeable wrappers do indeed sound a lot like RAII mutexes 
I've seen in C++ threading libs.  I disagree that D's lack of operator-> 
makes putting 2-3 new keywords in the language a "cool solution".  A 
cooler solution would be to make D capable of something similar to 
overloading ->.

The readable/writeable distinction seems like it would be a useful 
capability for the current synchronized methods too.  Also the ability 
to apply synchronized on the instance side rather than definition side 
is interesting.

But to me, more mutexes doesn't really seem like the answer to our 
multi-threading problems, since as you point out, it's still really 
trivial to get deadlocks and such.  It seems like this is just and 
expansion on sugary muxtes rather than something that makes 
multithreaded programming fundamentally less error-prone.

It also seems like you could nearly get the same functionality out of 
some kind of smart pointer.
Shared!(T) x; -- a T but no direct access to T or its members is allowed
Readable!(Shared!(T))(x),
Writeable!(Shared!(T))(x) -- RAII types, allowing access to x and its 
members

If it isn't possible to make such a smart pointer in D right now (and it 
isn't) that's what should be fixed.  Then this proposal could be 
implemented as a library.

I just don't see this as a viable replacement for 'const' or 'pure'. 
Though, maybe your purpose is more to provide something that satisfies 
Walter's threading requirements, leaving const free to be a more C++-ish 
thing.  It does seem like a nice way to do mutex programming though.

--bb