What grinds my gears about this, is that the other thread had lots of discussion and the overwhelming conclusion (from what I read – including agreement by the person who originally proposed it) was that it’s not worth adding complexity to the language (syntactically and for type inference) just to save a few keystrokes on defining collections. Yet here’s the idea moving forward anyway (and the reasoning smells a lot like “Well JavaScript does it”).
First off, there are several reasons why using square brackets for this is a bad idea: even if it doesn’t introduce syntactic ambiguity for the parser (is that assured?), it does add a big ol’ kink to the rules when you’re moving from C-ish languages to Scala – “square brackets are only for type parameters and type arguments; we don’t use them for indexing or collection-related things” gets an addendum of “except for collection literals – those are also square brackets”. What’s gained is not sufficient for the added confusion, IMHO.
More generally, special syntax for this or that isn’t going to move the needle for Scala. Being able to make examples look a little prettier isn’t going to help. Saving a few keystrokes in rare cases isn’t going to make a difference when people choose a language.
What’s going to make a difference are things like:
- Performance. As fast as Java (faster is better, of course!). Lower-cost abstractions.
- Tooling for the language. IDE support. Notebook support. Pleasant-to-use build tooling (and build tool integrations)
- Useful/understandable/actionable error messages. Out of the box, but also (especially) in weird type-astronaut API situations.
- Metaprogramming (Scala 3’s principled metaprogramming is really awesome, – and I would bet that the shared mechanisms between compile-time macros and staging capability is probably Scala 3’s “killer app”, if I were a gambler. Staging has a huge amount of potential in particular)
- Stability. Bincompat problems have held Scala back in the past. TASTy promised to solve this, but tools that really demonstrate the promise haven’t materialized.
IMHO, we need more discussion and focus on things like that and less discussion and focus on how syntax would make some cases look nicer or take fewer keystrokes. Keystrokes aren’t the problem, and syntactic changes that only save keystrokes by eliding explicitness are a distraction and an anti-improvement.
Folks who want a concise syntax for collections can just add Tuple conversions. This adds nothing to the language, prevents overloading square brackets, and allows concise syntax for creating collections inline.