Bartosz Milewski Missing post

[Michel Fortin]

On 2009-05-30 13:00:14 -0400, Bartosz Milewski 
<bartosz-nospam at relisoft.com> said:

> The complexity argument:  My proposal looks complex because I am 
> dropping the whole comprehensive solution on the D community all at 
> once. I would be much wearier of the kind of creeping complexity 
> resulting from incremental ad-hoc solutions. For instance, the whole 
> complexity of immutability hasn't been exposed yet. If it were, there 
> would be a much larger insurgency among D users. You know what I'm 
> talking about--invariant constructors. My proposal goes into nooks and 
> crannies and, of course, it makes it look more complex than it really 
> is. Not to mention that there could be a lot of ideas that would lead 
> to simplifications. I sometimes discuss various options for discussion.
> 
> Take my proposal for unique objects. I could have punted the need for 
> "lent". Maybe nobody would ask for it? Compare "unique" with 
> "scope"--nobody knows the target semantics of "scope". It's a 
> half-baked idea, but nobody's protesting.
> 
> Try to define the semantics of array slices and you'll see eyes 
> glazing. We know we have to fix them, but we don't know how 
> (array[new]?). Another half-baked idea. Are slices simple or complex?

Bartosz, you're arguing that your proposal isn't that complex compared 
to strange semantics of other parts of the language and I agree... I 
should even say that what you propose offer a solution for fixing these 
other parts of the language. It's funny how what's needed to make 
multithreading safe is pretty much the same as what is needed to make 
safe immutable constructors and safe array slices, let's take a look:

A constructor for a unique object is all you need to build an immutable 
one: move the unique pointer to an immutable pointer and you're sure no 
one has a mutable pointer to it. Of course, to implement unique 
constructors, you need 'lent' (or 'scope', whatever our prefered 
keyword) so you can call functions that will alter the unique object 
and its member without escaping a reference.

As for slices, as long as your slice is 'unique', you can enlarge it 
without side effects (relocating the slice in memory won't affect any 
other slice because you're guarentied there aren't any), making a 
'unique T[]' as good as an equivalent container... or should I say even 
safer since enlarging a non-unique container might be as bad as 
enlarging a slice (the container may realocate and disconnect from all 
its slices). You could also later transform 'unique T[]' to 'immutable 
T[]', or to a mutable 'T[]', but then you shouldn't be able to grow it 
without making a duplicate first to avoid undesirable side effects.

So instead of fighting over what's too complex and what isn't by 
looking at each hole of the language in isolation, I think it's time to 
look at the various problems as a whole. I believe all those half-baked 
ideas point to the same underlying deficiency: the lack of a safe 
unique type (which then requires move semantics and 'lent'/'scope' 
constrains). C++ will get half of that soon (unique_ptr) but it will 
still be missing 'lent' though so it won't be so safe.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/