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
• Discussed in LDM (2018-7-9)
• 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. 🦉

[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. 🙃

[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

[The-Futurist]

@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)

[The-Futurist]

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