Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# PROPOSAL: Add more options to escape from string template #890

Closed
ParserApprentice opened this issue Sep 8, 2017 · 14 comments
Closed

Comments

@ParserApprentice
Copy link

ParserApprentice commented Sep 8, 2017

C# PROPOSAL: Add more options to escape from string template

VS2017,

Current Status :
with C#7 local function,
I can use it as a string template for external lang.
eg.
cs_prop1

and this is the simple result ...
cs_prop2

or json text
cs_prop1_1

and the result...

cs_prop2_1

What I want to PROPOSE:

"Add more option to escape from string template"
Currently, It may be specific after $

eg Razor style, $@@""

cs_prop3

cs-parse found $ and follow by @@
cs-parse should escape when it found @ in the string literal
as if it found { } in C#7 , (see Razor as example)

(and more)
eg. Json

cs_prop4

currently
other algorithms of string template should remain the same.

I think it would be useful in many aspects.
eg

  1. local data template definition
  2. easy integration with some small data in xml or json format
  3. for the IntelliSense,
    the IDE can escape from the C# parsing context
    and go to another proper parsing context (eg xml, json , css etc..)

If the IDE is not support (3rd party) context lang => the context lang is just string template.

But for IDE that support context lang (eg. via plug-in)=>
When you click on code in that context -> IDE move you to the context lang enviroment.


Hope you consider this,
or suggest me if you have other ways

Thank you

@ParserApprentice
Copy link
Author

ParserApprentice commented Sep 8, 2017

@HaloFour
Copy link
Contributor

HaloFour commented Sep 8, 2017

Use of the razor syntax was suggested during the initial design of string interpolation and rejected. The interpolation syntax is a part of the C# language specification, the likelihood of a second syntax being considered alongside it is exceptionally low, especially since this proposal adds nothing new to the functionality.

@ParserApprentice
Copy link
Author

Don't you think it look cleaner when it was used in those use cases?
(esp. in json context)

@HaloFour
Copy link
Contributor

HaloFour commented Sep 8, 2017

Minimally, and I don't think that justifies adding a second interpolation grammar to the language specification. The current syntax was intentionally chosen to follow the conventions of String.Format and composite formatting within the .NET framework.

@ParserApprentice
Copy link
Author

ParserApprentice commented Sep 8, 2017

Why do you think that second interpolation grammar
should not be co-exists with the first one?

@ParserApprentice
Copy link
Author

since in C#, you can have many options to do the same thing.

@HaloFour
Copy link
Contributor

HaloFour commented Sep 8, 2017

@ParserApprentice

Because it represents a massive amount of work for virtually no gain. Things aren't added to the language just because they can be.

@ParserApprentice
Copy link
Author

since the first one may not suite in some situation (like in those use cases).
and
with the second one,=> developers can share code more easier with
other tech like Razor, css, js,typescript etc.

and tool (IDE) designers have more options when
they want to add context-aware suggestions.

@HaloFour
Copy link
Contributor

HaloFour commented Sep 8, 2017

Interpolation suits those use cases just fine. You are going to have to escape the curly braces, just like you would with String.Format. C# doesn't have a raw string syntax and any kind of interpolation syntax would require something somewhere to be escaped. That's completely unavoidable.

As for tools, that exists outside of the language and can be implemented by analyzers today. To C# interpolated strings are just strings and nothing more. It knows nothing about JSON, CSS, HTML, SQL, etc., nor does it care anything about them.

@ParserApprentice
Copy link
Author

ParserApprentice commented Sep 8, 2017

To C# interpolated strings are just strings and nothing more. It knows nothing about JSON, CSS, HTML, SQL, etc., nor does it care anything about them.

Yes, you are right.
and I don't want that C# to know it too.

I will handle the content of it with the analyzer.

But from the side of analyzer-tool developer.
I think that the primary code (before analyze) should
be more cleaner too.
Human user will happy when they read/review the code.

I think the code that look more concise/ readable/maintenance is one of
many goals of C#

@ParserApprentice
Copy link
Author

@HaloFour ,

Thank you for your comments.

I'm late for string interpolation design discussion.
so sometime I ask a question that was resolved.

so please think that I'm your student.

@ParserApprentice
Copy link
Author

Do you have a link or
Can you recommend a keyword for searching back to
the link of the discussion of C# string interpolation design.

So I can learn what the team think and discuss about it

@HaloFour
Copy link
Contributor

HaloFour commented Sep 8, 2017

String interpolation was designed while Roslyn was still over on CodePlex. Razor was brought up as an alternate syntax to the various proposals a couple of times.

@ParserApprentice
Copy link
Author

ParserApprentice commented Sep 8, 2017

I will study that discussions.
(https://roslyn.codeplex.com/discussions/540869)
(https://roslyn.codeplex.com/discussions/546467)

I think all Roslyn-Team have considered/discuss this before.
so at this time, I would like to close this issue.

Thank you for your comments and information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants