Soweit ich weiß, ist Unassigned eher für
OLE Zeugs - siehe auch Dokumentation, die da sagt:
Zitat:
Note: Unassigned is useful with variants referencing
OLE Automation Objects that you want to keep "alive" until another value is assigned to the variant.
Und da der Typ Nullable<T> und nicht Unassignable<T> heißt, machts
imho eher Sinn, Null zurückzuliefern, wenn der Nullable<T> leer ist.
Beim Hineingeben eines Variants sorgen sowohl Null als auch Unassigned (es wird mit VarIsNull or VarIsEmpty geprüft) dafür, dass es ein leerer Nullable<T> ist.
Allerdings muss sich beim herausgeben eines Variants für eins von beidem entschieden werden und da macht Null wie zuvor erwähnt eher Sinn.
System.Variants.Null()
liefert ein Variant, das bei seinen Casts immer "Null" zurückgibt. Auf eine Zahl ist es 0
, auf einen String ist es ein leerer String, auf eine Referenz ist es Nil
usw.
Dementgegen steht System.Variants.Unassigned()
: Das liefert einen Variant, der nichts ist. Man kann ihn nirgendwo hin casten, es steckt nichts drin.
Genau das Gegenteil ist der Fall, eine Zuweisung von Unassigned auf einen anderen Typ gibt immer den default Wert dieses Typs zurück (0, Leerstring, etc).
Bei Null gibts einen EVariantTypeCastError.
Ich hab meine Anwendung von der Verwendung von Variants auf TNullable umgestellt. Das hat problemlos funktioniert und macht den Code deutlich schöner.
Das freut mich, dass es so gut geklappt hat.