Inconsistency in constructing Dict and Array

[ingmarschuster]

Both Dict and Array are parametric types. Constructing a Dict and an Array of variable size differs markedly, though:
* Dict{TypeA,TypeB}()
* Array(Type) while Array{Type}() doesn't work
This creates some confusion for people new to the language – also I think its inconsistent design.

[diegozea]

Related to #2067

[amitmurthy]

Some other confusing (to me at least) behaviors:

julia> Int32[]
0-element Int32 Array

julia> NTuple[]
0-element NTuple{N,T} Array

julia> Tuple[]
ERROR: no method getindex((DataType,),)

and

julia> Array(Int32, 0)
0-element Int32 Array

julia> Vector(Int32)
ERROR: type: apply: expected Function, got Type{Array{T,1}}

[JeffBezanson]

Array{Type} is actually a partially-instantiated type (there is a second parameter for the number of dimensions), which currently means it can't have a constructor.

The T[] syntax did not always exist, and unfortunately tuple types are both types and indexable. But, you can't index a tuple with a tuple, so we could potentially define Tuple[Tuple...], distinct from Tuple[Int].

[ingmarschuster]

I can see why you might want to go wait until you can have constructors for partially-instantiated types; but maybe explicit is better than implicit here? Dynamically growing Arrays (Vectors in C++ lingo) are implemented really different from fixed-size Arrays (I didn't look at julias implementation but I guess it uses the conventional size & capacity book keeping?). Giving them a different name would make that very transparent, while functions can still be developed against a common abstract supertype.

[JeffBezanson]

There would be some advantages to having growable vectors separate from non-growable multi-dimensional arrays. But you would still be left without the syntax Array{T}(m,n) for constructing 2d arrays.

[ingmarschuster]

I think not having the syntax Array{T}(m,n) becomes a non-issue as soon as people perceive Arrays as being fixed size. Also Arrays will be used very rarely and only when people are pretty sure it wont grow in size - see Go arrays vs. slices ("Arrays have their place, but they're a bit inflexible, so you don't see them too often in Go code. Slices [Vectors in C++ lingo], though, are everywhere.", http://blog.golang.org/2011/01/go-slices-usage-and-internals.html)

[quinnj]

This should be affected by plans in #1470.

[JeffBezanson]

We have an update here! It is now possible to define constructors for Array{T} and Array{T,N}. They can also call convert, so for example we currently have

julia> Array{Int}([1.0,2.0])
2-element Array{Int64,1}:
 1
 2

I think it would be better to use Array{Int}(m,n) instead of Array(Int, m, n), but it does conflict slightly with the convert use above. Any suggestions on how to resolve this welcome.

[kmsquire]

Nice! How does it conflict? In Array{Int}(m,n), m and n are presumably numbers, and in Array{Int}([1.0,2.0]), the only argument is an Array, right? What am I missing?