Thanks everyone for contributing to this thread - it is so nice to see all engaged replies into this hot topic. As the rate of incoming comments tend to slow down I think it might be good to try to do a quick summary of the main pros and cons from the above discussions on introducing (Python-like) collection literals. (Let me know if I missed some important pros/cons.)
Regarding the concept of collection literals:
Pros:
- Conciseness and ergonomics. Many argue that collection literals combined with target typing and a default collection target will make constructing collections more readable and higher level (no implementation details shown).
- Support adoption of Scala. Developers are already familiar with this from other languages.
Cons:
- Risk of bugs/issues when being non-explicit about the collection type.
- There are already ways of doing this. Adding more ways of doing the same thing is not good. This may co-inside with the narrative of “Scala having too many ways of doing things” and thus hamper adoption.
- Risk for tooling evolution, esp. in terms of interaction with other language constructs and increased complexity in grammar/semantics. There are problems with implementing this in IDE:s and it may mean that resources are forced to be spent on this rather than more important things.
Regarding the surface syntax based on brackets specifically:
Pros:
- Similar to other languages. Developers can continue with known syntax.
- More concise than apply-syntax. In nested structures the benefit of conciseness is amplified.
Cons:
- The bracket syntax is alien to Scala in term position. Brackets currently have a clear devotion to types. Confusing this may actually hamper learnability and adoption.
- The similarity to other languages is dubious as one may assume semantics that are actually false in Scala.
- The bracket syntax compete and interacts with the tuple syntax. Why not use tuple syntax instead, as it is more native to Scala in term position?
- Risks of splitting the community and code-bases between apply-syntax and bracket syntax.
My current, personal view, given all the insightful discussions here, is that, if doing the pros/cons tradeoff then bracket-based syntax is probably not worth it, but tuple-based syntax might be (we would benefit from a solution to the Tuple0 and Tuple1 syntax problem anyway…). But we would need extensive experimentation and investigations on feature interaction e.g. with named tuples etc. in order to validate that it’s worth it.