NULL indicator in Variant

[Robert Jacques]

On Sat, 29 Oct 2011 16:23:11 -0400, Steve Teale <steve.teale at britseyeview.com> wrote:
> On Fri, 28 Oct 2011 23:50:37 -0400, Robert Jacques wrote:

[snip]

> I read through my answers again, and they seem to me to be perfectly
> valid responses to your questions. It's just that you are insisting on
> the use of terms like nullify and isNull that have different semantics
> than what is actually needed to deal with the database situation. Yes, I
> know I used NULL in my original question, but I was at pains to back of
> from that in my responses to your questions.
>
> I believe all that's needed to make variants play well with databases is
> a mark or flag. This could be used in other contexts for quite unrelated
> purposes. For the database case it would essentially serve as an ignore-
> this-value-just-note-the-type flag.

Steve, when you state: "For the database case it would essentially serve as an ignore-this-value-just-note-the-type flag", you are no longer describing your concept or use case, you are describing how you would implement that use case using functionality X.

 From what I can tell, you're thinking of an implementation like this:

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.