What should we use unprefixed {} brackets for?

[ivarne]

#8578 deprecated the use of {} for cell arrays in favor of Any[]. That means we will soon have a new set of ascii brackets we can use for a different purpose. This is intended as a Wiki style issue to suggest and discuss different usages, so please help me keep this top post up to date. (I'm pretty sure there is multiple good ideas that I didn't think of now. )

1. Use them for Tuple types. (As suggested in what should we use { } for? #8470 and partially implemented in WIP: redesign of tuples and tuple types #10380)

2. Have them introduce a new block environment, so that they can be used instead of (in addition to) parentheses for grouping expressions.

   {(r-a)^2 + (r-b)^2 +(r-c)^2}^(1/2)

3. Use them to quote expressions, instead of :(), which has lots of parsing issues considering how overloaded the : operator is.

4. Use them to differentiate concatenating, vs. non-concatenating array literals. (Unfortunately this means that you probably want the ability to add a type prefix, which will have a syntax collision with types.)

[JeffBezanson]

Those are all decent ideas. 1 and 2 seem a bit wasteful; the main reason I like (1) is that curly braces would be very consistently associated with types.

(4) is pretty good. In fact this made me notice that there is an erroneous deprecation in place:

julia> {1 [2];
        3 [4]}

WARNING: deprecated syntax "{a b; c d}".
Use "Any[a b; c d]" instead.
2x2 Array{Any,2}:
 1  [2]
 3  [4]

julia> Any[1 [2];
           3 [4]]
2x2 Array{Any,2}:
 1  2
 3  4

As you can see, the suggestion doesn't do the same thing. In our current state there's no easy way to make a 2d array without concatenating, as some have complained about on the lists.

Using {} for concatenating would of course be the exact opposite of what it used to do. However I find it a bit odd to specify an element type when concatenating, so we could avoid a collision with type syntax there.

[simonster]

Maybe for (4) we could use [a b, c d] by analogy to the 1D case instead of repurposing {? Although that would also imply that to horizontally concatenate two matrices we'd need [a b;].

[mbauman]

Another argument for (1) is that tuple types are (currently) covariant. It makes sense that there'd be a special syntax for them — the suggested Tuple{} type would have to be unlike all other parametric types and magically covariant. I suppose that a more general approach could be taken here if there were a convenient shorthand for marking covariance… in which case I'd agree that it'd be a bit of a waste of a valuable ASCII pair.

That said, I could imagine using {} to be that convenient shorthand for covariance. If I'm understanding #8974 correctly, Array{{Real}} could desugar into @UnionAll T<:Real Array{T}. Then you could have something like:

julia> Tuple{Int, Float64} <: Tuple{Real, Real} # Invariant
false

julia> Tuple{Int, Float64} <: Tuple{{Real, Real}} # Fully covariant
true

julia> Tuple{Int, Float64} <: Tuple{Real, {Real}} # Only covariant in the second arg
false

julia> Tuple{Int, Float64} <: Tuple{Int, {Real}}
true

This also seems like an awfully specific use-case, though.

[StefanKarpinski]

That undermines the new (soon-to-be) clear separation between array construction and concatenation:

• commas are always for construction
• spaces, semicolons and newlines are always for concatenation.

This would put spaces back into the confusing "it depends on how you use them" category. Maybe that's ok. I guess that would mean that you would write these two:

[a b c]  # construct 1 x 3 matrix with elements a, b, c
[a b c;] # concatenate size(a,1) x (size(a,2)+size(b,2)+size(c,2)) matrix

[simonster]

Well, it would mean that the ,/;/newline distinction fully determines the concatenation rule and spaces have no effect, which I don't think is all that confusing. But I suppose the argument against is that if you write [a b], it's more likely than not that you want to concatenate, and the extra ; is a bit of an eyesore.

[Jutho]

I would like to refer to #10338 for the concatenation discussion. Even though I don't mind the current decisions, there are also some disadvantages to the rule

commas are always for construction
spaces, semicolons and newlines are always for concatenation.

But if a new bracket is used for concatenation, I don't think we need to scarify { ... } for it, [| ... |] is equally good no?

[JeffBezanson]

Array{{Real}} could desugar into @unionall T<:Real Array{T}

I don't see how that can work, since in Array{Array{{Real}}} it's not clear where the UnionAll goes.

Typically variance is specified where a type is defined, and not per use. So one can imagine that we've declared Tuple covariant, but that the ability to make that declaration is not generally available.

I do kind of feel it would be better to distinguish concatenation via brackets, rather than with spaces vs. commas.

[JeffBezanson]

As another point in favor of tuple types, I can imagine using them more in the future, for example for formatted binary I/O:

read(f, {Int, 16 * Float32})

Something like that requires special syntax inside { }.

[StefanKarpinski]

Yikes, I'm not entirely sure I like that. I would also favor writing this as {Int, Float32^16} if so.

[JeffBezanson]

Yes ^ is actually more appropriate.
I think there's a lot to be said for a very different use of {}, rather than throwing all the brackets we have at matrices.

[johnmyleswhite]

FWIW, I love the idea of formatted binary I/O.

[jiahao]

Closed by #10380

[Jutho]

Is it expected behaviour that {Int,Int} still creates a Array{Any,1} on latest master?

[tkelman]

yes, with a deprecation - which isn't working

[mbauman]

Fixed in #10860. I'll merge it once CI greenlights.