Champion: verbatim interpolated string (order of $@ vs. @$) (16.3, Core 3)

[stuartstein777]

This proposal will extend object initializers to allow @$"hello" as a verbatim interpolated string, compared to $@"hello" (current interpolated verbatim string).

• [ ] Proposal added
• [x] Discussed in LDM (2018-7-9)
• [x] Decision in LDM (let's do it, 2018-7-9)
• [ ] Finalized (done, rejected, inactive)
• [ ] Spec'ed

LDM history:

• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-07-09.md

---

Would it be possible for the order of the string interpolation and string literal identifiers to not matter?

e.g.

var foo = $@"c:\foo\{someFile}";

Is fine, but

var foo = @$"c:\foo\{someFile}";

isn't...

There's probably a good reason for it that I'm missing, but would it be possible to make the order not matter?

O/T And looking at the title, I now realise $@ v @$ looks a bit like some funky owl, which I'm pleased with.

[Neme12]

I'd just vote for having a better error message from the compiler if you get this wrong.

[yaakov-h]

And a code fix in the IDE. 😄

[gafter]

I'll champion this. I think we should remove this little annoyance. :owl:

[CyrusNajmabadi]

FWIW, this trips me up all the time. I basically just try one order, and if it doesn't work, i flip it. It's the USB-A connection of C#.

[Joe4evr]

@CyrusNajmabadi Except that this doesn't require 3 tries to get right. :upside_down_face:

[Neme12]

I agree this is annoying, but I'm not sure if I like this being a preference/code style or just having this inconsistent everywhere.

[Logerfo]

@Joe4evr

$@"..."

3 compilation errors

damn it!

@$"..."

4 compilation errors

[Korporal]

@gafter @CyrusNajmabadi

I'll champion this. I think we should remove this little annoyance.

I'm really getting mixed signals here, substantive value?

[tannergooding]

@Korporal, there is a significant difference between the two proposals.

This one is a relaxation on an existing feature (recognizing both $@ and @$ as being verbatim interpolated strings -- it probably only requires a parser change).

The other is an entirely new feature that impacts multiple things in the language (control flow, definite assignment, existing code using labels, etc)

[Korporal]

@tannergooding @CyrusNajmabadi - Sure I agree and think the ordering should be irrelevant but telling me in one thread that a change has to provide substantive value even if its simple to do and then endorsing something in this thread that clearly doesn't, seems like an inconsistent position.

Just how many developers are asking for this? just how much pain does it cause developers? I'd be very surprised if this bothers developers more than poor support for exiting/continuing nested loops.

[CyrusNajmabadi]

There's clearly a zone for what account to niggles. i.e. they're not a new language feature per-se, they're just a tiny tweak of something already there. i.e. allowing separators in literals. Being more lenient with where "partial" can go. Allowing $@ vs @$.

That's very different from an entirely new language concept. "i.e. a label on a loop that behaves differently if you 'goto' it or 'continue' it or 'break' it". These open actual design areas and introduce entirely new concepts to the language. That's an entirely different sort of thing.

For things that really just affect hte lexing of a token, the bar is a lot lower. For things that introduce entirely new syntactic constructs that affect things as important as flow control, then there's goign to be a different bar.

[Neme12]

that a change has to provide substantive value

Almost every time I wanted to use $@ so far, I had to think about what the order is and potentially try both options. I've never felt the need to use a labeled loop.

[tannergooding]

AFAIK, there isn't some hardset rule of "weighing" a proposal, other than the general saying that everything starts at -100 and needs +100 points to be implemented.

Two members of the language team could have different opinions on a proposal and one could choose to champion it, where the other may choose not to.

Championing also doesn't necessarily mean it will get in, it just means that the champion will bring it forward at LDM because they think it is worthwhile.

In this particular case, the proposal is for an existing feature, it is trivial to implement, and it is something that most C# devs who use the feature have probably hit when typing out code. As such, it is something that was deemed worthwhile almost immediately (because it is basically a bug fix).

The other proposal is basically an entirely new feature, so it requires a lot more support, discussion, etc, to prove that it is worthwhile.

[CyrusNajmabadi]

Also, the messaging i gave was: It will be up to an LDM member to see if they want to champion.

in this case, an LDM member is willing to champion the issue. :)

[Korporal]

@CyrusNajmabadi

There's clearly a zone for what account to niggles. i.e. they're not a new language feature per-se, they're just a tiny tweak of something already there. i.e. allowing separators in literals. Being more lenient with where "partial" can go. Allowing $@ vs @$.

That's very different from an entirely new language concept. "i.e. a label on a loop that behaves differently if you 'goto' it or 'continue' it or 'break' it". These open actual design areas and introduce entirely new concepts to the language. That's an entirely different sort of thing.

