I’d like to see something like this proposal. I’d been following that pre-SIP but was rather dismayed by so many negative comments.
I respect those who urge caution to be sure that it’s not too hard to implement in the tooling - smooth-running metals etc. is very important. But it’s a pity to see all those remarks like “we shouldn’t put data in code”.
I’m a scientist, I make an interactive climate / socio-scenarios system model. It now works in scala.js (even wasm), but was derived from a java applet, evolving over 25 years.
This is real world stuff, there are many small sets of ‘constants’ (not user data) with irregular structures, setting up gases and aerosols, regions, socioeconomic sectors, sources of energy, land use biomes, pledge (NDC) definitions, parameter sets tuned from other models and scenarios, etc. etc. Of course the model loads big historical datasets separately, but small sets of numbers should be in the code where it’s easy to see and adjust them (real world and science changes…), that’s an essential part of the transparency. And don’t tell me to put these within multi-line strings, then the compiler doesn’t check the structure, so we’d get runtime errors instead (scala is great - because when once it compiles, it just works).
As noted in the discussion, there are various workarounds with aliases, which I use, but it could be neater.
A related topic that was on scala-contributors which I’d like to see reopened is multi-level (nested) enums, for similar reasons. To get around the limitations of enums, I recently started to write my own macros, which works but … (another story…).