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