On 2009-05-30 13:00:14 -0400, Bartosz Milewski
<bartosz-nos...@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.for...@michelf.com
http://michelf.com/
