On 12/11/2019 11:30 PM, mipri wrote:
>    void takes_a_normal_string(string s) { }
> 
>    takes_a_normal_string(i"%one + %two = %(one + two).");

I'm not sure what you expect that to do?

On Friday, 13 December 2019 at 08:54:08 UTC, Walter Bright wrote:
> On 12/11/2019 11:30 PM, mipri wrote:
>>    void takes_a_normal_string(string s) { }
>> 
>>    takes_a_normal_string(i"%one + %two = %(one + two).");
>
> I'm not sure what you expect that to do?

Complete example:

  import std.stdio;

  void takes_a_normal_string(string s) {
      writeln(s);
  }

  void main() {
      immutable one = 1, two = 2;
      takes_a_normal_string(i"%one + %two = %(one + two).");
  }

Output:

  1 + 2 = 3

But, this works with DIP 1027, so I think it's fine:

  import std.format;
  ...
  takes_a_normal_string(i"%one + %two = %(one + two).".format);

On 2019-12-11 22:55:22 +0000, Steven Schveighoffer said:

> On 12/11/19 5:49 PM, Steven Schveighoffer wrote:
> 
>> OK, this is definitely a winner, way better than my idea. Only thing better would be some way to set the default specifier to avoid all the verbosity.
> 
> Hm...  heredoc gives us a precedent that might be valuable here.
> 
> e.g.:
> 
> db.exec(i"{?}INSERT INTO mytable VALUES ($name, $serial, $cost)")
> 
> printf(i"{%d}I ate $apples and $bananas totaling $(apples + bananas) fruit.\n");
> 
> -Steve

Yes, much better to reduce syntax-cluttering. Why not lean towards existing syntax from templates:

i(?)"INSERT INTO mytable VALUES ($name, $serial, $cost)"

or even make it more configurable to catch more cases:

i($,?)"INSERT INTO mytable VALUES ($name, $serial, $cost)"
i(#,?)"INSERT INTO mytable VALUES (#name, #serial, #cost)"

i(#,?,$,??)"INSERT INTO mytable VALUES (#name, $serial, #cost)"

By provding a standard case, where the printf relevant type is automatically deduced from the used variables, when no specification is given the syntax would be simple in a lot of cases:

i"I ate $apples and $bananas totaling $(apples + bananas) fruit.\n"


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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

Quite better solution in my opinion.

Andrea

On Friday, 13 December 2019 at 09:19:53 UTC, Andrea Fontana wrote:
> 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
>
> Quite better solution in my opinion.
>
> Andrea

Yes, I would also like a dip with the Adam proposal

On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1027, "String Interpolation":

In my opinion, the semantics of string interpolation need to support:

* The type of an interpolated string should be the same as a regular string. That means that the following should work:

auto foo = 3;
auto b = i"%foo";
static assert(is(typeof(b) == string));

* It should support both interpolating expressions and, with a shorter syntax, symbols, example:

auto foo = 3;
auto bar = 4;
auto a = i"%foo" // interpolation of symbol
auto b = i"%(foo + bar)" // interpolation of expression

* It should not be tied to specific functions, like `printf` or `writef`

* It needs to be possible to identify which part is a literal string and which part is an interpolation

* A way to customize how the interpolation is performed. This I'm not sure how to do best. There are a couple of alternatives. In Swift string interpolation is lower to method calls [1]:

"The time is \(time)."

Is lowered to something like:

var interpolation = MyString.StringInterpolation(literalCapacity: 13,
                                                 interpolationCount: 1)

interpolation.appendLiteral("The time is ")
interpolation.appendInterpolation(time)
interpolation.appendLiteral(".")

MyString(stringInterpolation: interpolation)

When it comes to the syntax. I think the existing suggestion to use `%` is bad, it's just going to cause conflicts with format specifiers for functions like `printf`. I would prefer to use the dollar sign, i.e. `$foo` and `$(a + b)`.

[1] https://developer.apple.com/documentation/swift/stringinterpolationprotocol

--
/Jacob Carlborg

On 12/11/2019 2:57 AM, Alexandru Ermicioi wrote:
> Why not just split interpolated string into just a tuple of args & strings. For example:
> Given: (i"I ate %apples and %bananas totalling %(apples + bananas) fruit.")
> Is lowered to a tuple: ("I ate ", apples, " and ", bananas," totalling ", apples + bananas," fruit.")

I don't see the point of that. The user could write it that way to begin with.

On 12/11/2019 7:41 AM, Patrick Schluter wrote:
> This wouldn't work for C formats like printf. The proposition has the nice property of being usable for DasBetterC and interfacing with C libraries that use format specifiers (libxml2 anyone?).

It definitely needs to work for printf and writef.

On 12/11/2019 3:05 AM, Sebastiaan Koppe wrote:
> - I don't mind the required prefix 'i', but what about q{} strings? I probably want to use interpolation there as well

The interpolation string needs to be a separate token. But I was thinking about i strings being concatenated with other strings if the others immediately follow it.

> - I know it is bikeshedding but since string interpolation is 99% syntax, I vote for "either a single $colon for variables or ${expression} for expressions", like literally every other modern language.

Have to fit in format specifiers, too.

On 12/11/2019 4:11 AM, Martin Tschierschke wrote:
> It should be something common, not a dlang only syntax.

Unfortunately, there is enough variation in common use that there's no such thing as a common syntax.

> But this alone gives no way for formatting numbers

Yup. It's not good enough.