On 2/6/20 2:00 AM, Walter Bright wrote:
> On 2/5/2020 1:15 AM, FeepingCreature wrote:
>> On Wednesday, 5 February 2020 at 09:11:20 UTC, Walter Bright wrote:
>>> On 2/4/2020 9:48 PM, FeepingCreature wrote:
>>>> This may sound trivial, but trivial syntax enhancements matter, especially for a "top-ten" feature like format strings.
>>>
>>> It's a fair point, but there's a cost to supporting this. Nothing comes for free, and supporting everything is not practical.
>>
>> Okay, what actually is the cost of lowering to a template instantiation returning a type with an alias to a tuple, compared to lowering directly to a tuple? Is this significantly harder to implement and support?
> 
> For one thing, it becomes part of the language specification. It has to be documented and taught. It turns a simple feature into a complex one. Having language semantics controlled by a hidden template is not in any other part of D. It implies that the behavior of interpolated strings is not predictable.

By that logic, associative arrays are not predictable, as most of the API for it is in object.d

Neither is Object comparison (object.opCmp)

This argument is bunk. If it's part of the spec, it's predictable, no matter if the compiler implements it or the library does.

> Template instantiations are a LOT slower than direct implementation. Lots of interpolated strings means lots of template instantiations.

This is a good point. I'll add also that every string interpolation would result in a new type (which has a cost). I would like for a different way for this to work, and would be OK probably with a non-templated struct. Obviously, the template version provides more flexibility and power. But a non-template type with e.g. an array of strings and an array of format specifiers (all in ROM) would be sufficient for most cases. You'd probably have to include the fully generated string for the implicit casting.

One could also accept the interpolated string as a template parameter to get compile-time usage.

> Yes, it's also significantly more code to implement

