bearophile wrote:
J. M. Berger:
<sarcasm>
Consider immutable type immutable T:
immutable T] a = new immutable T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
In other words I create an array that I mean to fill in later,
because I don't have meaningful data for it in advance. How do I do
that with immutable types?
</sarcasm>
Despite your answer was sarcastic, it's a very interesting note.
In a recent post I have explained how Spec# solves this problem with arrays of
nonnulls, using NonNullType.AssertInitialized():
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=121140
What's interesting in your sarcastic note is that you have shown that building
a collection of immutables and a collection of nonnulls in some situations
share the same basic problem, that is how to build something that has
constraints regarding its changes or its not being present yet.
Two bug reports about the topic:
http://d.puremagic.com/issues/show_bug.cgi?id=5147
http://d.puremagic.com/issues/show_bug.cgi?id=5081
In my opinion currently in D there aren't very good ways to build collections
of immutables.
The Clojure solves a related problem (it's a performance problem too), using
transients:
http://clojure.org/transients
In practice even the Spec# solution uses a kind of "transient", you use
NonNullType.AssertInitialized() to mark inside a function the point where you state an
array of nonnulls is done, the transient had ended. Even if syntactically they are very
different, on a semantic level they are doing the same thing, they are both ways to tell
apart the building phase from the finished phase. Surely there are many different ways to
tell the compiler a way to tell apart such two phases.
A solution for the creation of immutable collections in D may be used to build
collections of nonulls too. They aren't the same problem, but they share enough
that the same solution (with little changes) may be used for both.
Bye,
bearophile
As was pointed out in a recent post, the return value of a pure function
is guaranteed to be unique, so could be allowed to implictly cast to
immutable. I'm planning a patch for that soon, to see how well it works
in practice.
But I don't think that would work for non-nulls. I don't think the two
situations have a great deal in common.
