On Thu, 27 Oct 2011 19:06:47 +0100, Steve Teale
<steve.te...@britseyeview.com> wrote:
On Thu, 27 Oct 2011 13:58:54 -0400, Steven Schveighoffer wrote:
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.
Could you wrap std.typecons.Nullable around it? It's currently disabled,
but a quick copy/paste into my own src, plus templating the opAssign e.g.
/**
Assigns $(D value) to the internally-held state.
*/
void opAssign(T value)
{
enforce(_value);
*_value = value;
}
and this works:
import std.exception; //nullable
import std.variant;
import std.stdio;
void main()
{
Nullable!Variant a;
assert(a.isNull);
a = 5;
assert(!a.isNull);
assert(a == 5);
}
I believe Nullable is going to be re-enabled soon?
One argument in the nullable pull request:
https://github.com/D-Programming-Language/phobos/pull/153
which also applies, is; why not just use Variant*'s in your database
cases?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/