Again I agree, my grumble is that you told me a proposed change "has to provide substantive value above and beyond just 'insufficiency'" yet here you're justifying this one based on implementation costs the very thing I tried to point out in the loop discussion.

As I say I'm fine with this idea and I'd champion it too if I were in a position to but clearly substantive value is not as important as you implied.

[tannergooding]

@Korporal, different people measure the "substance"/"impact" of a proposal differently 😄

[HaloFour]

More important than any of those factors, @gafter wants to champion it. That's a tall and subjective hurdle, and by no means guarantees that a proposal will go anywhere.

This repo isn't a democracy. The C# language still firmly belongs to the language team at Microsoft. We get to watch the show and shout comments from the studio audience, but there's no commitment that it goes further than that.

[CyrusNajmabadi]

yet here you're justifying this one based on implementation costs the very thing I tried to point out in the loop discussion.

I didn't do any justification based on impl costs :)

And i think you're conflating issues that appear as "little annoyances" to LDM members with issues that are more substantive in terms of design surface area and concept. These things are not the same, and are not really treated the same by many LDM members.

[Korporal]

@CyrusNajmabadi

I didn't do any justification based on impl costs :)

You did when you wrote this in this response:

they're just a tiny tweak of something already there.

emphasis mine.

This isn't really very important it just shows that different people here have different personal views of what matters and what doesn't which is only to be expected. But it does weaken your arguments about substantive value when it is pretty clear that adding a safer way to break or continue in nested loops (and thereby reduce the scope for badly behaving code) is more beneficial to users of the C# language than the ordering of these string tokens!

[CyrusNajmabadi]

emphasis mine.

That has nothing to do with impl cost. I'm saying, as a language feature, it's an incredibly tiny tweak. It's a niggle. It's on the scope of just impacting a single token the language has defined. This has nothing to do with the impl, it has to do with how many the language needs tweaking.

is more beneficial to users of the C# language than the ordering of these string tokens!

As i said above, the bars are different for different sorts of changes. I also made it clear over and over again that what was necessary was someone willing to champion the issue, and that all these proposals needed that. In a case like this, championing is easier because things are scoped so narrowly.

But it does weaken your arguments about substantive value when it is pretty clear that adding a safer way to break or continue in nested loops (and thereby reduce the scope for badly behaving code)

My argument was that you could get your "safer way to break or continue in nested loops" today just by writing an analyzer. INdeed, my overall argument would be: if you just want to to something you can already do today in C#, but you only want to restrict it, then analyzers are almost always the right way to things.

As per the discussion in the other thread, you could already have such a feature yesterday if these efforts were spent on that.

[Kryptos-FR]

I hit that issue with verbatim string interpolation all the time. One would think that if order did not matter then I should only hit it 50% of the time , but no it is 100%. So I had to ask myself why?

The answer is quite simple actually, and there are two reasons:

• the key order on the (standard American Qwerty) keyboard is @ then $
• the English name of that feature is "verbatim string interpolation", so verbatim before interpolation

One has to wonder, why the opposite order was chosen in the first place...

[jnm2]

@Kryptos-FR Pre- or post-fix is a sensible default rather than infix when adding a new feature, tbh.

[Neme12]

@Kryptos-FR

the English name of that feature is "verbatim string interpolation", so verbatim before interpolation

That logic only holds if you read "verbatim string interpolation" as "verbatim (string interpolation)". Parsing it as "(verbatim string) interpolation" would suggest that it's an interpolated verbatim string, which could justify the order :smile:

[Kryptos-FR]

@jnm2 It makes sense, from a technical point of view. A bit less from a user point of view (at least for me). Classical issue developer-friendly vs user-friendly, I guess.

@Neme12 fair point :smile:

[jcouv]

Promoted the issue to a championed issue. LDM is supportive. I have a PR for the implementation: https://github.com/dotnet/roslyn/pull/28355

[Grauenwolf]

If this doesn't pass, I would like Visual Studio to auto-correct it.

If this does pass, I would still like Visual Studio to auto-correct it (on format) so it looks consistent.

[yaakov-h]

I wouldn't expect it to be difficult to make a new formatting rule for the ordering of '@' and '$'. I'd definitely appreciate one, too.

[jcouv]

Filed https://github.com/dotnet/roslyn/issues/30012 for code style enforcement.

[Neme12]

Given that this feature needs to introduce a new code style for the ordering preference of @ and $ and that it introduces a point of inconsistency, I think I'd prefer a different solution. A code style for the ordering seems very strange since I don't think this is something most people care or have opinions about, they just want to get it right when typing. This code style would only exist to ensure consistency and would probably be turned on by default as a suggestion to use $@ (current syntax).

Essentially the experience as proposed for most people would be:

• I type $@"hello...", and after typing the string I see either a warning/suggestion/error (if that is enforced by the code base) and need to hit Ctrl+. to fix the order to adhere to the preferred style (or do it manually)

