On Sunday, 15 December 2019 at 17:26:57 UTC, Jab wrote:
> It being usable with snprintf() means it outputs something that pretty much no other function uses.

D's writef uses it too, as well as std.format. Do do the vibe logging functions.

It is a common format.

(though D's writef is supposed to replace C's printf... for great part because of type safety.))

On Sunday, 15 December 2019 at 17:38:29 UTC, Adam D. Ruppe wrote:
> On Sunday, 15 December 2019 at 17:26:57 UTC, Jab wrote:
>> It being usable with snprintf() means it outputs something that pretty much no other function uses.
>
> D's writef uses it too, as well as std.format. Do do the vibe logging functions.
>
> It is a common format.

Which brings this to mind:

  import std.stdio;

  void main() {
      int n, m;
      write("input: ");
      readf(i"$n - $m");
      writeln(n + m);
  }

As used:

  $ ./test
  input: 2 - 8
  10

When's the last time you saw string interpolation
that resulted in the variables getting set to new
values?

On Sunday, 15 December 2019 at 17:50:56 UTC, mipri wrote:
> When's the last time you saw string interpolation
> that resulted in the variables getting set to new
> values?

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)

On Sunday, 15 December 2019 at 17:26:57 UTC, Jab wrote:
> On Sunday, 15 December 2019 at 15:36:09 UTC, Guillaume Piolat
>
> There's no reason it can't be implicitly converted to a string.


Okay. Let's say this would compile:

    int stuff = 4;
    string s = i"my interpolated %stuff string";


Where should the result of i"my interpolated %stuff string" be allocated?
If you answer "with the GC", then this feature requires the runtime...

On Sunday, 15 December 2019 at 05:34:48 UTC, Jab wrote:
> If it was important it would already have been implemented, but no one uses printf as there are better alternatives.

That's wrong, we use printf snprint and sprintf a lot since we can't use D with its runtime (makes too much problems in a shared lib) and printf still is the gold standard for conversion of float to string.

On Sunday, 15 December 2019 at 17:38:29 UTC, Adam D. Ruppe wrote:
> On Sunday, 15 December 2019 at 17:26:57 UTC, Jab wrote:
>> It being usable with snprintf() means it outputs something that pretty much no other function uses.
>
> D's writef uses it too, as well as std.format. Do do the vibe logging functions.
>
> It is a common format.
>
> (though D's writef is supposed to replace C's printf... for great part because of type safety.))

Literally the next sentence:

> The only thing I know of that implements printf-style formatting is printf (or uses sprintf to implement it).

This is going to add a feature to the language that is dependent on a library feature. Even though the compiler creates and verifies the format strings, it's going to have to re-parse the format string at runtime anyways.

Implementing string interpolation will just grow the dependency on printf/sprintf. Cause like I said, no other function really actually implements that formatting scheme themselves. This limits and over-complicates the code around it.

On Sunday, 15 December 2019 at 18:25:40 UTC, Guillaume Piolat wrote:
> On Sunday, 15 December 2019 at 17:26:57 UTC, Jab wrote:
>> On Sunday, 15 December 2019 at 15:36:09 UTC, Guillaume Piolat
>>
>> There's no reason it can't be implicitly converted to a string.
>
>
> Okay. Let's say this would compile:
>
>     int stuff = 4;
>     string s = i"my interpolated %stuff string";
>
>
> Where should the result of i"my interpolated %stuff string" be allocated?
> If you answer "with the GC", then this feature requires the runtime...

"Implicitly converted" meaning it exists as something else and can be converted to it. If you don't want the GC then don't use a string.

     @nogc:

     int stuff = 4;
     auto t = i"my interpolated %stuff string";
     string s = mallocString(t); // no different than having to call malloc() + snprintf()

On Sunday, 15 December 2019 at 20:07:23 UTC, Jab wrote:
> Literally the next sentence:

writef is neither printf nor does it use sprintf to implement it (except for floating point types... much to the chagrin of would-be CTFE users).

D embraced printf's format and re-implemented it a long time ago.

On Sunday, 15 December 2019 at 18:29:10 UTC, Guillaume Piolat wrote:
> On Sunday, 15 December 2019 at 05:34:48 UTC, Jab wrote:
>> If it was important it would already have been implemented, but no one uses printf as there are better alternatives.
>
> That's wrong, we use printf snprint and sprintf a lot since we can't use D with its runtime (makes too much problems in a shared lib) and

It was a figure of speech. You are most definitely in the minority. You can create a convenience wrapper around printf that is @nogc so you don't have to use it directly.

> printf still is the gold standard for conversion of float to string.

It's just the most accessible. There are better float to string implementations out there.

On Sunday, 15 December 2019 at 20:15:38 UTC, Adam D. Ruppe wrote:
> for floating point types

Exactly.