Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Less verbose way of initializing a Nullable field to null #9364

Closed
amitmurthy opened this issue Dec 15, 2014 · 16 comments
Closed

Less verbose way of initializing a Nullable field to null #9364

amitmurthy opened this issue Dec 15, 2014 · 16 comments
Labels
needs decision A decision on this change is needed
Milestone

Comments

@amitmurthy
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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

@amitmurthy
Copy link
Contributor Author

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

@johnmyleswhite
Copy link
Member

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
Copy link
Member

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
Copy link

@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
Copy link
Member

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

@nalimilan
Copy link
Member

+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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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.

@amitmurthy amitmurthy changed the title Less verbose way of specifying an empty Nullable field Less verbose way of initializing a Nullable field to null Dec 22, 2014
@johnmyleswhite
Copy link
Member

Ah, ok. I thought you wanted something like:

type Foo
  a::Int?
end

@amitmurthy
Copy link
Contributor Author

That would be nice too. :-)

@rfourquet
Copy link
Member

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
Copy link
Member

That seems a little too magical for my tastes.

@ihnorton ihnorton added the needs decision A decision on this change is needed label Jan 6, 2015
@ihnorton ihnorton added this to the 0.4 milestone Jan 6, 2015
@nalimilan
Copy link
Member

@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.

JeffBezanson added a commit that referenced this issue Feb 18, 2015
JeffBezanson added a commit that referenced this issue Feb 18, 2015
add help for nothing and Nullable

ref #9364
alternative to c966812
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

7 participants