Feature Request: allow default values for unspecified type parameters

[kmsquire]

In #4038, I updated Dict to have a third type parameter, specifying whether the Dict should be Ordered or Unordered[1]. This allows one to create an OrderedDict with

julia> Dict{String,Int,Ordered}()
Dict{String,Int64,Int64}()

However, in order to create a normal Dict, I also need to specify Unordered:

julia> Dict{String,Int,Unordered}()
Dict{String,Int64,Nothing}()

julia> Dict{String,Int}()
ERROR: type cannot be constructed

I'd like to be able to simply specify Dict{String,Int}(), so that existing code continues to work unchanged.

This would seem to require the ability to specify a default value for a type parameter, or have it default to Any. Possible?

CC: @JeffBezanson, @StefanKarpinski

---

[1] It's irrelevant here, but Ordered is a type alias for Int64, and Unordered is a type alias for Nothing.

[JeffBezanson]

This is one reason some types (like Array) avoid curly braces. For example, one can define

Dict(K,V) = Dict{K,V,Unordered}()

and then you almost have what you want.

This is a difficult change, since typically type parameters can be left "unspecialized" by leaving them off (e.g. Array{Int} for arrays of Int of any dimension). It might make sense for types to be able to opt-out of that behavior and specify defaults instead, but I'm not sure.

[kmsquire]

typically type parameters can be left "unspecialized" by leaving them off

This is only when used, e.g., in function signatures, right? Ideally, I'd like to be able to keep this behavior (so that someone could pass an ordered or unordered Dict to a function), but allow defaults to be specified only for type construction.

[JeffBezanson]

Currently there is no distinction between type construction inside function signatures and anywhere else.

[StefanKarpinski]

If Dict{K,V} were a type constructor in the same way that Dict is, then wouldn't that help the situation? In essence, this would make Dict{} mean the same thing as Dict does. Note that this is not the same thing as having defaults for type parameters, although that could be taken to mean that, e.g., Dict{K,V}() = Dict{K,V,Unordered}() should be supplied as a method by default, or something like that. But that's a separate issue.

[kmsquire]

For construction, I can't leave a type unspecialized, can I?

julia> type TestType{A,B} end

julia> TestType{Int,Int}()
TestType{Int64,Int64}()

julia> TestType{Int}()
ERROR: type cannot be constructed

[kmsquire]

I would be quite happy with being able to specify Dict{K,V}() = Dict{K,V,Unordered}(). That would amount to allowing users to explicitly create/call functions parameterized with types, right?

[JeffBezanson]

It is possible to make a partially-specialized type like TestType{Int} a generic function, so that methods can be added to it. However this is quite weird, and causes a lot of unpleasantness. The simplest issue is that the syntax Dict{K,V}() = ... is taken and already means something else.
I guess this is another case where one wants to define apply{K,V}(::Type{Dict{K,V}}).

[StefanKarpinski]

I was going to write something along the same lines, but you beat me to it.

[kmsquire]

Dict{K,V}(...) is defined only for the base type, and for when the ... contains arrays or other things from which the values of K and V can be inferred, right?

For my modified Dict, then, Dict{K,V,O}() is defined for the base type, but there's no definition for Dict{K,V}() (with no passed parameters)... if this were possible, I wouldn't have opened this issue. ;-)

[kmsquire]

But apply{K,V}(::Type{Dict{K,V}}) would be useful as well.

[kmsquire]

The simplest issue is that the syntax Dict{K,V}() = ... is taken and already means something else.

The point I was trying to make is that I don't believe this is defined explicitly as such (with no parameters), but only as the default type constructor.

[JeffBezanson]

#1470 will make it possible to define constructors for partially-specified types, which seems to be the best way to resolve this.