On 12/10/18 8:48 AM, Olivier FAURE wrote:
> On Thursday, 6 December 2018 at 16:19:12 UTC, Steven Schveighoffer wrote:
>> With the concept of lowering to a tuple, I'd love to use such a thing for database queries.
>>
>> For instance:
>>
>> db.exec("UPDATE Foo SET a = ?, b = ?, c = ?, d = ? WHERE id = ?", aval, bval, cval, dval, id);
>>
>> vs.
>>
>> db.exec(i"UPDATE Foo SET a = $aval, b = $bval, c = $cval, d = $dval WHERE id = $id");
> 
> I really like that, but I'd add a caveat: this syntax makes it harder for db.exec to know which arguments you give it are trusted compile-time inputs, and which arguments are unsafe runtime inputs.

Yes, if you read down into this thread, Neia brought up the same issue.

The answer is -- pass them at compile time. I.e.:

db.exec!(i"UPDATE ...");

Now you have access to what are string literals and what are parameters. You can even build the query string at compile time if using a library that requires it all as one string.

-Steve

On Monday, 10 December 2018 at 10:55:05 UTC, Atila Neves wrote:
> Strawman.
>
> My point isn't that syntax sugar isn't needed, is that in this case the problem is easily solved with a library (and has been), and doesn't apply to anything except for multiline code generation, which is a niche.

In languages that support it, string interpolation is used for many things other than multiline code generation.

On Monday, 10 December 2018 at 16:55:38 UTC, Paul Backus wrote:
> On Monday, 10 December 2018 at 10:55:05 UTC, Atila Neves wrote:
>> Strawman.
>>
>> My point isn't that syntax sugar isn't needed, is that in this case the problem is easily solved with a library (and has been), and doesn't apply to anything except for multiline code generation, which is a niche.
>
> In languages that support it, string interpolation is used for many things other than multiline code generation.

I meant compared to std.conv.text. If it fits on one line then `text` is more than fine.

On Monday, 10 December 2018 at 20:57:52 UTC, Atila Neves wrote:
> I meant compared to std.conv.text. If it fits on one line then `text` is more than fine.

My use case is terminal colours in format patterns, which quickly become mental gymnastics and extremely bug prone/easy to get wrong. They're largely oneliners, and interpolation would be a huge help.

// string logtint, warningtint;
// Exception e;

logger.warningf("IRC Parse Exception: %s%s %s(at %1$s%4$s%3$s:%1$s%5$d%3$s)",
    logtint, e.msg, warningtint, e.file, e.line);

(Apologies if I misread your meaning)

On Monday, 10 December 2018 at 20:57:52 UTC, Atila Neves wrote:
> On Monday, 10 December 2018 at 16:55:38 UTC, Paul Backus wrote:
>> On Monday, 10 December 2018 at 10:55:05 UTC, Atila Neves wrote:
>>> Strawman.
>>>
>>> My point isn't that syntax sugar isn't needed, is that in this case the problem is easily solved with a library (and has been), and doesn't apply to anything except for multiline code generation, which is a niche.
>>
>> In languages that support it, string interpolation is used for many things other than multiline code generation.
>
> I meant compared to std.conv.text. If it fits on one line then `text` is more than fine.

Compare:

    const expected = ...;
    const result = foo(x, y, z);

    // without interpolation
    assert(result == expected,
        text("`foo(", x, ", ", y, ", ", z, ")`: expected `", expected, "` but got `", result, "`"));

    // with library interpolation
    assert(result == expected, mixin(interp!
        "`foo($(x), $(y), $(z))`: expected `$(expected)` but got `$(result)`"));

    // with built-in interpolation syntax
    assert(result == expected,
        i"`foo($(x), $(y), $(z))`: expected `$(expected)` but got `$(result)`".text);

Even for a single-line string, the interpolated version has clear advantages.

I'll grant that the difference between interpolation as a library and as a language feature is a lot smaller than the difference between interpolation and plain-old `text`. So maybe getting `interp` into Phobos is a better line of attack than trying to sell W&A on new syntax.

On Monday, 10 December 2018 at 23:07:32 UTC, Paul Backus wrote:
> So maybe getting `interp` into Phobos is a better line of attack than trying to sell W&A on new syntax.

