Sharing in D

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 31 08:51:03 PDT 2008


"JAnderson" wrote
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> http://www.reddit.com/comments/6u7k0/sharing_in_d/
>>
>> There are 2 problems I see with this scheme.
>>
>> First, that the default is 'unshared'.  This is going to break a lot of 
>> existing code, and make peoples lives miserable who do not want to deal 
>> with unshared non-stack data.  I would hazard to guess that adopting this 
>> would cause a larger rift than const.
>
> <Snip>
>
> As far as radical changes to the language breaking existing code, if 
> Walter maintained that approach D would never beable to make radical and 
> correct improvements (rather then half-work rounds).  We would end up with 
> C++.  This is why we have D 1 and 2.  D 2 is still the experimental 
> branch.  Yes it makes radical changes however D might never be able to 
> provide better multi-threading support if it can't make breaking changes.
>

So should people wait to write libraries until all this is fleshed out?  I 
mean, there is already a pretty significant code base that assumes shared is 
the default.  When this ever gets around to being implemented (and 
released), how much work will it be to rewrite all code to either use a new 
model, or put a shared tag on every variable?  It seems to me the logical 
approach is to assume shared and tag things as unshared.

> My option is that the experimental branch of D should be correct first and 
> backwoods compatible second.

That is a great recipe for the forking of D :)  I'm not saying that breaking 
changes should be unacceptable, I'm just saying that there better be a 
really compelling reason to break things.

I believe Walter's view of "wild west" programming is completely off target. 
Many good multithreadded applications exist today, without the aid of this 
shared/unshared view.  I don't see how having this is going to magically 
solve any threadding issues.  If anything it's going to just pop up as an 
annoying obstacle that is frequently bypassed with casts, making the system 
useless anyways.  I don't know if this can be shown until the idea moves 
from theory to practice, so maybe we'll just have to wait and see.  This 
could be a stepping stone to a really great system, just like the first 
const incarnations were awful, but the one we have now (save a few missing 
pieces) is pretty good.

Just my opinion.

-Steve 





More information about the Digitalmars-d mailing list