NULL indicator in Variant

[Robert Jacques]

On Thu, 27 Oct 2011 14:06:47 -0400, Steve Teale <steve.teale at britseyeview.com> wrote:
> On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote:
>> On Thu, 27 Oct 2011 13:53:02 -0400, Steve Teale
>> <steve.teale at britseyeview.com> wrote:
>>> On Thu, 27 Oct 2011 13:09:43 -0400, Steven Schveighoffer wrote:
>>>> On Thu, 27 Oct 2011 12:58:57 -0400, Steve Teale
>>>> <steve.teale at britseyeview.com> wrote:
>>>>> On Thu, 27 Oct 2011 16:16:26 +0200, Alex Rønne Petersen wrote:
>>>>>> On 27-10-2011 15:50, Steve Teale wrote:

[snip]

> Well, yes, that was my first reaction, but I thought I'd ask - if there
> was a spare bit somewhere in Variant, would it do much harm, and Variant
> is getting a makeover. Maybe there are circumstances other than database
> interactions where it could be useful.
>
> Steve

Speaking as the one making over variant, let me see if I understand your use case. Similar to typecons.Nullable, you want to be able to test any type for isNull and be to 'nullify' any type. Correct?

Does nullifying a value wipe it clean? i.e. can you ever un-nullify something?

If you assign to a nulled variant, should there be some sort of special behavior?

Should 'hasValue' return false or true? If true, what should 'get' & company return?

'type' should return the TypeInfo of the type that was nullified, correct?

What should 'toString' return?

One thing that concerns me is the API. The new Variant supports reflection via opDispatch, so adding 'isNull' and 'nullify' members would, for example, block Nullable!int's 'isNull' and 'nullify' members. Would '__isNull' '__nullify' be acceptable? Alternatively, I could special case opAssign and opEquals: 'var = Variant.NULL' and 'var == Variant.NULL'. Thoughts?

Sorry for all the questions, but I want to make sure what I build is what you need. That said, I'm petty sure I can incorporate what you want.