so what exactly is const supposed to mean?

[David Medlock]

kris wrote:
> Chris Nicholson-Sauls wrote:
> 
>> Technically no.  Although at present, there are precisely two possible 
>> methods, and both require wrapping every single field up with a 
>> D-style property.  (True properties could actually have the potential 
>> to make this simpler... but we don't have those either.)
>>
>> Method #1 - Write the class as innately immutable, then write a 
>> mutable subclass.  This is the methodology at work in Mango, for 
>> example, where the module mango.io.FilePath actually defines two 
>> classes, FilePath:Object and MutableFilePath:FilePath.
>>
>> Method #2 - Same as above, but with one class that has a pair of 
>> methods (mutable() and immutable() for example) that 
>> activate/deactivate mutability, usually locking on something such as 
>> instance of another class (the identity of which doesn't particularly 
>> matter). For (quick'n'dirty) example:
> 
> 
> Method #3 - each mutator function/method actually creates a clone of the 
> original, mutates it, and returns that instead.
> 
> Method #1 & #2 are typically the most efficient, but can expose an 
> achilles heel. For instance, suppose you had an immutable String class? 
> At some point, it will need to expose the content therein -- perhaps via 
> a toString() method, or perhaps something more subtle? At that point, 
> the class either returns a .dup of the internal content, or it exposes 
> the internal content directly by returning it (as an array). Neither of 
> these options are entirely attractive, and it's the reason why fully 
> immutable classes/structs are not entirely practical in D at this time.
> 
> This "return value" concern is also the reason why I believe that a 
> "minimalist" support for "read-only" would be to protect just the return 
> values. With the latter, one could happily return internal aggregate 
> content (as arrays) and be safe in the knowledge that the compiler will 
> catch pedestrian errors. However, I'd much rather see const-by-default 
> instead -- that's a more practical solution, and should offer notable 
> opportunities for optimization.
> 
> One should note that the goal of such mechanisms is to tighten up the 
> "contract" between caller and callee. This becomes increasingly 
> important within multithreaded designs, to the point of becoming a 
> fundamental requirement in some ways (in terms of robustness, 
> simplicitly, efficiency, deterministic behaviour, etc). CoW is another 
> mechansism intended to achieve similar results, but the key distinction 
> is the lack of an enforceable contract. With mutable/immutable decls, 
> the compiler has the necessary information to catch cases where the 
> contract is being broken. With CoW, the compiler does not have that meta 
> information available (whether the design says it's OK to alias or not).
> 
> Of course, this won't stop some determined fool from bypassing the 
> contract altogether: even with immutable-by-default, one could 
> presumably cast() lvalues in some manner to subvert the contract. But 
> that's not the point -- the compiler would be looking to catch honest 
> mistakes, and not trying to cure stupidity :p
> 
> Hope this helps.

Not intending to start a long drawn out 'const' discussion again but...

Multithreading appears to be the hardest of hardware parallelism to 
implement.  Race conditions will not magically disapear with 
const-correctness (Delegates alone negate that).

I really believe that true hardware parallelism will come from data 
parallelism:

Data[1000]	mydata;
foo( mydata );

processor 1 operates on mydata[0-499]
processor 2 operates on mydata[500-999]

Data parallelism is (in the general sense) inherently faster,doesn't 
require locking, and is not prone to things like task-switching, locks, 
race conditions, etc

Apparently NVidia has figured this out already.
Of course this requires a more relational/vector view of the data than 
is currently mainstream.

Here is a relevant presentation:
http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

(PDF 
here:http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf 
).

Const has some nice properties, but I rate it about a 5 on a scale of 10 
for dire features.  Yes, I know libraries benefit from it.
I would counter that library authors have serious design issues to 
consider even with const, and that COW is not a bad tradeoff in the 
meantime.

-DavidM