September 11, 2020
On Friday, 11 September 2020 at 14:05:51 UTC, 12345swordy wrote:
> On Friday, 11 September 2020 at 13:46:52 UTC, Paul Backus wrote:
>>
>> Yes, that's exactly what I'm asking. Note that this is something D *already* does when it provides wrappers like `writefln` as alternatives to C functions like `printf`, so in practice, it should not require any new work to be done.
>
> You conflicting standard library feature with built in language feature here, they are not the same.

I don't understand the objection. Both `printf` and `writefln` are standard-library features in their respective languages. I guess I could have been more precise and written "Phobos" and "libc" instead of "D" and "C", but I assumed that was clear from context.
September 11, 2020
On Friday, 11 September 2020 at 14:15:23 UTC, Paul Backus wrote:
> On Friday, 11 September 2020 at 14:05:51 UTC, 12345swordy wrote:
>> On Friday, 11 September 2020 at 13:46:52 UTC, Paul Backus wrote:
>>>
>>> Yes, that's exactly what I'm asking. Note that this is something D *already* does when it provides wrappers like `writefln` as alternatives to C functions like `printf`, so in practice, it should not require any new work to be done.
>>
>> You conflicting standard library feature with built in language feature here, they are not the same.
>
> I don't understand the objection.
You request people who maintain c/c++ binding libraries to put into the extra effort of preventing users from accidentally call the wrong function when using string interpolate. That is just plan unreasonable.
September 11, 2020
On Friday, 11 September 2020 at 14:56:10 UTC, 12345swordy wrote:
> You request people who maintain c/c++ binding libraries to put into the extra effort of preventing users from accidentally call the wrong function when using string interpolate. That is just plan unreasonable.

I request that library maintainers, *in general*, put in the extra effort of preventing users from accidentally calling the wrong function, *in general*, because it's a basic tenet of good library design. The fact that it also helps with string interpolation is just a nice bonus. :)

If someone insists on using a badly-designed C library without wrapping it, that's their problem. No amount of compiler cleverness is going to make badly-designed C libraries pleasant to use.
September 11, 2020
On Friday, 11 September 2020 at 15:14:29 UTC, Paul Backus wrote:
> On Friday, 11 September 2020 at 14:56:10 UTC, 12345swordy wrote:
>> You request people who maintain c/c++ binding libraries to put into the extra effort of preventing users from accidentally call the wrong function when using string interpolate. That is just plan unreasonable.
>
> I request that library maintainers, *in general*, put in the extra effort of preventing users from accidentally calling the wrong function, *in general*, because it's a basic tenet of good library design. The fact that it also helps with string interpolation is just a nice bonus. :)


Do you think that the d language should allow opimplicit conversion if think that preventing calling the wrong function rest on the library and not the language?
September 11, 2020
On Friday, 11 September 2020 at 15:27:08 UTC, 12345swordy wrote:
>
> Do you think that the d language should allow opimplicit conversion if think that preventing calling the wrong function rest on the library and not the language?

I think the D language should give programmers the tools they need to write good code, and should trust programmers to use the tools it gives them responsibly.

If D can't trust programmers to use this style of interpolated string (that lowers to an argument list) responsibly, then it shouldn't have them at all. A crippled version like DIP 1036 is not the solution.
September 11, 2020
On Friday, 11 September 2020 at 16:10:17 UTC, Paul Backus wrote:
> On Friday, 11 September 2020 at 15:27:08 UTC, 12345swordy wrote:
>>
>> Do you think that the d language should allow opimplicit conversion if think that preventing calling the wrong function rest on the library and not the language?
>
> I think the D language should give programmers the tools they need to write good code, and should trust programmers to use the tools it gives them responsibly.
>
> If D can't trust programmers to use this style of interpolated string (that lowers to an argument list) responsibly, then it shouldn't have them at all. A crippled version like DIP 1036 is not the solution.

That doesn't answer my question.
September 11, 2020
On Friday, 11 September 2020 at 10:43:54 UTC, Paul Backus wrote:
> Anyway, I don't expect my idea to satisfy everyone equally.

