syntax: separate array concatenation from array construction

[StefanKarpinski]

Much gnashing of teeth derives from the overlap between syntax for array literal construction and array concatenation in Julia – largely inherited from Matlab. Perhaps we should just use a different syntax for block matrix construction entirely. One thought would be this:

| a b
  c d |

This has the advantage of being pretty terse and lightweight. For example, the current idiom of expanding a range into an array is [1:10] which would become |1:10| while [1:10] would construct a one-element array of type UnitRange{Int}.

[tkelman]

If breaking changes are being considered for this, I'll put in a vote for using an explicit delimiter here. Comma, semicolon, whatever. Not whitespace.

[StefanKarpinski]

Well, this would free up the ability to use an explicit delimiter instead of requiring using whitespace. It is still sometimes nice to use whitespace, although I guess we could avoid that since it's a bit of a parsing nightmare.

[JeffBezanson]

dup of:
#3737
#2488

related syntax discussion:
#6960

related:
#6491

[tkelman]

Inconvenience of one extra character per element for explicit delimiters is minor compared to the parsing inconsistency IMO

[StefanKarpinski]

It's not really a perfect dup of either of those, although it is related.

[JeffBezanson]

#3737 is an exact dup. Even the title is almost the same.

[jiahao]

|...| looks a bit too much like a determinant for my comfort. In the OP, I read | a b; c d | as a*d-c*b the first time round.

[quinnj]

As mentioned elsewhere, the {...} syntax could be made available since it's completely redundant anyway (can always use Any[...] instead). I like the thought of making curly braces actually useful!

[kmsquire]

+1 for making {...} concatenation (and making [ ] equivalent to Any[ ] instead of None[ ]).

[pao]

Consolidating from #7293, I'd like to see ways of constructing both N-vectors and Nx1 matrices, since we're distinguishing them.

[nalimilan]

Reclaiming {...} may be a good solution. [...] could actually keep its concatenating behavior, and {...} would become the non-concatenating version. This would be minimally disruptive since {...} is used less often, and it doesn't concatenate at the moment. (Plus, I find it more "intuitive" than the reversed roles, not sure why...)

[pao]

Plus, I find it more "intuitive" than the reversed roles, not sure why...

Perhaps it reminds you of C++11 initializer lists?