Simpler syntax for creating uninitialized arrays

[jkrumbiegel]

I find the syntax for creating uninitialized arrays a bit verbose, while there are nice and short options for almost all other common cases of creating arrays:

# compare to
Float64[1, 2, 3, 4, 5]
zeros(Float64, 10)
ones(Float64, 10)
fill(1.0, 10)

But for uninitialized arrays you always have to use curly bracket syntax if I'm correct:

v = Vector{Float64}(undef, 10)

How about one of these two alternatives, which both seem to be available:

v = Float64[undef, 10]
arr = Int32[undef, 3, 4, 5]

# or

v = undef(Float64, 10)
arr = undef(Int32, 3, 4, 5)

The second one is actually easy to get via:

(::UndefInitializer)(T::Type, dims::Vararg{Int}) = Array{T}(undef, dims...)

[jakobnissen]

See this issue and this Discourse discussion.

These posts are both very long and mostly discuss something other than your concrete proposal. However, there is at least one relevant point, namely that undef(Int, 10) returns an Array, when there are so many other AbstractArrays that could be usable.

Not sure I agree, though. The same could be said for zeros, ones and fill. Array still is by far the most used AbstractArray.

So think your proposed undef(T, dims...) syntax would be nice. It's short and explicit, and would probably be used quite often.

[martinholters]

would probably be used quite often.

...which might be a reason not to do it...

[yuyichao]

...which might be a reason not to do it...

It may be important to make the "uninitialized" part explicit, but I don't think it's necessary to make the syntax harder to use.

[JeffBezanson]

This is indeed somewhat intentional, to discourage uninitialized arrays. But we also wanted to move towards more general and regular syntax instead of all the special cases like zeros(...). The syntax undef(T, dims) is ok, but I question whether having more ways to write it is actually easier to use.

[timholy]

If we want to increase uniformity, one thought for 2.0: deprecate zeros, ones in favor of fill(v, axes), and consider allowing fill(Undef{T}, axes) for an uninitialized array with eltype T. (fill(T, axes) won't work because what if you want to create an array of types?)

[KristofferC]

deprecate zeros, ones

Wasn't this already discussed, cf JuliaLang/LinearAlgebra.jl#484?

[timholy]

I guess I'm consistent!

[StefanKarpinski]

I’ve actually often wanted a way to go in the other direction: factor out the initializer concept so that I can do things uniformly like this:

Array{T}(undef, m, n)
Array{T}(zeros, m, n)
Array{T}(ones, m, n)

Why? It makes it easier to swap out any of the properties of what’s being done: it cleanly separates the container type, the element type, what to initialize it with and the dimensions.

[tpapp]

Note also that while ones, fill etc make sense for most <: AbstractArray types, undef is the odd one out in the sense that is only practical for mutable arrays.

[KristofferC]

undef is the odd one out in the sense that is only practical for mutable arrays.

Not really, because in reality undef means uninitialized(which is what originally called). I made a PR to rename it to undef (shame on me) but in hind-sight, uninit would probably have been better.

[StefanKarpinski]

I think the point is that making an uninitialized immutable array isn't very useful.

[KristofferC]

Oh, yeah, I misread that.

[Sacha0]

Comet topic! :)

I’ve actually often wanted a way to go in the other direction: factor out the initializer concept so that I can do things uniformly like this: [...]

For interested newcomers to this discussion, #24595 (comment) discusses this direction at length as 'the second proposal':

The more general extension of this model is MyArray[{...}](contentspec[, modifierspec...]). Roughly, contentspec defines the result's contents, while modifierspec... (if given) provides qualifications, e.g. shape.

[StefanKarpinski]

One thing we could do is:

• make Array{T}(zeros, dims...) etc. work
• make undef(T, dims...) and undef(dims...) work

That way we round out the collection of convenience constructors in way that can always be expressed in terms of the fuller Container{Eltype}(initializer, dims...) form.