On Wednesday, 11 December 2019 at 12:50:34 UTC, Ernesto Castellotti wrote:
> e if I'm wrong but from my point of view this "String interpolation" is completely useless.
> I wish D had a string interpolation like Kotlin

The problem is making it work with something like a string-appender. If you don't have GC then you might want to estimate buffer size before allocating, so you need 2 passes.

* pass 1:

run over all items and caculate length

*allocate buffer

* pass 2:

call formatting-objects on each item and ask them to write themselves to a slice.

But a metaprogramming oriented language really should to support custom formatters well in interpolated strings.

On Wednesday, 11 December 2019 at 11:21:08 UTC, Ola Fosheim Grøstad wrote:
> Agree. Your suggestion is much more in line with metaprogramming and offers the right flexibility.

But then it is impossible to tell which parts were in the string literal and which parts are outside data.

If you are going to do the tuple thing it absolutely must put a string in every other slot so this can be predicted.

Walter's proposal at least separates them cleanly.

On Wednesday, 11 December 2019 at 12:35:54 UTC, Rumbu wrote:
>> writefln(i"I ate %apples and %{d}bananas")
>
> What if I don't want any space after %apples?

i"I ate %(apples)and "

just use the parenthesis version.

On Wednesday, 11 December 2019 at 12:31:28 UTC, Andre Pany wrote:
> supported by the dip, only the 2 functions writeln/printf.

No, it can be passed to anything. std.string.format does it returning a string. Or you can write custom functions to read it.

On Wednesday, 11 December 2019 at 13:43:48 UTC, Adam D. Ruppe wrote:
> On Wednesday, 11 December 2019 at 11:21:08 UTC, Ola Fosheim Grøstad wrote:
>> Agree. Your suggestion is much more in line with metaprogramming and offers the right flexibility.
>
> But then it is impossible to tell which parts were in the string literal and which parts are outside data.

Can't you handle this by taking the head of the tuple and then let the formatter absorb what it needs? Then continue with the rest of the tuple?

Anyway, that was just a suggestion for making something that was close enough to Python 3 to be easy to use for simple cases (but slightly more difficult for advanced meta programming).

No problem with clever tricks in libraries, but it should not be complex on the surface, like this DIP. D needs to 1. embrace metaprogramming and 2. provide a simple surface for newbies.

> If you are going to do the tuple thing it absolutely must put a string in every other slot so this can be predicted.

Not necessarily, if you have a protocol then you can identify the type. However, it is probably better to let the formatting object wrap the data.

If you want it simple: add tuples. You either get something that can be turned into a string or you get a tuple, if you get a tuple then the first item in the tuple is a formatter and the rest is data.

Probably 100 ways to do this, but the key is to support custom formatters in an efficient manner that does not require high level allocation optimizations (GC languages can optimize away allocations because they control the allocator and all allocations).

On Wednesday, 11 December 2019 at 13:57:20 UTC, Ola Fosheim Grøstad wrote:
> If you want it simple: add tuples. You either get something that can be turned into a string or you get a tuple, if you get a tuple then the first item in the tuple is a formatter and the rest is data.

You could use «,» to indicate a formatter like this:

f"This is  {"my money"}:  {dec(3,2), my_account}!"

=>

("This is ", "my money", ": ", ( dec(3,2), my_account ), "!")

On Wednesday, 11 December 2019 at 12:31:28 UTC, Andre Pany wrote:
> If my understanding is right, string assignment is not supported by the dip, only the 2 functions writeln/printf.
> Which would be a quite big limitation. This would only cover 20% of my use case
> of string interpolation.
> Is my understanding correct?
>
> Kind regards
> André

Probably we're going to add format everywhere write:

string t = i"%count iterations done.".format;

Andrea

On Wednesday, 11 December 2019 at 11:01:58 UTC, MrSmith wrote:
> On Wednesday, 11 December 2019 at 10:57:13 UTC, 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.")
>
> That's an option, but one would also need to figure out handling of format specifiers

Do we really need support for format specifiers which are mostly appliable for primitive numeric type? I doubt existing format specifiers could be used with structs, classes, or any aggregate structures.

An alternative to specifiers we could define free functions that would format numeric values as needed allowing us to write smth like:

i"I ate %apples and %bananas totalling %(apples + bananas).format(formatargs))"

then, accepting function wouldn't require to meddle with specific printf semantics, and will get properly pre-formatted data to process.

if format specifiers are still desired they could be passed as separate arguments similar how it is done for getopts, and then accepting function would need to treat them in context of passed args.

Best regards,
Alexandru.

On Wednesday, 11 December 2019 at 11:21:08 UTC, Ola Fosheim Grøstad wrote:
> [snip]
> Also, change the prefix to "f", so  that is is similar to other languages like Python.
> [snip]

Python has f interpolation that looks like
print(f'Hello {name}! This is {program}')
but it also has % formatting that looks like
print(‘Hello %(name)s! This is %(program)s.’%(name,program))
This %(name) is probably the closest that compares to this DIP, but it seems like the Python 3.6 string interpolation was meant to replace that.

Scala also has f interpolation, but they also have s and raw interpolation.
The f is like
println(f"$name%s is $height%2.2f meters tall")
the s is like
println(s"Hello, $name")
and the raw is like
raw"a\nb"
The raw strings would correspond to D's r strings.

However, from that string interpolation page from wikipedia, I'm not seeing a lot of other examples of languages that use the f. Many of the languages on there do not require a prefix, though it seems to be mostly dynamic languages. It looks to me like most of the languages from the Visual Basic/C# microsoft line of things use a $ interpolation as in
Console.WriteLine($"Hello, {name}")

It looks most common to use $var, ${var}, ${expression}, or a little more rarely just {var}.

I like Scala's syntax, but you could probably bring together the f and s strings by just providing a default if there is no format provided.

On Wednesday, 11 December 2019 at 12:50:34 UTC, Ernesto Castellotti wrote:
> 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":
>>
>> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on December 25, or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> *Please stay on topic!*
>>
>> Thanks in advance to all who participate.
>
> From the dip it seems that it is only valid for writefln & co
> So a code like:
>    auto myText = i"I ate% apples"
> would not be valid.
>
> Correct me if I'm wrong but from my point of view this "String interpolation" is completely useless.
> I wish D had a string interpolation like Kotlin

this code should be valid although it wont be a string but a tuple of string & args ready for printing by stdio family of printer functions.


Current implementation also requires that a function call to be used to get a string, which defies the entire purpose of interpolated strings.

It either should be a simple tuple as suggested above (then i could live with additional func call to get resulting string), or return an interpolated string ready to be used (no additional function call).

Best regards,
Alexandru.