NULL indicator in Variant

[Steve Teale]

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:
>>>>>>>
>>>>>>> Surely Variant.init should do the trick?
>>>>>>
>>>>>> Dmitry,
>>>>>>
>>>>>> Are you talking about the new std.variant - I don't see 'init'
>>>>>> currently.
>>>>>>
>>>>>> Steve
>>>>>
>>>>> He is probably referring to the 'init' property on the *type*, i.e.
>>>>> int.init and so on.
>>>>>
>>>>> - Alex
>>>>
>>>> Same catch 22. In order to have an init property, the Variant would
>>>> have to have been set to some type, at which point hasValue() would
>>>> say yes.
>>>>
>>>> Steve
>>>
>>> import std.variant;
>>>
>>> void main()
>>> {
>>>      Variant v = 1;
>>>      assert(v.hasValue());
>>>      v = v.init;
>>>      assert(!v.hasValue());
>>> }
>>>
>>> -Steve
>>
>> Exactly, and v has reverted to being typeless:
> 
> Sorry to jump in mid-stream, but you seemed to be suggesting Variant
> didn't have an init without an assigned type.

No, I was just saying it didn't help.

> Why wouldn't you just wrap variant if you want to introduce a nullable
> variant type?  Why does Variant have to be muddied with requirements for
> database API?  Database null is an entirely different animal from D's
> null.

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