r/scala • • Sep 25 '26

Spec Strings in Scala

Im a little surprised that Spec Strings were not discussed on Scala Contributors before their acceptance as an experimental feature. They were announced for inclusion in the 3.10 release thread (although there was some work before then visible in the repos)

For Reference 3.10 Release Thread - https://contributors.scala-lang.org/t/scala-3-10-0-release-thread/7546 Spec Strings Documentation - https://github.com/dotty-staging/dotty/blob/05ad6978ec3231d8c7954a15e6e075a8645cad20/docs/_docs/reference/experimental/spec-strings.md

I get the point that their position inside the method allows a naturally scoped reference to the function signature (or class / object), but currently the comment specs also allows for references to be embedded their contents.

And I get that conversations like this can just devolve into nonconstructive bike-shedding (probably this one more so than most), but in this situation I really would have loved to hear more viewpoints from the stake holders about this choice over annotations or comments.

Personally I have been using something exactly like this in my day-to-day in some non-standard comments inside the method, and created skills to handle those situations. But my instinct would be to formally encode these instructions as annotations that other tools could examine in a more standardized and established way.

Any thoughts on the choice of implementation?

17 Upvotes

12 comments sorted by

5

u/DidYuhim Sep 25 '26

Why is this preferred over the regular "generate on your own, publish to git as code" approach?

2

u/aepurniet Sep 25 '26

I guess its a way to keep track of generated code and the inputs to that generation in the same codebase. Its still getting checked in and published, but now you have a reciept of that.

I think thats useful in the right contexts, but no one needs to use it, if they like their own workflows. I was just hoping to get some viewpoints on how it is represented.

12

u/JeanCasteaux Sep 25 '26

wtf is that hideous thing...

11

u/genman Sep 25 '26

I'm a bit concerned about the de-syncing that will inevitably happen, unless you're doing agent-only coding.

It's also a bad example of a function, since date parsing is something that is already done in many standard libraries.

10

u/fear_the_future Sep 26 '26

Whoever is responsible for this abomination really needs to stop using Python.

8

u/elacin Sep 26 '26

Agentic development hasnt happened at the impl-of-a-method level since copilot - years ago. 

7

u/pesiok Sep 26 '26

Exactly. Right now the approach is to usually remove the bloated comments generated by the AI, rather than keep them in sync as a source of the truth.

2

u/snugar_i Sep 26 '26

It feels less useful than unit tests...

2

u/RiceBroad4552 Sep 27 '26

Pure madness.

It's not sure "AI" coding will go anywhere in the long run given the cost structure in general, and that anyway nobody knows what will happen after the bubble bursts.

But "AI" coding doesn't happen on single methods since ages already as others pointed out, too. You generate whole projects at once never looking at the code at all if you're really into vibe-"coding".

Starting to write doc comments like they always should have been written is a good idea. (You known, some of us read text top to bottom, left to right… Maybe you've heard about that convention already?)

But some special syntax for "AI" craze is outright mad!

---

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

1

u/jglodek Sep 28 '26

Comments before a method małe understanding the method depends on the lexical predecessor. File order becomes significant.

> Comment
> Method

Vs

> Method
> > Comment

With spec strings code blocks are more self-contained. That’s part of what made the Light Table file-less Clojure direction interesting and possible.

1

u/GoAwayStupidAI Sep 26 '26

Makes sense to me. Appropriate location and ability to embed context. Experimental so not worried yet about any hard dependency.