## digitalmars.D - Re: Spec#, nullables and more

bearophile <bearophileHUGS lycos.com> writes:
```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>

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
```
Nov 06 2010
Don <nospam nospam.com> writes:
```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>

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.
```
Nov 06 2010