I might be thinking something really silly, but since adding such a thing as string interpolation is pretty much (wanted) syntactic sugar, isn't it just possible to lower it? And if the answer to this is yes, why can't we have some much wanted syntactic library solutions as language features lowered in a compiler pass?
We can just maintain a separate set of lowerable language constructs into a combination of existing library functions instead of the true lowering of for loops and while loops and everything the like.
(we could lower a specific character before a string literal into a literal![STRING]; )
Isn't that more acceptable? Keeping syntactic sugar lowering separate from fundamental lowering? As far as I can see this would "promote" addition of syntactic sugar as a language feature because it can be maintained whitout a big impact on the language.
If certain syntactic sugar lowerings are deemed wanted, tested and found stable but can benefit from a performance increase by better compiler support using some other forms than just lowering, they might eventually be altered whitout impact to the user.
Also, these syntactic sugar language features might be disabled/enabled by a compiler flag or dub setting.
All with all, I don't see how this couldn't realistically be included into the language like a lot of syntactic sugar. I understand the argument against it, but the potential benefits I can see are just too big to ignore.

On Tuesday, 11 December 2018 at 13:49:17 UTC, Sjoerd Nijboer wrote:
>
> I might be thinking something really silly, but since adding such a thing as string interpolation is pretty much (wanted) syntactic sugar, isn't it just possible to lower it? And if the answer to this is yes, why can't we have some much wanted syntactic library solutions as language features lowered in a compiler pass?
> We can just maintain a separate set of lowerable language constructs into a combination of existing library functions instead of the true lowering of for loops and while loops and everything the like.
> (we could lower a specific character before a string literal into a literal![STRING]; )

It sounds like what you're asking for is a way to define rules for "lowering" one kind of syntax (e.g., string literals) into another (e.g., calls to library functions or templates).

This feature exists in other programming languages. The technical name for it is "AST macros." It's a very powerful feature, because it allows the programmer to essentially build their own custom programming languages on top of the "base" one provided by the compiler. For the same reason, it can also make code very difficult to read and understand. If any piece of syntax can be "lowered" into anything else, the only way to understand the code is to know what all the lowering rules are, and that can get difficult when every programmer is free to add to the pile.

Because of those potential difficulties, Walter has rejected every previous proposal to add AST macros to D, and there's no evidence to suggest that he's changed his mind since the last one. So, while it's true that AST macros would solve the issue with string interpolation, they're not a realistic option if we want our proposal to be accepted.

On Tuesday, 11 December 2018 at 16:48:56 UTC, Paul Backus wrote:
> It sounds like what you're asking for is a way to define rules for "lowering" one kind of syntax (e.g., string literals) into another (e.g., calls to library functions or templates).

Maybe I explained it a littl weird, but I would really like D to not have AST macros that are accessible for the programmer. Like you explained, it makes the language into whatever the one who created the library wanted to be. Which probably isn't a good thing for a language like D.

I think that there might be realistically 5 or 8 or so syntactic sugar features people generally want in this language, and I think the compiler could provide that. This could be done using AST's, but should not be accessible to the programmer.
At most, I think this would add some compiler swithces like `dmd --syntaxextention=interpolation,null-conditional,etc...`
That way they would be defined by the D community, W&A wouldn't have to "deal" with it, the people who want their sugar have it, and the people who never ever want to touch it don't have to.

The biggest benefit I think of doing it this way is standardisation. Because if it were to be done with a library implementation, there will probably be a few libraries which will implement it with various syntax and in various stages of working. Furtheron, people would have to learn a library instead of a language feature, which on itsself isn't such big of a deal except that there are probably multiple libraries doing thesame thing, and libraries are harder to find documentation for. Its always annoying in a professional project to have to add external dependencies for small features. It becomes a liability and makes D less attractive.

On Tuesday, 11 December 2018 at 17:12:46 UTC, Sjoerd Nijboer wrote:
> The biggest benefit I think of doing it this way is standardisation. Because if it were to be done with a library implementation, there will probably be a few libraries which will implement it with various syntax and in various stages of working. Furtheron, people would have to learn a library instead of a language feature, which on itsself isn't such big of a deal except that there are probably multiple libraries doing thesame thing, and libraries are harder to find documentation for. Its always annoying in a professional project to have to add external dependencies for small features. It becomes a liability and makes D less attractive.

You can get the same benefit by putting the library version in the standard library.

I do agree that this is important, and I think more people would use `interp` if it came with Phobos rather than in a dub package.

What's the state nearly year later?