Warning: [a] concatenation is deprecated; use [a;] instead

[juliohm]

Julia Version 0.4.0-dev+3533
Commit f875a54* (2015-02-22 20:56 UTC)
Platform Info:
System: Linux (x86_64-unknown-linux-gnu)
CPU: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3

julia> [1:3]
WARNING: [a] concatenation is deprecated; use [a;] instead
 in depwarn at ./deprecated.jl:40
 in oldstyle_vcat_warning at ./abstractarray.jl:26
 in vect at abstractarray.jl:29
3-element Array{Int64,1}:
 1
 2
 3

Is this undesired syntax?

[jiahao]

The warning is correct for 0.4. See #3737 #8599 and the related issues regarding array concatenation syntax.

Please reopen if the warning is unclear.

[juliohm]

@jiahao, I did read the threads, but the change is still not clear to me. Could you please elaborate on the current syntax for what I'm trying to achieve?

[jiahao]

julia> [1:3;]
3-element Array{Int64,1}:
 1
 2
 3

Please note that 0.4-dev is considered not suitable for general use.

[juliohm]

How is the semicolon solving the issue here?

[jakebolewski]

[1:2] is an Array{Range,1} of one element, [1:2;] calls vcat which produces a Int[1,2]. The new default behavior is not to concatenate by default.

[juliohm]

Thank you @jakebolewski, I don't like the extra semicolon myself, but will assume Julia devs have a good reason for it.

[garborg]

@juliohm You may prefer collect(1:2). (I do at least, and there was some discussion in the PR comments about that being more correct, even though the deprecation message disagrees.)

[juliohm]

Thank you @garborg, will keep this option in mind.

[JeffBezanson]

I don't like the extra semicolon myself, but will assume Julia devs have a good reason for it.

The reason is so [x] always means to make a 1-element array with element x. Otherwise [x] would mean something strange like

if isa(x, AbstractArray)
  collect(x)
else
  a = Array(typeof(x),1); a[1] = x; a
end

In the long run we're better off with simpler more predictable abstractions.

[juliohm]

@JeffBezanson nice, KISS philosophy.