On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote: > On Thu, 27 Oct 2011 13:53:02 -0400, Steve Teale > <[email protected]> wrote: > >> On Thu, 27 Oct 2011 13:09:43 -0400, Steven Schveighoffer wrote: >> >>> On Thu, 27 Oct 2011 12:58:57 -0400, Steve Teale >>> <[email protected]> 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
