[fpc-devel] "Default" discussion for SmartPointers etc
sglienke at dsharp.org
Thu Jul 28 17:03:07 CEST 2016
> 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);
> A : TNullable<Integer>;
> 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>".
More information about the fpc-devel