Frist Draft (in this forum): Enum Parameters

[Steven Schveighoffer]

On Friday, 26 April 2024 at 09:39:52 UTC, Quirin Schroll wrote:
> On Friday, 26 April 2024 at 02:47:18 UTC, Steven Schveighoffer 
> wrote:
>> I have thoughts on reworking interpolation tuples if this got 
>> in...
>
> Please, elaborate. I was somewhat absent from the forums while 
> string interpolation took off. I read the docs, but it seems a 
> lot of regulars like you have a lot more intuition about where 
> interpolation tuples are useful. Not only could I use those 
> ideas in the DIP, I’m honestly intrigued because I can’t 
> imagine how they meaningfully interact.

I realize I forgot to expand on this.

In the current regime of 
[IES](https://dlang.org/spec/istring.html), the compile-time 
strings are preserved via an attachment of the literal data to 
the *type* of the parameter. This necessitates always taking the 
IES via vararg template, and also results in some more advanced 
techniques required for introspecting the data.

Compared to a blueprint-style function (like `writef`), it's much 
more complex to explain and use. But the benefit is awesome -- 
perfect rewriting of code is possible (via string mixin) as if 
you called the new code without doing any runtime parsing.

But if we have an enum parameter mechanism, the compile-time data 
can become a simple array of literal data, and you can accept it 
via a runtime parameter (if you prefer runtime parsing, and less 
template bloat), or via an enum parameter (if you prefer to parse 
at compile time).

I outlined my thoughts on it here: 
https://forum.dlang.org/post/ojotybtiosjikmmcxemw@forum.dlang.org

(there I also acknowledged that I didn't know about your previous 
DIP, and supported it)

-Steve