> 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>". _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel