February 04, 2020
On Tuesday, 4 February 2020 at 14:33:59 UTC, Adam D. Ruppe wrote:
> [...] consider this:
>
>    Window createWindow(string title, int width = 0, int height = 0) {}
>
> and the user writes
>
>    createWindow(i"Window for $user_id on $pid")
>

You made some good arguments about why structure is needed (versus having a string + a tuple), but this is a really good example.

If anything the i"" should not return a string, but rather an InterpolatedString type (whatever that is).

This not only allow overloading/static-if on it, but also the possibility to introspect it. For instance to extract the original string.
February 04, 2020
On Tuesday, 4 February 2020 at 07:12:11 UTC, Walter Bright wrote:
> On 2/3/2020 5:06 PM, Jonathan Marler wrote:
>> Some applications want the "Strings and Expressions" form rather than the "Format String" form.
>
> To have "strings and expressions" then write it that way:
>
>     foo("I want ", i, " bananas");

I explained why I thought it would be better for interpolated strings to resolve to "Strings and Expressions" rather than "Format Strings". Then you responded saying you can write "Strings and Expressions" without interpolated strings.  However, I'm not sure what the relevance is.  You can also write "Format Strings" without interpolated strings, like this:

foo("I want %s bananas", bananas);

But I'm not sure how these facts help us determine which form interpolated strings should resolve to?

February 04, 2020
On Tuesday, 4 February 2020 at 07:12:11 UTC, Walter Bright wrote:
> On 2/3/2020 5:06 PM, Jonathan Marler wrote:
>> Some applications want the "Strings and Expressions" form rather than the "Format String" form.
>
> To have "strings and expressions" then write it that way:
>
>     foo("I want ", i, " bananas");

This just seems entirely tone death to the comment he made. All interpolated strings are is syntactic sugar. You can just write the alternative (including printf), the purpose of interpolated strings is to not to.

To be useful it has to become something like this:

> i"$apples and ${%d}bananas"
>
> =>
>
> (__d_format_literal!(Format.init, " and ", Format("%d")), apples, bananas)

__d_format_literal is easy to parse compared to just a string. So it is easier to turn it back into essentially a tuple, at the cost of slow CTFE.

With this it'd be easy to check and just throw an error at compile time if you don't want to allow custom formatting as well.

This is probably the best solution so far that still allows customization and supports specifying custom formats that can be used with printf.

    i"value is ${%6.2f}value"

I just wouldn't want Format() to just be a string either though. It'd be useful if it split all the options up appropriately. That way you don't have to parse the format string yourself.








February 04, 2020
On Tuesday, 4 February 2020 at 18:20:27 UTC, Arine wrote:
> I just wouldn't want Format() to just be a string either though. It'd be useful if it split all the options up appropriately. That way you don't have to parse the format string yourself.

You can use `std.format.FormatSpec` to parse the format string, if you don't want to write your own parsing code.
February 04, 2020
On Tuesday, 4 February 2020 at 14:33:59 UTC, Adam D. Ruppe wrote:
> [snip]

One thing I'm a little confused on with this proposal. Under DIP 1027, if I have a function that takes an string as input, then I believe it can take an interpolated string as input instead. Similarly, it works with printf.

Under the addendum proposal, is it also the case that functions that take strings or printf can instead take the interpolated string? You have some comments about that it does have compatability with printf and there was some discussion about a toString method, but I wasn't 100% sure where that came down and why.
February 04, 2020
On 2/4/20 1:41 PM, jmh530 wrote:
> On Tuesday, 4 February 2020 at 14:33:59 UTC, Adam D. Ruppe wrote:
>> [snip]
> 
> One thing I'm a little confused on with this proposal. Under DIP 1027, if I have a function that takes an string as input, then I believe it can take an interpolated string as input instead. Similarly, it works with printf.
> 
> Under the addendum proposal, is it also the case that functions that take strings or printf can instead take the interpolated string? You have some comments about that it does have compatability with printf and there was some discussion about a toString method, but I wasn't 100% sure where that came down and why.

The intention is for __d_interpolatedString (or whatever) to return a struct that has an enum member which is the interpolated format string, which is then alias this'd to the struct.

So the type should decay exactly into what the current DIP says. It should be 100% compatible with printf.

But if you want to do something different with interpolated strings, you can overload your function to handle it specially. Once you do that, you have access to the original parsed interpolation string parts and formats.

In short -- anything that would work with the DIP as currently written would work with this new proposal.

