@compat for (e.g.) Vector{Int}()?

[sbromberger]

Hi,

Currently in 0.3.x

julia> q = Vector{Int}()
ERROR: type cannot be constructed

Any way to get this working in 0.3?

[garrison]

see also JuliaLang/julia#11154, where the Vector{Int} constructor was added.

[garrison]

and the related julia-users thread

[garrison]

In any event, I have been planning to add Compat support for these constructors but have been fairly busy lately, and I expect to be busy/unresponsive the next two weeks. Feel free to beat me to it. Some documentation for these constructors should also be added to julia once the julia-users thread pans out.

[sbromberger]

@garrison thanks. I might take a shot at it next week but I doubt my attempt will be as good as yours would be.

I think the julia-users thread has run its course, and unfortunately (for me, anyway) there hasn't been a declaration. I'm still left wondering what the go-forward, preferred method of constructing an empty vector is / will be. If it's Vector{Int}(), then I can feel comfortable trying to get this into Compat. If, however, this is NOT the best way to do it, then I'd much rather try to get the preferred method in.

I hope this rambling makes a little bit of sense.

[StefanKarpinski]

We should definitely have this in Compat. If you want a really future-proof way to construct an empty vector of a given type, Array{Int}(0) is the safest possible thing – I can't see that going away.

[sbromberger]

@StefanKarpinski thanks very much for your comment. If I'm interpreting it correctly, it means that Vector{T}() is the go-forward Julian way to create an empty vector, and that the other methods (T[], ...) are "ok but not preferred"?

(or, on second read, does it mean that Vector{T}() is not as preferred as Array{T}(0)? Or is Vector merely syntactic sugar that can be relied upon?)

[StefanKarpinski]

No, I'm just saying that if you want to be maximally sure that you don't ever have to change your code, use Array{T}(d1, d2, ...) – that form is not going anywhere. The Vector{T}(d1) thing is very nearly as safe, although it's slightly odd that the number of dimensions and the Vector name are redundant. The Vector{T}() form with no arguments strikes me as a little fishy – why is zero the default dimension size? Similarly for Matrix{T}() giving a 0x0 matrix of element type T. You can certainly use the T[] syntax for now, and who knows, it might stay, but the indexing into a type syntax pun is kind of unfortunate so I suspect we might come up with something better at some point.

In short, if you're ok with potentially changing your code in the future when you get deprecation warnings, then use whatever syntax you prefer. If you really want to avoid that, use Array{T}(0) for T[].

[sbromberger]

Perfect. Thank you very much!

[sbromberger]

Ok, just FYI, this is dev+4739.

... and I have absolutely no idea how to do this without call :)

[stevengj]

You would write a macro, so that @compat Vector{Int}() gets left as-is in 0.4 and in older versions gets transformed to Array(Int). It's no problem to do this via a macro because Vector{Int}() still parses in older versions, even if it cannot be compiled.

[sbromberger]

Thanks. I've never written a macro before. Perhaps this is a good opportunity to figure it out.

[stevengj]

See the existing macro compat in the Compat package; it already does several transformations of this sort, so you would just be adding one more.

[sbromberger]

Does this work for the array rewrite? (This is my first attempt at metaprogramming; my tests seem to work but there may be edge cases).

I don't know where to put this, in any case.

Vector appears to be a :ref instead of a :call so there will likely need to be another function.

function rewrite_arr(ex)
    f = ex.args[1]
    if isexpr(f, :curly)
        head = ex.head
        args = [f.args[1:2], ex.args[2:end]]
        return Expr(head, args...)
    else
        return ex
    end
end