This right here is why the idup mechanism is how it is.

There's ten cases we identified from various people to try to hit:

 1. string s = i""; should work.
 2. @nogc use of i"" should be possible.
 3. foo(i""); should work where it is foo(string) {}
 4. for createWindow(string s, int width = 0, int height = 0), calling createWindow(i"Connected $id") should NOT result in createWindow("Connected %s", id). It should either error, or convert the entire expression to a string.
 5. db.query(i""); should be possibly to do safely
 6. int x; verbose_debug!(i"$x assertion failed"); should be possible
 7. readf(i"$foo"); should be possible as well as other ref, scope, etc. types
 8. compile-time checking of format strings should be possible
 9. mixin(i"T $name;"); should work
10. printf(i""); should work


Hitting all ten is impossible; some of them are directly contradictory. But if we loosen some of those "should work" things to "works with .idup", then we actually can do them all.

C# style objects (which I advocated for first btw) cannot possibly do numbers 6, 7. Putting the arguments in an object forces evaluation, which would trigger CTFE errors on 6 and discards the ref storage class in case 7. (now I'm kinda of the opinion that case 7 is silly and not worth fussing over. But the general problem with it is once you put it in an object, parts are lost. I know a lot of people feel the whole concept of D's storage classes were a mistake, but it is what it is.

If we go up one level and just present the parameter list, then you could still send it to an object, but you're no longer forced to, so all that data is still available. Jonathan Marler's original PR did what you proposed for `i""`. Walter Bright's did.... almost... what you proposed for `f""`. But better than any of them is Javascript's system, like I wrote about in a previous message, adapted to D.

(and I know some of this should be in the DIP, to be honest, I've just written it up a couple times and over the delay to formalize the process, I just plain forgot what I said where. I *very* much simply prefer working with code and casual conversation than with this passive voice hyperformal waterfall spec speak. The dip text itself got weakened too by the focus on specifying ToFormatSpec instead of the actual structure implementation. It is the same code... just rewriting it in formal spec-talk instead of straightforward code is painful. I dropped out of college!)
September 11, 2020
I'm eagerly awaiting the inclusion of this feature in the D language!

Well, I have a few questions and points about this DIP.

1. Although the Abstract says "embedding arguments in the string itself", the DIP does not propose a syntax for embedding arguments in the string; the DIP proposes a syntax for splitting the string into tuples. I think, as I do, that what most people want is "embedding arguments in the string itself", so the essence of DIP should be the same. It might be a good idea to add a `f"..."` syntax that has the same meaning as `i"...".idup`.

2. It doesn't seem to work well with the {} style formatting employed by C#, Rust, etc. Is the following interpretation correct?
`String.Format("You are now {0} years old.", years - 1)` eq `String.Format(i"You are now ${\{0\}}(years - 1) years old.")`
This is a commonly used formatting style, so it would be nice to have an aid to this.

3. The object.idup in the DIP uses `import std.format`, is it permissible for the druntime to be dependent on Phobos?

4. Are there any reasons why backquotes (i`...`) are not allowed? Of the several string literals currently available, back-quoting string literals seem to be a good match for this DIP.

5. Although you use the name idup, idup should be used to create `immutable(_d_interpolated_string!Parts)`, which is an immutable duplication. In other words, I think you should avoid using this name. A good alternative is `toString`. On the other hand, this alternative may dilute the implications of the GC being used, but idup does not imply that the GC will be used in the first place.
September 11, 2020
On Friday, 11 September 2020 at 16:32:28 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2020 at 10:43:54 UTC, Paul Backus wrote:
>> [...]
>
> This right here is why the idup mechanism is how it is.
>
> There's ten cases we identified from various people to try to hit:
>
> [...]

You have a pull request that implement this then?
September 11, 2020
On Friday, 11 September 2020 at 17:46:22 UTC, 12345swordy wrote:
> You have a pull request that implement this then?

No, but you can copy/paste the example implementation in the dip and translate it by hand to get an idea of how it works.