[fpc-devel] "Default" discussion for SmartPointers etc

[Stefan Glienke]

> Well, I think this addition is not necessary, maybe even dangerous.
> I can live with the 'ascetic' version :-)
> 
> Since the following:
> 
> Procedure SomeTest(Var X : Integer);
> 
> begin
>    X:=1; 
> end;
> 
> Var
>    A : TNullable<Integer>;
> 
> begin
>    SomeTest(A^);
> end.
> 
> Will lead to a crash on a null value, I don't think this is a very good idea
> to add.
> We should protect users from crashes, not expose them to it :-)
> 
> So, currently balance for me, if I understood everything correctly:
> [+] Implicit constructor/destructor.
>      Good for simulating 'managed' types.
> [+] Default field (even if it is only syntactic sugar)
> [-] ^ dereference magic: a no-no :)

I agree with Michael here. While in Spring4D our nullables have the implicit
operator in both directions in retrospective I think it's not a good idea and
the nullable<x> -> x conversion should be explicit (with the possibility to
raise an explicit exception - not an AV) and for sure not be faked by the deref
operator because a nullable is not a reference type in my book even if it can be
null (err nil?) That btw leads to another question - is the "null" state equal
to nil - or is it something different. So a nullable is kind of both things, it
can be nil/null but if not it contains the value but does not point to it thus
cannot/should not be deferenced. C# for example requires a hard cast or the call
to .Value to get the underlying value from a nullable with the possibility to
throw a InvalidOperationException if it has no value.

FWIW if you make it a new language construct I actually would prefer "nullable
of <type>" which is consistent with "array of <type>" or "set of <type>".