I already did that, kind of! A library solution is mostly adequate.
The strategy I took was to define a slice as an opaque type in a Long–yes, this means that you can’t stride, but those cases are comparatively rare–and have one type being “collection relative” where if you want to be relative to the end you use End. Then I decorated Array with a ton of methods that take these.
It’s quite nice! I rarely miss Python slices any longer. Because I have to evade existing names, it’s not quite perfect.
But all over my code now I have things like
val ys = xs.select(1 to End-1)
ys.edit(3 to 10): (y, i) =>
if y*i > 10 then -y else 2*y
ys(End-5 to End-2) = 0
ys(_ < -2) = -2
Anyway, my conclusion from this is that you don’t really need the language to do anything for you. Regular syntax is enough unless you actually want to just copy the exact Python syntax so you don’t need to relearn it. Otherwise, I find 3 to End a lot clearer than 3:.
(If one wanted to intercept the usual 1 to 5 by 2 syntax of ranges via a macro, one could also do that. I find it still a bit too much work to make everything a macro, so I did without.)
Having in-line XML in Scala made my keystone Scala project possible. Having in-line JSON would be amazing. I’ve worked many projects that needed short snippets of these standard external formats for communicating with other systsems. Maybe if this feature were packaged up as part of full support for JSON in Scala it would be more attractive. Just checking json"{...}" format at compile time would be valuable.
However, something that “kinda acts like JSON” but isn’t “paste in JSON” doesn’t provide that value, and has none of the appeal. A non-standard, internal format doesn’t fit this common use case as well as json"".
In contrast Seq(a,b,Seq(c,d)) structures have worked really well when I’m teaching. The better students hit command-B on Seq and discover apply() methods. ("What the heck is unapply()? " - it’s been that good.) Square brackets offer far less for them to find, especially if some unseen implicit holds everything together. Adding a 1991 Python feature I think takes teaching the wrong direction.
The other big use case discussed is build systems. Bleep uses a .yaml file for input - and simple Scala trait implementations for its plugins. The kids have no problem switching between the two. Bleep is a joy to use for projects that fit in its nascent ecosystem. Maybe an external .yaml file for lists of common things is a better general path forward for the build system use case.
It depends on what you mean by checking. Just checking syntax is not enough. I don’t know JSON very well but in XML you have schemas that you can validate against. In Scala this would be done by type checking against a type ascription:
val x: MyCaseClassOrCollectionThereof = json"{...}"
I’m not sure how this could be done concretely, without substantial macro machinery, and even then, do we have expected type information in macros? Again, I don’t know enough of macros to tell.
Well they came across to me as a voice of reason. I believe we have evolved as a species to solve problems through diverse personality types. So even if you are disposed to see the negative over the positive, its always good to have at least one person with that disposition in a decision making group.
So I would say please keep up the snarkiness, even though I don’t doubt that down the road, it will be one of my bright ideas, that you’re throwing cold water on.
As someone outside the main contributors circle, it seems like Scala has gone from one extreme to the other. For years it seemed virtually impossible to get anything changed. Now everything has to change and by last week to. In the past it seemed that everything was sacrificed on the alter of “simplicity” and orthogonality, no special case could ever be considered. Now it seems like every special case under the sun must be catered to.
Its good that we realised that people don’t want simple languages. I never believed that the attacks on Scala’s complicatedness were made in good faith. But its as if we’ve done an about turn and are now deliberately trying to make the language more complicated.
Code and Data are different. Code needs a higher level of verbosity than Data, because Code can be anything, whereas Data can be succinct because the user of the data, knows what it means, knows the types of the Data that are being parsed.
(This is all a bit of a tangent from Collection Literals at this point.)
We demonstrated “just checking the format” for XML was very valuable for projects with lots of little, boring snippets of XML. Those are more rare in 2025, out-competed in the ecosystem by smaller, still boring snippets of json.
We have a healthy ecosystem of libraries for processing json. I agree that handling json really should be in the province of those libraries, even at compile time.
I think tasks to support that work would add more value than the proposal here might add.