small inconsistency in zero-arg array constructors

[Sacha0]

The zero-argument constructor for Vector works with and without type specification:

julia> Vector{Int}()
0-element Array{Int64,1}

julia> Vector()
0-element Array{Any,1}

whereas the zero-argument Array constructor (which returns an uninitialized zero-dimensional Array) requires type specification:

julia> Array{Int}()
0-dimensional Array{Int64,0}:
73

julia> Array()
ERROR: MethodError: no method matching Array()
Closest candidates are:
  Array(::T<:Array) where T<:Array at array.jl:458
  Array(::UniformScaling, ::Integer, ::Integer) at linalg/uniformscaling.jl:383
  Array(::UniformScaling, ::Tuple{Int64,Int64}) at linalg/uniformscaling.jl:384
  ...

This inconsistency (naively) seems more or less harmless, and throwing a MethodError rather than returning something seems like a future-proof position. But this inconsistency initially surprised me, hence this issue. Thoughts?

[JeffBezanson]

We can probably lose Vector() since [] does the same thing.

[rfourquet]

But the problem with Vector is that it's a special case of Array on one hand, but also the go-to container where dimensionality is irrelevant on the other hand. Then, Vector() is consistent with Dict() or Set(), and I think it should remain. This point has been raised in an issue some month ago, but can't find it now.

[Sacha0]

This point has been raised in an issue some month ago, but can't find it now.

Found the discussion re. deprecating the zero-argument Vector constructors in #20330 and #22717. That discussion strongly suggests keeping those constructors around. (Thanks @rfourquet! :) )

Relevant thought from #24778 (comment):

I suppose Array{T}() is the integer-series-accepting equivalent of Array{T}(()) / the base case for integer-series-accepting Array constructors. With the Array(shape...) -> Array(uninitialized, shape...) transition (ref. #24595), the tuple form Array{T}(()) becomes Array{T}(uninitialized, ()), and the higher-dimensional integer-series-accepting form Array{T}(ints...) becomes Array{T}(uninitialized, ints...), leaving Array{T}() an odd case. Array{T}(uninitialized) would be the consistent replacement...

... and would better separate the zero-argument Array and Vector constructors. (Note that Array{T}() returns uninitialized memory (a single value), whereas the zero-arg Vector constructors do not.) Thoughts? Thanks!

[Sacha0]

Investigating a bit further reveals that, in the Array(shape...) -> Array(uninitialized, shape...) deprecation, Array{T}() will automatically deprecate to Array{T}(uninitialized) alongside the other constructors in that family, making this inconsistency more or less negligible. Hence closing. Thanks all!