October 19, 2023
On 10/18/2023 6:42 PM, monkyyy wrote:
> I would think its nonlinear and you could easily justify 90 -> 95% being 2x the complexity cost

For another example, the iphone camera pretty much destroyed the market for standalone cameras other than special purpose ones.
October 19, 2023
On 10/19/2023 12:29 AM, Andrea Fontana wrote:
>> > is prone to errors
> 
> Well, you know, even you posted a wrong example earlier in the thread.

The error won't result in anything other than oops there's a format string in the output.

If that's the only prone-ness to errors, it's doing very well.


> I'm also somewhat concerned about potential error messages that might confuse users due to the non-obvious abstraction: f.e. what happens if someone writes ```myfunction(i"hello $name!");```

Do you mean someone accidentally prefixing with 'i'? How would that be any different from the other proposal?

October 19, 2023
On Thursday, 19 October 2023 at 01:12:53 UTC, Walter Bright wrote:
> On 10/17/2023 10:14 PM, Imperatorn wrote:
>> Just a quick comment. Probably with string interpolation, less is more.
>
> Solving for 90% of the cases with a simple solution is preferable than a much more complex one to get a few more %. This is a winning strategy with programming.
>
> For example, with Ddoc and Unittest, the idea was to go for a simple-as-possible scheme to cover 90%, and it proved to be a winner.

Please give us something, anything at all 😭
As long as it's safe and doesn't destroy anything 🙏
October 19, 2023

On Thursday, 19 October 2023 at 07:51:38 UTC, Walter Bright wrote:

>

On 10/19/2023 12:29 AM, Andrea Fontana wrote:

> > >

is prone to errors

Well, you know, even you posted a wrong example earlier in the thread.

The error won't result in anything other than oops there's a format string in the output.

If that's the only prone-ness to errors, it's doing very well.

>

I'm also somewhat concerned about potential error messages that might confuse users due to the non-obvious abstraction: f.e. what happens if someone writes myfunction(i"hello $name!");

Do you mean someone accidentally prefixing with 'i'? How would that be any different from the other proposal?

Not by mistake, but intentionally because I want to pass a formatted string to my function.

And if I'm not mistaken, that string will be expanded into a tuple that could mess up the call to my function, returning an error that might confuse the user. In the worst case, it could call my function with extra parameters I didn't even expect, causing some unexpected side-effects.

// This function delete all the file passed (just a joke)
void deleteFiles(string[]... files) { ... }

// Example
deleteFiles("/tmp/test.txt", "/tmp/old.txt");
deleteFiles(i"/tmp/$dirname/$file"); <-- ooops this will be expanded?
October 19, 2023
As long as the literal cannot expand out into regular strings and only structs, this shouldn't be possible for it to occur silently.

From there its just a matter of having good error message writing where it sees what you tried to do and tell you why its wrong. This can happen incrementally.
October 19, 2023
On Thursday, 19 October 2023 at 10:53:08 UTC, Richard (Rikki) Andrew Cattermole wrote:
> As long as the literal cannot expand out into regular strings and only structs, this shouldn't be possible for it to occur silently.
>
> From there its just a matter of having good error message writing where it sees what you tried to do and tell you why its wrong. This can happen incrementally.

But walter's proposal expands it to a tuple if I understand it correctly:
https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
October 20, 2023
Don't worry about it, it has already been rejected and this was one of the reasons why.

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1027.md#final-review
October 19, 2023
On Thursday, 19 October 2023 at 02:48:43 UTC, Adam D Ruppe wrote:
> On Thursday, 19 October 2023 at 01:12:53 UTC, Walter Bright wrote:
>> Solving for 90% of the cases with a simple solution is preferable than a much more complex one to get a few more %. This is a winning strategy with programming.
>
> YAIDIP is an incredibly simple solution that has enormous bang for buck.
>
> Its implementation is very simple.

I like YAIDIP a lot from what I've read.  I also trust Adam and Steve and others in the discord universe who are demonstrated app/template wizards. Me, not so wizardly in that arena so grain of salt advised :-) .

October 19, 2023
On Thursday, 19 October 2023 at 11:10:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Don't worry about it, it has already been rejected and this was one of the reasons why.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1027.md#final-review

I think the simplest solution is to give up on one-size-fits-all.

slow"this allocates a string"
fast"this creates a fast tuple for meta-programming"

Even though the user-facing part is quite different, it would be possible to share much code between the two implementations inside the compiler.

obviously slow and fast are placeholder names.

October 19, 2023
On Thursday, 19 October 2023 at 11:10:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Don't worry about it, it has already been rejected and this was one of the reasons why.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1027.md#final-review

I don't think Walter has given up on it :P