Add "Non-Standard Array Literals" by allowing juxtaposition of macro and array

[cdsousa]

TLDR: Please, allow parsing @foo[1, 2, 3] as a shortcut for @foo([1, 2, 3]).

Too many times, when using StaticArrays, I write stuff like

@SArray[1 2; 3 4] * v

which fails with ERROR: syntax: invalid macro use "@((typed_vcat SArray (row 1 2) (row 3 4)))"
I then add a space between @SArray and [1 2; 3 4] which also fails since the macro tries to consume the whole [1 2; 3 4] * v expression.
The right way to do it

@SArray([1 2; 3 4]) * v

It would be nice to be able to this without the parentheses...
Yes, I know, it's not that cumbersome to type two extra characters... but on the other hand, this syntax is available and making it work will hopefully not introduce many accidental bugs.

This could be seen as a kind of "Non-Standard Array Literals".
(related: #8934, #7128, #6960, #8892, #7128)

(Had I the knowledge of Julia parser I would open a PR instead of an issue, but I'm a null at scheme.)

[andyferris]

To me, non standard array liberals would be very useful and this is the shortest path to something reasonable.

[andyferris]

An alternative way of thinking of this is "what else could this syntax possibly mean?"

I doubt that expanding a zero-arg macro and using it as the element type would be very useful, and I can't think of any other contenders.

[cdsousa]

Yes, @andyferris , a zero-arg macro for element type can still be invoked the same way as it has to be now (as all zero-arg macros): @name()[1, 2].

[martinholters]

For StaticArrays, there might be an alternative approach: Overloading typed_*cat. However, that would require a slight change to typed_hvcat (and the respective lowering) to pass the rows information as a type rather than a value, i.e.

SArray[1 2; 3 4; 5, 6]

would need to be lowered to

typed_hvcat(SArray, Tuple{2, 2, 2}, 1, 2, 3, 4, 5, 6)

instead of the current

typed_hvcat(SArray, (2, 2, 2), 1, 2, 3, 4, 5, 6)

Not sure it's worth the effort of doing it (and the macro approach described here might still be wanted in addition), but I'd say it's worth thinking about.

EDIT: Ref. #16740 (comment)

[andyferris]

Yes we've discussed this before. We had concerns about extending what is already a pun on getindex even further, however it is still a viable option.

I definitely don't think SArray[...] is viable for a single static array because I often make Arrays of 3D points and we absolutely need to respect the predexisting interface.

This is possible with a placeholder e.g. sa object (not type) but seems slightly odd.

[martinholters]

I'm not 100% sure I understand your concern. Is it because you would like to create an Array of objects that should be converted to SArrays, which you presently do with SArray[obj1, obj2, ...]? My approach in #16740 was (besides leaving getindex alone because it seems to be used more often for this than the *cats) to allow e.g. Vector{SArray}[vec1; vec2; ...] (where vec1 and vec2 are Arrays already) for these kinds of operations. But yes, that would be a breaking change, so if you had a discussion before that this was not the preferred solution anyway, then it's obviously not worth it.

[andyferris]

That's right. For instance I already use SVector{3,Float64}[] to create an empty array of 3D points that I can push! to (actually, I more frequently tend to use Vector{SVector{3,Float64}}() but that's a distraction from my point). For better or worse, SArray[..] must obey the same semantic.

I think some general cleanups as in #16740 would be wonderful, and I really like the Vector{T}[] type of syntax - even if it is much more verbose for simple cases, it generalized to everything (including stuff which isn't a AbstractArray at all, like a dataframe or dict whatever).