Drop nil from the language about dora HOT 8 CLOSED

I think removing nil became recently feasible in Dora. Thanks to @soc, we now have the Option class and the arrayDefault-function (although it's called arrayNew but feel free to change it). I don't think we need the lambda-version right now since we have the Vec class as well.

I guess what is left is to simply require initializers for fields and to make Array[T](length: Int) private to stdlib. The latter one could be "solved" for now by simply treating the array constructor as internal. Later when functions can be private to a module it is straight-forward to rectify this.

Apart from that I suppose we only need to remove nil from tests and test/benchmark programs - and then removing nil-support completely from the language.

from dora.

Sounds good!

from dora.

Very exciting progress!

I updated the description above to the new syntax and the rough semantics of the existing code for Default; also added arrayZero as a more limited, but more lightweight alternative for types where no custom initialization code needs to be run (which I forgot when I first wrote the issue).

from dora.

Not sure we need arrayZero for avoiding initialising twice. I think the optimizing compiler or runtime should be able to detect this and optimize it away. We need that anyways since classes like Vec[T] can't use arrayZero since they operate on all possible types.

from dora.

From my perspective it's not about initializing twice, it's avoiding initialization altogether:

Allocating zeroed memory for those types implementing Zero means that the type is properly initialized, but not every type can implement Zero.

Default is different in that every type could implement it.

For example, String could support Default with a default value of ""; arrayDefault[String](10) would mean that the defaultValue would be computed 10 times.

Assuming that String is a reference type, it wouldn't be able to support Zero though; the closest thing would be an Option[String]; in the case of arrayZero[Option[String]](10) no initialization code would need to be run at all, as zeroValue of Option would be None, which in turn is represented as a null pointer.

from dora.

The array constructor Array[T](len) always initializes (zeros) the allocated memory. So we always initialize memory at least once. I think this is the step where we count differently.

With arrayFill or arrayDefault we then initialize the array with some value a second time. arrayZero would guarantee a single initialization, but I think this is something we might also be able to achieve with the compiler/runtime without providing a special function.

My argument is that many potential users can't use arrayZero anyways since e.g. T might not implement the Zero trait (e.g. Vec). That's why we should try to avoid the second initialization for arrayFill and arrayDefault if possible as well. As soon as we have that, there would be no use for arrayZero anymore.

from dora.

Is this done for good, @dinfuehr with your recent commits? :-)

from dora.

I think it's mostly done, there might be some cleanup needed but I guess we can close this already.

from dora.