Personally I’m strongly opposed to this proposal, as is, for a few reasons:
-
It’s re-purposing an existing keyword in a weird way.
usingis kinda-sorta tangentially related to one particular use case of what we’re trying to do here, just likeimport $is kinda-sorta tangentially related to one particular use case of what Ammonite does. But it’s different enough that it seems like it would cause confusion, not unlike how we used to use underscore_for a bunch of scenarios that were kinda-sorta related -
It doesn’t look like Scala.
scala "3.1.2"does not look like valid Scala syntax at all.someSettings { setting1 value 1; setting2; }is technically valid Scala syntax, but is in the style of odd DSLs. It looks like Kotlin or Groovy with their convention of builder DSLs, but those aren’t ubiquitous in the Scala ecosystem. -
The fact that it looks similar to Scala expressions at all is misleading. Can I import stuff? What’s the evaluation order? Can I define
vals/defs/classes and so on? I assume not, and that this stuff would get statically inspected as metadata, rather than evaluated as code. This means the syntax is actively misleading people into thinking it’s Scala expressions, when it’s not
Overall, I think it looks about as smoothly integrated as Ammonite’s magic imports, and neither fits well enough into Scala that I’d be happy including them in the language.
TBH, if we want a way to associate metadata with Scala files, that sounds a lot like the existing way to associate metadata with pieces of Scala code: an annotation. I think some annotation-like syntax using @ would be a lot better than the using syntax proposed above. We’d need to finesse the syntax in order to make it unambiguous and ergonomic, but I think it can be done and result in a much more familiar user experience. This applies to people coming from any language, as most languages have some sort of annotation-like syntax for associating metadata with code, and that’s exactly what we want to do here.