It will be significantly more code for the library to implement if he has to parse the format string or add a special function to handle interpolation (because it doesn't follow the normal format for that domain, e.g. SQL).

> and there has to be error recovery for when the template can't be found, and checks for a rogue template.

These are solved problems. See all the templates inside the object module.

> 
> All that has to be weighed against the benefit. Implementing something just because it is feasible and ticks a box is not a sufficient reason to do it. D must have smallish features that are widely useful, not be a large collection of trivia.
> 

This is a fundamental disconnect. It's not ticking a box, it provides real value as described many times across this thread. You are willfully ignoring those points. And it's why I almost want to delete this message, and focus on more important things. But I'll send this last one, and then you can approve your own DIP without listening to the community.

-Steve

On Thursday, 6 February 2020 at 16:03:54 UTC, Steven Schveighoffer wrote:
> But I'll send this last one, and then you can approve your own DIP without listening to the community.
>
> -Steve

Wait a minute, can this happen? I mean someone approve own DIP like this?

If yes, what's the reasoning of this discussion?

Matheus.

On Thursday, 6 February 2020 at 16:24:43 UTC, matheus wrote:
> On Thursday, 6 February 2020 at 16:03:54 UTC, Steven Schveighoffer wrote:
>> But I'll send this last one, and then you can approve your own DIP without listening to the community.
>>
>> -Steve
>
> Wait a minute, can this happen? I mean someone approve own DIP like this?
>
> If yes, what's the reasoning of this discussion?
>
> Matheus.

The idea is to refine a suggestion before it is sent to the language maintainers for approval. It falls apart, obviously, when the person making the suggestion is also the person doing the approval.

On Thursday, 6 February 2020 at 16:24:43 UTC, matheus wrote:
> On Thursday, 6 February 2020 at 16:03:54 UTC, Steven Schveighoffer wrote:
>> But I'll send this last one, and then you can approve your own DIP without listening to the community.
>>
>> -Steve
>
> Wait a minute, can this happen? I mean someone approve own DIP like this?
>
> If yes, what's the reasoning of this discussion?
>
> Matheus.

All DIPs require approval from Walter and Atila. That doesn't change because it's Walter's DIP. Some people have called this a conflict of interest, but this isn't a democracy and the ultimate decision for anything that goes into the language is up to Walter, although it'd be foolish not to take the community's opinion into account.

The purpose of this discussion is to point out errors in the DIP and discuss it, IIRC.

On Tuesday, 4 February 2020 at 23:03:45 UTC, Adam D. Ruppe wrote:
> I just wrote up a revised DIP based on Walter's to detail my current thoughts:
>
> https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f

This should be in the feedback thread too.

Answering both:

On Thursday, 6 February 2020 at 16:43:37 UTC, nullptr wrote:
> The idea is to refine a suggestion before it is sent to the language maintainers for approval. It falls apart, obviously, when the person making the suggestion is also the person doing the approval.

On Thursday, 6 February 2020 at 17:03:42 UTC, Meta wrote:
> All DIPs require approval from Walter and Atila. That doesn't change because it's Walter's DIP. Some people have called this a conflict of interest, but this isn't a democracy and the ultimate decision for anything that goes into the language is up to Walter, although it'd be foolish not to take the community's opinion into account.
>
> The purpose of this discussion is to point out errors in the DIP and discuss it, IIRC.

Well I didn't know for me there was a sort of committee. I mean Walter could have a casting vote when tied, or more weight overall, but it's awkward seeing mostly only one person defining this.

Anyway I should stop to not get this out of rails.

Matheus.

On Thursday, 6 February 2020 at 16:03:54 UTC, Steven Schveighoffer wrote:
> This is a good point. I'll add also that every string interpolation would result in a new type (which has a cost).

A fairly small cost in exchange for a larger benefit (seamless compile time checking of format strings!).

Template explosion in D *is* a problem in other places, but very unlikely to be here, because there'd be one template per builder, not n-squared or even n-factorial per builder argument list length as can easily happen with template metaprogramming and voldemort type mangling.

So I doubt it would apply here anyway. And if it did, we can cross that when we come to it.

On Thursday, 6 February 2020 at 10:53:18 UTC, Jacob Carlborg wrote:
> This will make it feel more like a real string.

It is not a real string. It is a string builder. They aren't supposed to feel the same.

Just like how `[1,2,3].map!whatever` doesn't actually run any code until you force evaluation with foreach, each, array, or something. I know it doesn't work that way in other languages, but it DOES work that way in much D code and there's good reasons for it.

That's my position and I'm sticking to it.


so a bit more explanation, really the thing is that implicit conversion is directly at odds against other use cases. We'd either sacrifice a few cases entirely or sacrifice some in part and require compiler magic to even make it possible.

Our options are:

1) Maintain my position. Conversion to string consistently requires an explicit call to `.idup` or another helper function. Everything else is possible with overloaded functions. Hits about 10 / 12 user desires.

2) Switch to a C# style FormattableObject that implicitly converts to string. This sacrifices some use cases entirely (readf in particular, possibly interacting poorly wit `scope`, `return`, etc attributes as well), but may be more familiar to users coming from other languages. Hits about 8 / 12 user desires (though two of the hits here do include the misses in option #1)

3) Put magic into the compiler to automatically transform #1 into #2 depending on situation, or something like that. Will hit 11 / 12 wishlist items, but at the cost of more compiler magic...

Hitting 12/12 is impossible because one of those items is implicit conversion to string and another one of those items is NO implicit conversion to string (for various reasons)!

So with those direct contradictions we just have to accept that 100% of desires will NOT be 100% achieved.

My proposal gets us over 80% at a fraction of the cost of option #3; it is the 80/20 rule optimum in my view.

On 2/5/2020 6:18 AM, Steven Schveighoffer wrote:
> All you are doing is transforming the format specification into a tuple instead of a string.

What is the tuple generated for:

  i"your hex data is ${%02x}someByte"

?

On Friday, 7 February 2020 at 08:45:03 UTC, Walter Bright wrote:
> What is the tuple generated for:

read my document here: https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f

>   i"your hex data is ${%02x}someByte"

(_d_interpolated_string!("your hex data is ", _d_interpolated_format_spec("%02x"))(), someByte)

Note that is a tuple consisting of two members, one of which is a single template instantiation given two value arguments.