On Sunday, 15 December 2019 at 18:25:40 UTC, Guillaume Piolat wrote:
> If you answer "with the GC", then this feature requires the runtime...

That's exactly what mine would do.

But at the same time, with mine, you could *also* do

snprintf(buffer.ptr, buffer.length, i"foo %bar".c.tupleof);


Check out a draft hacky 100% library implementation here:
http://arsdnet.net/inter.d

the compiler can do a slightly better job avoiding the copying of values (the library can too... but not if you also want all three: RT+CT compat, C function compat, and expressions in the interpolated string. It is a kinda pick any two. Unless I'm missing a cool trick. But the compiler can express more than the library.)

On Sunday, 15 December 2019 at 20:32:38 UTC, Adam D. Ruppe wrote:
> On Sunday, 15 December 2019 at 18:25:40 UTC, Guillaume Piolat wrote:
>> If you answer "with the GC", then this feature requires the runtime...
>
> That's exactly what mine would do.

On second thought, it's true interpolated string are most wanted _when generating website pages_ and it's not like we would miss it that much in -betterC / or with disabled runtime.

On 12/15/2019 2:17 AM, Aliak wrote:
> To use it people will need to understand how to use d tuples as well.

No, they don't.

On 12/15/2019 10:03 AM, Adam D. Ruppe wrote:
> I actually think that is a cool feature of the proposal. (though i hate readf, the general idea of populating placeholders is a nice one)

It works with scanf, too, though I never use scanf.

On 12/15/2019 2:33 AM, Alexandru Ermicioi wrote:
> On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
>> object.d is getting more and more bloated over time. This is not a solution to imports, and is not a good trend.
> 
> A bit other topic, but this can be fixed by splitting object.d in multiple modules in same package, and auto import that package, just like how it is done in java with java.lang package.
> 
> For example, object.d could be split into several modules under d.lang package.
> 
> This will also clean existing bloatware, since we could move typeinfo, object definition and other stuff into separated modules.

The reality is that compilation time is more proportional to the number of files than the size of the files. Splitting up object.d into multiple modules that must still be loaded will make things slower.

Also, splitting it up into multiple modules does not eliminate the complexity of it.

Some hashtags to get things started:

#dip1027
#stringInterpolation

On Monday, 16 December 2019 at 01:35:51 UTC, Walter Bright wrote:
> On 12/15/2019 2:17 AM, Aliak wrote:
>> To use it people will need to understand how to use d tuples as well.
>
> No, they don't.

User: why can't I do this?/Why doesn't this work?

string s = i"$var";

Answer?

On Thursday, 12 December 2019 at 17:05:32 UTC, Adam D. Ruppe wrote:
> On Thursday, 12 December 2019 at 16:50:47 UTC, aliak wrote:
>> So i"blah %var" would not return a tuple but a type that has alias this to string? Like:
>
> Yup that's my proposal: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html
>
> Walter's proposal isn't bad, though mine is better :)
>
> However I would tweak one thing about mine. Before I said "auto arg1 = 50; ". I'd actually change that now to `auto arg1 = () => 50;` for more compile time / runtime mixing compatibility.
>
> I might also steal the raw string thing from Javascript... and I actually kinda like the format string from Walter's proposal, though mine can actually do that too already by reading format stuff in CTFE right out of the string.

Ah ok. Yeah that sounds pretty good!

I'm starting to wonder now, what's the use case for returning tuples? Why not just a string?

On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
> On Monday, 16 December 2019 at 01:35:51 UTC, Walter Bright wrote:
>> On 12/15/2019 2:17 AM, Aliak wrote:
>>> To use it people will need to understand how to use d tuples as well.
>>
>> No, they don't.
>
> User: why can't I do this?/Why doesn't this work?
>
> string s = i"$var";
>
> Answer?

because

string s = ("%s",var);

is a syntax error. Even a beginning programmer can understand that an interpolated string cannot be a pure simple string as it contains symbols and expressions that are language construct not part of the string literal, i.e. that the compiler has to perform some transformations to substitute these language symbols into a value.
Interpolated strings, in any language, are not string literals. Each language resolves this fact in different manners and at different times. Interpreted languages do it at runtime (obviously), java like languages chose to do it at runtime. In a language like D, which prefers resolving what is resolvable at compile time, it would be loathed if it interpolation was resolved at runtime (remember how long people were bitching about runtime only format strings?)
Resolving interpolation at compile time is imho incompatible with handling them as regular strings.

The question is then do we want CT or RT interpolated strings. RT interpolated strings can still be provided by a library.

On Monday, 16 December 2019 at 11:08:00 UTC, Patrick Schluter wrote:
> On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
>
>> Resolving interpolation at compile time is imho incompatible
> with handling them as regular strings.

Maybe I'm wrong here, I haven't thought it through, but in first approach I think that's an essential point. As the string contains code, if evaluated at CT, the string must be split somehow in literal parts and code parts. Allowing the i-string to be handled as regular string implies that the splitting happens sometime between when it is declared and after it is used, which can happen after runtime.

import fn;

int b = 20;

string inter = i"$(a+b)";

foreach(a; 1..10)
  fn(inter);

---
module fn;

void fn(string s)
{
  writefln(s);
}

How would that work?

In python or javascript there's no issue, a is a runtime symbol.

>
> The question is then do we want CT or RT interpolated strings. RT interpolated strings can still be provided by a library.