String interpolation syntax being postfix bad for intellisense

[foxydevloper]

Would like to add input on https://github.com/hsutter/cppfront/wiki/Design-note:-Capture
While I think capture being postfix for capturing makes a lot of sense and is reasonable, for string interpolation it would prevent the IDE from being able to immediately provide intellisense for string interpolation, since you would first be required to type ()$, and then jump back to after ( to trigger autocompletion. I think that string interpolation would benefit from it's syntax being prefix or { }, since it could tell that you entered a string interpolation and provide autocomplete. I think this would fit very well with cpp2's goal of improving toolability. I don't think string interpolation and capture need to have the same syntax, they seem to be relatively different concepts, string interpolation is mainly just sugar for concatenation.

Here's a demonstration from javascript to show how prefix string interpolation (as well as if it was { }) allows for your IDE to trigger autocomplete immediately upon writing the prefix, which wouldn't be as convenient if it's syntax required a postfix after the brackets.

Code_2023-10-22_13-44-41.mp4

[msadeqhe]

IMO capturing is an important operation and it's more visible when it appears at first.

var1: i32 = 10;
var2: = var1&$*;
var3: = $(var1&)*;

[JohelEGP]

Parentheses are worse, IMO.
And the symmetry of postfix is good.
String interpolation needs the parentheses, anyways, so it can be prefix there.

[JohelEGP]

var3: = $(var1&)*;

It's actually worse.
Using prefix + instead, it lowers to +*cpp2::impl::assert_not_null((&var1)) (https://cpp2.godbolt.org/z/93fznePs8).
The prefix operator applies to everything until a binary operator.
There's none here, so you need even more parentheses to actually dereference the capture.

var3: = ($(var1&))*;

[JohelEGP]

In fact, it's just that the inner parentheses are redundant.
Or, that in the original code, $ should go inside the parentheses.
($var1&)* would work fine.
(+var1&)* lowers to *cpp2::impl::assert_not_null((+&var1)) (https://cpp2.godbolt.org/z/MsKMG6ras).

[hsutter]

Thanks! I'm listening: This is a frequently asked question, and when something is frequently asked even after it's been answered, that's data.

I do want consistency, a single way to do capture (and it's always value capture). And I do want to treat interpolation as value capture -- that seems to be a valid generalization that is working well.

I've seen a pattern with respect to parentheses: It appears that string interpolation will always need the parens (or equivalent), whereas other capture needs parens more often for prefix $ capture. Here are some examples I think about:

// a typical postcondition
:() vec.size()$ + 1;
                        :() $(vec.size()) + 1;
                        :() $(vec.size() + 1);

// a typical value capture
:() x$;
                        :() $x;

// a typical reference capture
:() x&$*;
                        :() $(x&)*;

// a typical single value interpolation
"hello (name)$\n"
                        "hello $(name)\n"

// a typical expression interpolation
"result: (x*3 + 2)$\n"
                        "result: $(x*3 + 2)\n"

As @msadeqhe points out, for reference (pointer) capture, requiring the parens may actually be more readable.

As @foxydevloper and many others point out, prefix $ is more consistent with other languages.

[MaxSagebaum]

@MaxSagebaum

After a ( is entered into a string the intellisense can automatically open. The user can then either ignore it or use the completion feature. So nothing is really lost.

Parathesis are very common in English (like this), having it trigger autocomplete whenever using them could be pretty inconvenient. I also don't think that would work very well since if you had a string like "i like dogs (and cats), how about you", the language server would have to assume (and cats) is an unfinished string interpolation. I'm not really sure, we'd have to see an implementation of an language server for cpp2 with string interpolation autocomplete to what the best syntax for string interpolation would be. I'm just assuming this is why most languages don't have a postfix after brackets. IDEs automatically add the closing brackets which makes prefix string interpolation immediately able to provide autocomplete results, since all the characters are already typed out

I understand that braces are more common in English, but usually not in the text we write in computer programs. Larger phrases are just read from some file. The strings we usually write are used to combine the larger phrases.

Nevertheless, I spoke from a non intrusive autocomplete. Here, the cursor is not moved and the typing is not interrupted. Then it should not matter. In IDEs, that automatically set a default and add it automatically, which I personally do not like, it would be a huge issue.

That's not quite the same. When you type ", it puts another " after the cursor. To get the same thing here, typing ( would need to add )$ after the cursor, and I'm not sure that this is common enough. Maybe in a Cpp2 mode, that MIGHT make sense, but I find that there are enough times that I currently don't want the second " when I type the first one that it could get annoying really quickly.

If an autocomplete is triggered on a ( and the user selects one option only then the )$ could be added.

[simeonKuran]

I am a big fan of generalization and consistency. However, I wonder if captures and string interpolation are really similar? To what kind of respect?
But of course, it might still be useful to treat them uniformly (with postfix operator)...

[JohelEGP]

See https://github.com/hsutter/cppfront/wiki/Design-note%3A-Capture.

[JohelEGP]

Better yet, #159 (comment), which opens with

Apologies if this is obvious, but is string interpolation even capturing?

[simeonKuran]

Thanks for pointing me there. 😊

Nevertheless, to me it feels quite unintuitive to think of captures when defining a string. I am not sure, that this brings any benefit.

But at least I understand now the idea better.

[msadeqhe]

For autocompletion outside string literals, prefix $ has the advantage that it would be possible to only show local variables of outer function scope only if $ is typed. For example if | is the cursor:

fnc1: () = {
    var1: = 0;
    var2: = 0;

    call(: () -> i32 = $|); // Prefix $
    call(: () -> i32 = |); // Postfix $
}

If $ is postfix, the tool has to display all local variables from outer function scope in auto completion list. But if $ is prefix, the tool can display all local variables from outer scope only if $ is written before (of course it won't display local variables of current scope, because $ is written before, only local variables from outer scope can be written after that).

Also considering these type declarations:

point: @struct type = {
    x: i32 = 0;
    y: i32 = 0;
    z: i32 = 0;
}

shape: @struct type = {
    center: point = ();
}

I think if programmers can capture a variable without parentheses $variable, they won't mind (most of the times) that it captures the whole variable instead of its individual members:

main: () = {
    var1: shape = ();

    // `var1` is captured.
    call(: () -> i32 = $var1.center.x + $var1.center.y + $var1.center.z); // Prefix $
    call(: () -> i32 = var1$.center.x + var1$.center.y + var1$.center.z); // Postfix $

    // `var1.center` is captured.
    call(: () -> i32 = $(var1.center).x + $(var1.center).y + $(var1.center).z); // Prefix $
    call(: () -> i32 = var1.center$.x + var1.center$.y + var1.center$.z); // Postfix $

    // `var1.center.x`, `var1.center.y` and `var1.center.z` are captured.
    call(: () -> i32 = $(var1.center.x) + $(var1.center.y) + $(var1.center.z)); // Prefix $
    call(: () -> i32 = var1.center.x$ + var1.center.y$ + var1.center.z$); // Postfix $
}

So prefix $ may encourage capturing the whole variable, on the other hand it's easier to find prefix $ (because of white-spaces around binary operator+).

[foxydevloper]

This is a really interesting and good point. It really does seem like in this case - even though postfix is good for a lot of things, capture being a syntax that begins before parathesis in order to get context on what it's doing would be best, it would really make things read left-to-right, which postfix can help with for a lot of syntax but for capturing values it really seems like the capture is more important to be left-most, as if it were a function call, so it would be better off as prefix

[JohelEGP]

What if you typed $,
your cursor moved back before the $,
and then you're shown the outer-scope suggestions.
Then postfix still works.

[foxydevloper]

That could work, but I don't see how that behavior would work in IDEs, and your cursor moving backwards from captures would be confusing and possibly annoying. Having to go from right to left really goes against the whole postfix making code read left-to-right philosophy that a lot of features being postfix is supposed to help with.

[switch-blade-stuff]

Personally I prefer the prefix style since it is easier to notice and read. Prefix says "interpolate the following", postfix says "whatever you read just now, interpolate that please", which is easier to miss and harder to read when slimming the code (you can't just skip the interpolation, you need to read into it). Its the similar complaint I have in rust with implicit returns, where a giant statement may be returning depending on whether there is a semicolon at the end.

On another note, I know this was discussed before but I still think that curly braces are better for interpolation, since string interpolation doesn't really "capture scope", it formats the data. Braces are also used in other languages for interpolation and in std::format, making transition easier for new developers. Prefix $ also cannot support formatting (without additional syntax), while braces can support formatting, which can also make transition from std::format seamless.

[gregmarr]

@switch-blade-stuff I just noticed that we now have formats in the captures. e38838e

That brings us even closer to being able to use std::format on the entire string literal, with only a wrapper that strips out the expressions and puts them in the arg list, if we use the {} syntax instead of the ()$ syntax.

std::cout << "(x.name():20)$ color (x.color():10)$ price (x.price(): <10.2f)$ in stock = (x.count() > 0)$\n";

std::cout << "{x.name():20} color {x.color():10} price {x.price(): <10.2f} in stock = {x.count() > 0}\n";

std::cout << std::format("{:20} color {:10} price {: <10.2f} in stock = {}\n", x.name(), x.color(), x.price(), x.count() > 0);

[switch-blade-stuff]

Thank you for pointing this out! I am a little outdated on the current progress of cppfront.

Given that interpolation does support formatting now, there is even less parallel to scope captures and more potential for confusion when using the parentheses syntax.

[gregmarr]

Thank you for pointing this out! I am a little outdated on the current progress of cppfront.

I just found it yesterday, so not too far behind. :)

Given that interpolation does support formatting now, there is even less parallel to scope captures and more potential for confusion when using the parentheses syntax.

Agreed.