On Thu, 27 Oct 2011 14:06:47 -0400, Steve Teale
<steve.te...@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.te...@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.te...@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.
I don't like Variant having this behavior when it's only of specific use.
Variant is not a database-only type.
Here's another idea:
struct DBNull(T) { }
Where T is the type for the column. i.e.:
row.column = DBNull!int;
Now, you have your flag indicating it's null (you should be able to write
a function that returns whether the column is null or not), it doesn't
consume any more space (value is already part of a union that's bigger
than DBNull!int), and the type of field is still valid.
-Steve
