[API Proposal]: Allow StringSyntaxAttribute to be applied to return values.

[Swimburger]

Background and motivation

The addition of StringSyntaxAttribute (#62505) adds syntax highlighting and more to parameters, fields, and properties which is very helpful already.
A lot of methods also construct strings of a specific syntax and return them, which could benefit from the syntax highlighting and tooling of the StringSyntaxAttribute.

API Proposal

Add AttributeTargets.ReturnValue to the list of targets of the StringSyntaxAttribute.

API Usage

[return: StringSyntax(syntax: StringSyntaxAttribute.Xml)]
public static string BuildTwiml(string name) => $"""
    <?xml version="1.0" encoding="utf-8"?>
    <Response>
        <Say>Ahoy {name}!</Say>
    </Response>
    """;

Alternative Designs

No response

Risks

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

The addition of StringSyntaxAttribute (#62505) adds syntax highlighting and more to parameters, fields, and properties which is very helpful already.
A lot of methods also construct strings of a specific syntax and return them, which could benefit from the syntax highlighting and tooling of the StringSyntaxAttribute.

API Proposal

Add AttributeTargets.ReturnValue to the list of targets of the StringSyntaxAttribute.

API Usage

[return: StringSyntax(syntax: StringSyntaxAttribute.Xml)]
public static string BuildTwiml(string name) => $"""
    <?xml version="1.0" encoding="utf-8"?>
    <Response>
        <Say>Ahoy {name}!</Say>
    </Response>
    """;

Alternative Designs

No response

Risks

No response

Author:	Swimburger
Assignees:	-
Labels:	api-suggestion, area-System.Diagnostics, untriaged
Milestone:	-

[tommcdon]

@stephentoub

[stephentoub]

@CyrusNajmabadi, would Roslyn be able to handle this?

@Swimburger, your example uses interpolated strings. They already don't get the syntax highlighting and related features you mention. Do you have real examples that don't involve dynamically-generated content?

[CyrusNajmabadi]

Sure. We could handle this. But we still won't do anything special for interpolated strings as we have no idea how to interpret the content. We also won't do anything with xml as we lack an xml parser that gives things like positions (afaik)

[Swimburger]

Without string interpolation, it would probably be better to store the string in a const, so I don't have another use-case.
The most common scenario would be to do some work, and at the end of the method interpolate strings with the result of the work.
I wouldn't expect this to work for more complex scenarios.

The current implementation already supports string interpolation, at least in the IDE I tried (Rider 2022.3 EAP 1).

[CyrusNajmabadi]

What happens if you have var name = "</Greeting>";?

We could possibly attempt to support a subset of features here. But we very likely could not effectively do diagnostics.

[Swimburger]

When I do that, the program works without errors or warnings.

When I intentionally malform the XML, it also doesn't complain about it in combination with string interpolation.
The syntax highlighting works which is a big benefit, but the warnings/errors don't.

With the interpolation, there's still warnings for empty XML nodes, and code completion.

[CyrusNajmabadi]

When I intentionally malform the XML, it also doesn't complain about it in combination with string interpolation.

Yeah, this makes it just a heuristic. We could consider that, but it's feels like it's full of caveats and can easily make people think code is fine when it's really not.

[Swimburger]

That makes sense, although the same would apply to the current attribute targets, no?

[CyrusNajmabadi]

This is solely about interpolated strings. Normal non-interpolated strings are fine and can be correctly analyzed in all contexts.

[svick]

Attributes generally tell something about a method to something outside that method. But here, the attribute would be only used inside the method itself. Because of that, I think the // lang=xml syntax, which works today, would be a better fit here.

[julealgon]

But here, the attribute would be only used inside the method itself.

@svick , wouldn't it be possible for the IDE itself to be able to leverage the attribute to display the text in a formatted/syntax-highlighted manner when hovering over a variable for example when in debug mode?

[arakis]

Because of that, I think the // lang=xml syntax, which works today, would be a better fit here.

Can you explain more about that // lang=xml feature please? I never heard about it. Where to apply that comment?

Edit: It seems to be a JetBrains Rider only feature: https://www.jetbrains.com/help/rider/Language_Injections.html#use-comments
Any plans to integrate that in VS also?

[julealgon]

Can you explain more about that // lang=xml feature please? I never heard about it. Where to apply that comment?

@arakis It is a comment that allows you to tell the format for a specific string argument/variable. Basically, an alternative to [StringSyntaxAttribute].

• [API Proposal]: System.Diagnostics.CodeAnalysis.StringSyntaxAttribute #62505

Edit: It seems to be a JetBrains Rider only feature... Any plans to integrate that in VS also?

It is not Rider-specific. It is already part of VS.

[arakis]

Amazing, i didn't know that. I never read about that little detail, is there any official documentation (except #62505).

By the way, it seems not to work with xml:

[CyrusNajmabadi]

no xml support has been added.

[julealgon]

...is there any official documentation (except #62505).

I'm actually interested in the answer to this myself. When I was searching to reply to your post @arakis I also was not able to find anything on MSDN at all. Then only thing I found was that git item.