Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Andrei Alexandrescu]

On 9/11/20 2:24 PM, Adam D. Ruppe wrote:
> On Friday, 11 September 2020 at 18:16:10 UTC, Paul Backus wrote:
>> The main difference is that the Javascript system uses a regular-old 
>> Javascript list for its "spec object", rather than an opaque 
>> runtime-defined type.
> 
> Frankly, I hate the opaque thing too and it is going to change. In my 
> mind, it *must* be introspectable to be useful (without that, it also 
> fails test #8 btw).

Well it looks like that opaque thing should be the result of "tuple" and 
what's now "idup" should be "text", which takes us somewhere in between 
the previous DIP (and what people opine in this thread) and this DIP.

Lowering for this:

i"Hello, $name"

would be:

tuple("Hello, ", name)

and that's the way the cookie crumbles.

Of course the problem is "tuple" is somewhere in std instead of being in 
object.d. But if we zero in on this notion that we want a simple 
lowering, no support for all that %s nonsense, and something that people 
don't need to design functions especially for, that's an easy problem to 
look at.

BTW people will do this:

auto var = i"Hello, $name";

They will expect a string. Now maybe we can talk them into well that's a 
tuple, which is nice because @nogc, has full type info, etc. etc. But if 
we start talking about yet another __opaqueTypeWithItsOwnAPI then we've 
lost already.