enum Format

Nickolay Bukreyev buknik95 at ya.ru
Thu Jan 11 01:53:35 UTC 2024


On Wednesday, 10 January 2024 at 19:53:48 UTC, Walter Bright 
wrote:
> I may have found a solution. I'm interested in your thoughts on 
> it.

It looks very similar to what I presented in my later posts 
([this](https://forum.dlang.org/post/qiyrmzwnoguzxxllgzcz@forum.dlang.org) and one following). It’s inspiring: we are probably getting closer to common understanding of things.

> As far as I can tell, the only advantage of DIP1036 is the use 
> of inserted templates to "key" the tuples to specific 
> functions. Isn't that what the type system is supposed to do? 
> Maybe the real issue is that a format string should be a 
> different type than a conventional string.

Exactly. Let me try to explain why DIP1036 is doing what it is 
doing. For illustrative purposes, I’ll be drastically simplifying 
code; please excuse me for that.

Let there be `foo`, a function that would like to receive an 
istring. Inside it, we would like to transform its argument list 
at compile time into a new argument list. So what we essentially 
want is to pass an istring to a template parameter so that it is 
available to `foo` at compile time:

```d
int x;
foo!(cast(Format)"prefix ", 2 * x); // foo!(alias Format, alias 
int)()
```

Unfortunately, this does not work because `2 * x` cannot be 
passed to an `alias` parameter. _This is the root of the 
problem._ The only way to do that is to pass them to runtime 
parameters:

```d
int x;
foo(cast(Format)"prefix ", 2 * x); // foo!(Format, int)(Format, 
int)
```

However, now `foo` cannot access the format string at compile 
time—its type is simply `Format`, and its value becomes known 
only at runtime. So we encode the value into the type:

```d
int x;
foo(Format!"prefix "(), 2 * x); // foo!(Format!"prefix ", 
int)(Format!"prefix ", int)
```

This is more or less what DIP1036 is doing at the moment. Hope it 
became clear now.

I’d say DIP1036, as we see it now, relies on a clever workaround 
of a limitation imposed by the language. If that limitation is 
gone, the DIP will become simpler.


More information about the Digitalmars-d mailing list