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

[claptrap]

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:
>> 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.

The most critical part of global optimisation is making sure your 
cost function is good. If you dont account for all the things you 
want to achieve, and weight them appropriately then you will end 
up with a sub optimal solution.

IE. In setting those 10 requirements you will pay somewhere else 
in the design. So the question is are those 10 requirements all 
thats important? Are they all more important than...

"Is it easy to explain to newbies?"
"Is it easy to use correctly?"
"Will it just work with existing code?"
etc..

Did you account for everything you want in the cost function?