add 2 argument Nullable constructor

[simonbyrne]

Arose in #11522, but probably good to have generally.

[johnmyleswhite]

LGTM

[nalimilan]

Any reason you chose (isnull, value) instead of (value, isnull)? Given that the one-argument version only takes value, I would find it more logical to keep it as the first argument.

[StefanKarpinski]

One argument is that it matches the storage order, but that's kind of an accident due to how we're using new to construct uninitialized values for non-bits types. This could also be reduced to a single definition with a default value if it was the other order.

[vtjnash]

One argument is that it matches the storage order, but that's kind of an accident due to how we're using new to construct uninitialized values for non-bits types. This could also be reduced to a single definition with a default value if it was the other order

we should probably make that change anyways. otherwise, for certain classes of large-ish immutable types T, we may need to waste some space to ensure alignment. and doing so is pretty easy:

 immutable Nullable{T}
     value::T
     isnull::Bool

     Nullable() = (x = new(); x.isnull = true; x)
     Nullable(value::T) = new(value, false)
 end
View

but this PR also seems to be an odd usage of Nullable. does it really make sense to have a two-argument constructor? that seems like a bad abuse of the type, since now you have an instance where isnull==true, but the data is (somewhat) still valid. in #11522 it seems like the actual goal might be to have a return tuple?

[johnmyleswhite]

One potential use case for the two-argument constructor: doing construction without a branch.

[StefanKarpinski]

I don't see why having isnull be true while the value is valid is a problem. @vtjnash, your version won't work since the Nullable type is immutable. You have to do this purely with new.

[StefanKarpinski]

It may be worthwhile to add language support for Nullable so that when the type parameter is not a bits type, it can be stored as a pointer and nullness is indicated by that pointer being null.

[johnmyleswhite]

I would love to have more language support for Nullables. I suspect we'll need a lot more built-in language support if we want to resolve things like #9446.

[ScottPJones]

Sounds good, the idea to be able to represent isnull true by a pointer being null... 👍

[vtjnash]

while that would allow you to use a slightly small gc sizeclass (

julia/src/gc.c

Lines 1115 to 1123 in 4a313de

	static const int sizeclasses[N_POOLS] = {
	#ifdef _P64
	8,
	#else
	4, 8, 12,
	#endif
	// 16 pools at 16-byte spacing
	16, 32, 48, 64, 80, 96, 112, 128,

) i'm pretty sure the added complexity would be not worthwhile.

unless you had some other idea for why this would be useful?

[simonbyrne]

Well, I rewrote the code to switch the argument order, but obviously it fails due to the issue @StefanKarpinski mentioned. Is there any way around this?

[simonbyrne]

One other reason for exposing the 2 argument version (with argument order matching the field order) is that it would allow use of general metaprogramming tricks like this.

[StefanKarpinski]

How about using this version:

immutable Nullable{T}
    isnull::Bool
    value::T

    Nullable() = new(true)
    Nullable(value::T, isnull::Bool=false) = new(isnull, value)
end

The storage order is just an internal detail – you'd have to write some very non-abstract code to expose the fact that the isnull field comes first.

[johnmyleswhite]

That suggestion is good by me.

[simonbyrne]

Okay, updated.

[nalimilan]

LGTM.

[prcastro]

Would be nice to have this documented