-Steve
February 04, 2020
On 2/4/20 8:44 AM, jmh530 wrote:
> On Tuesday, 4 February 2020 at 12:47:28 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> As I expected, this was rejected, and Walter didn't understand what I was saying, says we shouldn't bake % into the format specification (it doesn't), and that it's like AST macros (it's not). Since there's no arguing on the feedback thread, I didn't want to push it.
>>
> 
> Several people seem to think it is an important proposal, so I wouldn't want you to get discouraged.

I've been involved in many discussions like this with Walter, and it's not something I plan to do in this case. Once he makes up his mind, the chances that I can convince him otherwise shrink to almost non-existent, and it's not worth the effort IMO.

> However, when you say "Walter didn't understand what I was saying", another way to look at it is "I didn't communicate this well enough to convince Walter".

Possibly, but his response looks like he's trying to intentionally avoid discussing the proposal at all (most of the points were obviously incorrect, which leads me to believe that he would rather not discuss the actual proposal). I don't have lots of time to argue with people who aren't open to discussion.

-Steve
February 04, 2020
On 2/4/20 2:12 AM, Walter Bright wrote:
> On 2/3/2020 5:06 PM, Jonathan Marler wrote:
>> Some applications want the "Strings and Expressions" form rather than the "Format String" form.
> 
> To have "strings and expressions" then write it that way:
> 
>      foo("I want ", i, " bananas");

To have "formatted string output", just write it that way:

writefln("I have %s apples and %d bananas", apples, bananas);

-Steve
February 04, 2020
On 04.02.20 22:57, Steven Schveighoffer wrote:
> On 2/4/20 8:44 AM, jmh530 wrote:
>> On Tuesday, 4 February 2020 at 12:47:28 UTC, Steven Schveighoffer wrote:
>>> [snip]
>>>
>>> As I expected, this was rejected, and Walter didn't understand what I was saying, says we shouldn't bake % into the format specification (it doesn't), and that it's like AST macros (it's not). Since there's no arguing on the feedback thread, I didn't want to push it.
>>>
>>
>> Several people seem to think it is an important proposal, so I wouldn't want you to get discouraged.
> 
> I've been involved in many discussions like this with Walter, and it's not something I plan to do in this case. Once he makes up his mind, the chances that I can convince him otherwise shrink to almost non-existent, and it's not worth the effort IMO.
> 
>> However, when you say "Walter didn't understand what I was saying", another way to look at it is "I didn't communicate this well enough to convince Walter".
> 
> Possibly, but his response looks like he's trying to intentionally avoid discussing the proposal at all (most of the points were obviously incorrect, which leads me to believe that he would rather not discuss the actual proposal). I don't have lots of time to argue with people who aren't open to discussion.
> 
> -Steve

+1. I have refrained from commenting on the string interpolation DIP so far because it is not important enough to me to yet again get into the situation that Steve, Adam, Jonathan,... are in now. It's a very frustrating way to lose a lot of what could have been productive time.

Personally, I think it is ridiculous that the DIP focuses on printf over all other use cases so much yet in the common case, the proposed string interpolation will lead to access violations when used with printf in the most natural way, and it does not even support type safe formatting. This is not what people mean when they vote for string interpolation on a survey.

@jmh530: Have you read all the arguments made? Do you really think they are not compelling enough to at least warrant being addressed?
February 04, 2020
On Tuesday, 4 February 2020 at 18:41:20 UTC, jmh530 wrote:
> Under the addendum proposal, is it also the case that functions that take strings or printf can instead take the interpolated string?

That would depend on the druntime implementation. I think my preference would be it implicitly casts to string and const char* if and only if all format specifiers are given by the user.

I just wrote up a revised DIP based on Walter's to detail my current thoughts:

https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f

and wow that took like 3 hours. I have other things to do now so I haven't proofread it yet, but it basically explains what I'm feeling is ideal based on this thread with a couple small new ideas (like the `idup` overload that replaces my old `toString` proposal)

But the executive summary is

1) Steven's proposal from earlier, but with `Format.init` changed to `Format(null)`. Same result now but easier to add another argument in the future if we decide to extend this.

2) A sample library implementation you can play with. You'll have to write out the lowering by hand though since I didn't do a mixin translator this time.

3) A couple use cases and benefit examples written up. I also want to mention i18n but I ran out of time like two hours ago so bleh.

4) Most Walter's limitations are eliminated and I cleaned up some of the language (like that MixinExpression) one too.


I got more into the implementation weeds than I probably should have but with that you can see more clearly in exact detail what behavior I am envisioning.