Feedback Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[aberba]

On Wednesday, 9 September 2020 at 16:43:04 UTC, Seb wrote:
> On Wednesday, 9 September 2020 at 14:19:43 UTC, Paul Backus 
> wrote:
> ...
> I second this. I like this DIP more than 1027, but I fully 
> agree with Paul that in its current form this DIP does too many 
> wrong compromises. Just to re-state my points:
>
> 1) I strongly believe that printf shouldn't make up most of the 
> design considerations and DIPs space. This is about a D 
> feature, not C. Trying to bridge both worlds will please none.
very debatable.

>
> 2) No C string magic: "spec will automatically convert to a 
> compile-time NUL-terminated C string if spec.hasAllSpecs is 
> true." is just a big NO.
>
> 3) `${%d}bananas` is an awful syntax compromise as it will be 
> very unintuitive to newcomers as it's not clear what the 
> variable is.
> For example, `${bananas:2f}` would read much better. In 
> general, I like the way Python handles the format specifiers:
These things seem to me like unnecessary nitpicking, I don't see 
how something like `${bananas:2f}` is remotely more pleasant.

>
> https://www.python.org/dev/peps/pep-0498/#format-specifiers
>
> 4) Format specifiers need to be 100% customizable. The NodeJS 
> community got this right and it lead ...
I've been developing almost always with Node.Js full-time for 
100% of the projects I work on for client...including full-stack 
applications and my use of string interpolation has never sent me 
where I needed something like chalk's way of doing things. So 
it's very debatable.

>
> 5) APIs will need to be written specifically to cater for 
> _d_interpolated_strings if no implicit conversion is allowed 
> anyhow, so the interpolated_string struct should always 
> containing its arguments. This would allow for adding methods 
> like `idup`, `toString` etc. directly inside the struct. I 
> don't see the DIP explaining the advantage of doing rewrite 
> magic to `writefln(<interpolationSpec>, apples, bananas, apples 
> + bananas);` and this will only confuse people.

> ... this will only confuse people.
???

> 9) The DIP does not mention operator overloading, e.g.
>
> string s = "foo";
> ...
> s ~= i"foo $bar";
>
> IMHO this is unambiguous and would reduce the need to call 
> `.idup`.
Is calling .idup that much of a trouble? Because one time we're 
about how it's important to be explicit about types in D and 
other times we're about the opposite of that.


Off I go but when folks start with "this DIP should be rejected" 
it tells me whatever follows is nitpicking that will ensure 
goodies don't get implemented.