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?
We can probably lose Vector() since [] does the same thing.
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.
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 https://github.com/JuliaLang/julia/issues/24778#issuecomment-346958358:
I suppose
Array{T}()is the integer-series-accepting equivalent ofArray{T}(())/ the base case for integer-series-acceptingArrayconstructors. With theArray(shape...)->Array(uninitialized, shape...)transition (ref. #24595), the tuple formArray{T}(())becomesArray{T}(uninitialized, ()), and the higher-dimensional integer-series-accepting formArray{T}(ints...)becomesArray{T}(uninitialized, ints...), leavingArray{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!
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!
Most helpful comment
Investigating a bit further reveals that, in the
Array(shape...)->Array(uninitialized, shape...)deprecation,Array{T}()will automatically deprecate toArray{T}(uninitialized)alongside the other constructors in that family, making this inconsistency more or less negligible. Hence closing. Thanks all!