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
