Less verbose way of initializing a Nullable field to null

[amitmurthy]

This issue is to track and generate consensus on having a simpler method to nullify a Nullable field.

If we have a type with a large number of Nullable fields that we want to initialize with empty values:

type Foo
  x1::Nullable{Int}
  x2::Nullable{Bool}
  x3::Nullable{AbstractString}
...
end

the current method involves having the constructor as Foo() = new(Nullable{Int}(), Nullable{Bool}(), Nullable{AbstractString}().... ). For a large number of fields it involves matching the Nullable container type in the constructor and can be a bit painful.

See issues #9351, #8423 for the previous discussions about this.

[JeffBezanson]

I think my vote is to define null = Nullable{Union()}(), and rename the null function to nullspace.

Another possibility is nulled, which might make it clearer that this is a Nullable.

[amitmurthy]

nulled is good. Would address @johnmyleswhite 's concerns about folks returning null/NULL. And different from a C null/void.

[amitmurthy]

Linking #9356 - it will be good to have the same term for initialization as well as printing.

[johnmyleswhite]

I think adding null or nulled is a good strategy, although I'm very unclear about how Nullable{Union()}() works inside of the type inference system. Is Union(), by virtue of being unconstructed, processed specially during type inference?

[JeffBezanson]

It's just the empty set, so we naturally conclude that the set of values you can get from get(::Nullable{Union()}) is empty. This helps prevent it from polluting types, since it doesn't contribute any possibilities.

[RauliRuohonen]

@johnmyleswhite I'm not sure if you'd consider this a part of the type inference system, but if you wanted to know whether e.g. a field of type Union() inside a container takes no space since nothing can be stored there, the answer is no. In particular, sizeof(Nullable{Void}) = 1 but sizeof(Nullable{Union()}) = 16. This is because sizeof(Void) = 0 but sizeof(Union()) = 8.

[JeffBezanson]

We could probably improve this to also avoid storing fields of type Union(). It never really came up before this.

[nalimilan]

+1 for null = Nullable{Union()}(). As @RauliRuohonen mentioned at #1090 (comment), with return type declarations return null could be made efficient, thus making null a good solution represent a missing value in various contexts.

[johnmyleswhite]

Ok, I'm onboard with null = Nullable{Union()}() now. Given Jeff's point about how the union doesn't propagate further into the type inference system and Rauli's point about the eventual possibility of forcing conversions using return type declarations.

This still leaves the original question of shorter syntax for nullable fields in types and also the related question of achieving shorter printing for nullable values in #9356 .

[nalimilan]

Ok, I'm onboard with null = Nullable{Union()}() now. Given Jeff's point about how the union doesn't propagate further into the type inference system and Rauli's point about the eventual possibility of forcing conversions using return type declarations.

Hey, we are constantly progressing towards a successful consensus! :-)

This still leaves the original question of shorter syntax for nullable fields in types

I don't think so. With null = Nullable{Union()}(), one could write Foo.x1 = null instead of Foo.x1 = Nullable{Int}(), right?

and also the related question of achieving shorter printing for nullable values in #9356 .

Right.

[amitmurthy]

I am actually OK with the syntax of specifying it. I was more concerned with initializing it to null - the title is misleading.

I guess printing too can print null.

[johnmyleswhite]

Ah, ok. I thought you wanted something like:

type Foo
  a::Int?
end

[amitmurthy]

That would be nice too. :-)

[rfourquet]

I also felt the need to initialize Nullable fields less verbosely in new, so would too like that new(null, null,...) works. But not only: when seeing Nullable as a container, it would make sense to extend null-initialization (or default-initialization) to general containers, e.g.

type Bar
    a::Array{Int,1}
    b::Dict{Int,String}
    ...
    Bar() = new(default, default,...) 
    # instead of: new(Array(Int,0), Dict{Int,String}(),...)
end

Admitedly this doesn't happen as often as with Nullable, but often enough that I found it boring and error-prone (when prototyping and changing one type of container for another). Maybe using null for default wouldn't be too confusing, I guess it would only take to define:
convert{T}(::Type{Array{T,1}}, null) = Array(T,0) etc. It could even be pushed further by forwarding arguments, via a Args type: Bar() = new(Args([1, 2, 3]), Args()).

[johnmyleswhite]

That seems a little too magical for my tastes.

[nalimilan]

@JeffBezanson "My opinion is heavily that way". :-)

I really prefer null to nulled, except if that's only intended as a stopgap until the deprecation period for null is over.