I propose a different approach. The language would still only support $@ as the only valid order but I would add 3 improvements to the compiler & IDE to remove the annoyance of having to know the order:

1. The compiler would parse and understand the opposite order @$ and treat it as a verbatim interpolated string for all intents and purposes. Even the IDE would recognize it as verbatim interpolated string. But there would be a small error squggle on the @$ characters telling you that hey, you got the order wrong. This would be much better error recovery (because we know that people get this wrong sometimes) than the parser going crazy like it does now. It would work as if this feature is supported but has an artificial error added blocking it from compiling.
2. If you do get the order wrong and get the small error suggested above, the IDE would offer a simple code fix to fix the ordering. So far, the experience with these 2 additions would be very similar to the current proposal of a code style, except it would always be enforced with an error.
3. When typing @$"" in the IDE, after typing the @$ characters, the IDE would automatically fix the order on the fly as you type the opening quote. This would be the most common experience - as you're typing, you don't even have to remember the order - if you get it wrong, it is just fixed as soon as you start typing the string; you don't have to care and might not even notice that. In my opinion, this provides an even better experience than the current proposal of accepting both and having a code style, since that involves having to use the code fix (and adding a very strange code style option that I don't even know how you would describe in editorconfig :smile:)

[CyrusNajmabadi]

TBH, that sounds very sensible to me. @jcouv what do you think? Might it be better to just make this a tooling-improvement story, instead of an actual language change?

It woudl be similar to how i added support for <<<<<<<-style conflict markers. We didn't change the language or anything, we just made the tooling much better here. We'd do the same for @$ and $@. The lexer would understand it (as you've done in this PR), and we'd possibly still have a distinct kind for it. But it would always be an error, and the IDE would simply have a feature to fixup that error.

--

In terms of fixing while typing. I'm normally a bit wary about that given the state-machine stuff you have to be careful with. (For example, if someone types @$-<backspace>). However, this seems generally so targeted and safe enough, that i think it would be potentially ok to just fix immediately as you type.

[jnm2]

I like @Neme12's proposal, especially the autocorrect without needing Ctrl+., because it's a step in a direction that I'd want regardless. If it turns out to still bug enough people who aren't using the VS IDE, the compiler can still be relaxed later on.

[jcouv]

I think that's workable, and it would indeed avoid style issues. The parsing work is the same either way. The only difference is whether we produce a diagnostic.

the IDE would automatically fix the order on the fly as you type the opening quote.

@CyrusNajmabadi Would you have a tip on how to do that?

[CyrusNajmabadi]

Literally just have a command handler that listens for type-chars. If you hear about $ go and look if it's right after @. If so, execute more complex logic to see if you should apply (i.e. you're not in a string), then just make the edit to the buffer :)

[CyrusNajmabadi]

Note: the only part i'm a little on the fence for is: Do we need a separate SyntaxKind for this. I can see arguments both ways... I'm leaning toward not wanting a new kind here, and having this just be something you can get for the regular kind...

[Neme12]

@jcouv do you mind if I try to implement this or would you like to do this yourself?

[Neme12]

The parser change was already merged with a single syntax kind

[jcouv]

I'm starting a thread with LDM to confirm we're ok to revert the language design (disallow @$ after all). Since the parsing change was already implemented (https://github.com/dotnet/roslyn/pull/28355), it's just a matter of adjusting when a diagnostic is produced.

@Neme12 That'd be great. I assume you'd take care of the compiler change too (always produce a diagnostic, regardless of LangVersion). We'll also want to delete the code fixer (made obsolete by new auto-fixer). I'll ping you as soon as I get confirmation from LDM (hopefully this afternoon).

[jcouv]

The feedback from LDM is to keep the language feature (allow @$) because some editors won't have the auto-fixer. We can still implement a code style or auto-fixer in VS to improve style consistency.

[Neme12]

Ok, thanks

[CyrusNajmabadi]

The change was already merged with a single syntax kind

Great. I think i prefer it that way.

[generateui]

The answer of the question "is it $@ or is it @$?" is 42.

shift-4-2 produces $@.

[alexdresko]

How would @$ be parsed in Razor? In Razor, @ roughly defines the beginning of a code block. I've never tried it before, but it seems like @$ would tell Razor to output the value of the interpolated string. Worse, @@ is the syntax for escaping the special @ character, so I don't think you'd be able to @@$.

Just some thoughts that popped into my head. I ain't no eckspurt.

[jnm2]

@alexdresko How would @"" be parsed now?

[jcouv]

Tagging @rynowak as FYI, as new syntax could impact Razor.

[rynowak]

Thanks, making a note of it.

[GSPP]

Now the inconsistency in a team situation is going to drive people mad instead 😆

Resharper solves this by immediately correcting a mistake as you type.

[jnm2]

Visual Studio immediately corrects as you type, too.