We are forking D

Walter Bright newshound2 at digitalmars.com
Mon Jan 8 02:10:03 UTC 2024


On 1/7/2024 3:45 PM, Timon Gehr wrote:
> Only if you pass the i-string as a template parameter (which might not even work 
> because any non-symbol expression will need to be evaluated at compile time but 
> maybe cannot).

Currently D internally supports non-trivial expressions as tuples. DIP1027 
relies on that, as:

```
int i = 4;
writefln(i"hello $(3 + i)");
```

prints:

hello 7

But, if the tuple is created with:

```
template tuple(A ...) { alias tuple = A; }
```

then a non-trivial expression cannot be passed to it, as it will not work as an 
alias parameter. This is a general shortcoming in D, not a specific problem with 
DIP1027.

We've been moving towards:

```
auto tup = (1, 3 + i);
```
for a while now, which is why comma expressions have been deprecated.

Amusingly, istrings can be used to create non-trivial expression tuples with this:

```
int i = 4;
auto tup2 = i"$i $(3 + i)"[1..3];
writeln("a tuple: ", tup2);
```

which prints:

a tuple: 47

I can't recommend doing things that way, but it just illustrates istrings as 
being a building block rather than an end product.

As for detecting string literals, I have tried a few schemes to no avail. It may 
have to be added with a __traits, which is where we put such things.

Trying that with DIP1036 means there are several more entries added to the 
tuple, which would have to be filtered out.


> Also, what do you do if someone nests multiple i-strings? DIP1036 handles it. 
> etc. The design is simple but it addresses many issues that authors of competing 
> proposals did not even think about.

Nested istrings would do the expected - create a tuple within a tuple, which 
gets flattened out. You'd likely wind up with a compile time error that there 
are too many arguments for the format. Recall that the istring is simply 
converted to a tuple, after that, predictable tuple rules are followed.

However, the nested istring can always be inserted as an argument to the `text` 
function which will expand it into a single argument, and no tuple twubble.

In general, you and I agree that D should move towards much better tuple 
support. DIP1027 fits right in with that, as it does no magic. Better tuple 
support will fit right in in extending istring power, rather than making istring 
itself more powerful.


More information about the Digitalmars-d mailing list