NULL indicator in Variant

[Steve Teale]

On Sat, 29 Oct 2011 17:42:54 -0400, Robert Jacques wrote:
> 
> Variant var = 1;
> var.mark = true;
> 
> if(var.mark) {
>      // Do DB NULL stuff
> } else {
>      // Do DB value stuff
> }
> 
> But how is that different from this:
> 
> Variant var = 1;
> var.nullify;
> 
> if(var.isNull) {
>      // Do DB NULL stuff
> } else {
>      // Do DB value stuff
> }
> 
> or this:
> 
> auto var = Variant.NULL!int;
> 
> if(var.hasValue) {
>      // Do DB NULL stuff
> } else {
>      // Do DB value stuff
> }
> 
> or this:
> 
> auto var = typeid(int);
> 
> if(auto type = var.peek!TypeInfo) {
>      // Do DB NULL stuff
> } else {
>      // Do DB value stuff
> }
> 
> ?
> 
> I don't care about adding functionality X; you can already build a
> null-able DB type on top of Variant (see above, or use Nullable!Vairant,
> etc). I care about making variant (or Algebraic) _into_ a null-able DB
> type. So that it composes integrates well with the rest of our
> code-bases.
> 
>> It is not essential, but it would make a database interface using
>> variants easier to code and to use. Probably we should just forget the
>> idea.
>>
>> Steve
> 
> Databases and their ilk are a pretty big and important use case. So I
> think cleanly supporting them is necessary. That said, there are lots of
> alternatives available.

Robert,

I guess I was reacting to your worry about the std.typecons Nullable!T, 
and Steve S's objection to 'muddying' Variant by including specifically 
database oriented stuff. A simple mark seemed more general purpose and 
possibly more acceptable.

>From your examples, I like

Variant var = 1;
var.nullify;

if(var.isNull) {
     // Do DB NULL stuff
} else {
     // Do DB value stuff
}

As long as when it is nullified I can still use var.type and get int.

I take it that in the case of this example hasValue() would signify that 
the Variant was 'raw' - we don't really have uninitialized in D.

Steve