Spec#, nullables and more

[Don]

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.