Unseal StringSyntaxAttribute

[AndreVianna]

The StringSyntaxAttribute is very useful to add a syntax highlight to string parameters.
But because it requires to select the desired format it becomes very verbose.
For instance:

using System.Diagnostics.CodeAnalysis;

public string FormatValue(int value, [StringSyntax(StringSyntaxAttribute.CompositeFormat)] string format) {
   ...
}

Allowing us to inherit from the StringSyntaxAttribute we could define our own attribute for the specific method or just to shorter the attribute name.
For instance:

using System.Diagnostics.CodeAnalysis;

public class CompositeFormatStringAttribute : StringSyntaxAttribute {
    public CompositeFormatStringAttribute () : base(StringSyntaxAttribute.CompositeFormat) {
    }
}

public string FormatValue(int value, [CompositeFormatString] string format) {
   ...
}

I think that just unsealing the class would not cause a breaking change.
And the properties Syntax and Arguments used by the compiler would be inherited from the parent.
Simple type testing (is) can confirm the Attribute is of the correct type.

Please, consider.

[jnm2]

If the IDE sees [YourAttributeInheritingStringSyntaxAttribute], how will it know what string syntax to use? It can't execute the code inside an attribute, nor can it reliably access or introspect its implementation.

Maybe we need DerivedStringSyntaxAttributeAttribute: letting you apply [DerivedStringSyntaxAttribute(StringSyntaxAttribute.CompositeFormat)] on class FormatSyntaxAttribute so that the IDE can know what it means 😄

[AndreVianna]

The same way a very simple roslyn analyser would do.

1. Get the Attribute;
2. Check if is a descendant of StringSyntaxAttribute;
3. Check if it has a public parameterless constructor;
4. Create an instance; and finally
5. Get the value of the Syntax property.
   That should be enough for the IDE to color the string.
   If any of the steps fails the attribute is simply ignored and the IDE moves on.

Alternatively,
If it not practical to have the IDE to do all that analysis.

What is the point of having an attribute with a required parameter that can't be extended and is used in a very intrusive place (in the parameter list) with such long name. Just create multiple attributes.

Instead of:
[StringSyntaxAttribute(StringSyntaxAttribute.CompositeFormat)]
[StringSyntaxAttribute(StringSyntaxAttribute.Json)]
[StringSyntaxAttribute(StringSyntaxAttribute.DateOnlyFormat)]
etc...

Way not only:
[CompositeFormatString]
[JsonString]
[DateOnlyFormatString]
etc...

It is cleaner, clearer, and it will take the IDE the same effort to identify the attribute.

[huoyaoyuan]

Get the value of the Syntax property.

This step is impossible. All of the implementation bodies in attributes are opaque at compile time. What's seen at compile time is:

public class FormatSyntaxAttribute : StringSyntaxAttribute
{
    public FormatSyntaxAttribute() { throw null; }
}

[333fred]

Create an instance;

This is not something a roslyn analyzer would, or even could, do.

[AndreVianna]

OK.
If that is impossible give us multiple attributes.

[huoyaoyuan]

When working with attributes, the constructed attribute instance is very unimportant. It's a run-time only concept, which is impossible for many toolchains to utilize, including the compiler.
Instead, the attribute construction data, including explicit and default parameters specified in code, are much more important. It's a compile-time concept and will be materialized in compiled file.

That's why it's suggested against to have any logic in attributes, because they are totally inaccessible at compile time. To make your proposal possibly work, your attribute can only be defined as:

public class FormatSyntaxAttribute : StringSyntaxAttribute
{
    public FormatSyntaxAttribute(string syntax = StringSyntaxAttribute.CompositeFormat) : base(syntax) { }
}

Then the compiler can see the default parameter provided by to the constructor. The constructor will never actually execute. Only the parameter provided to it can be utilized.

[AndreVianna]

I understand your point.
Maybe, in my example I gave the idea that I would want to have the attribute to get multiple formats. I've updated the description to make clear that the Attribute would only signal of a single format.
My problem is with the verbosity of the code required to apply the attribute.
If the attribute must be sealed, and the list of syntaxes is closed and do not allow extensions, at least give us a list of attributes as I've mention in the reply to the post from @jnm2.

let me write:
public string FormatValue(int value, [CompositeFormat] string format)
instead of
public string FormatValue(int value, [StringSyntax(StringSyntaxAttribute.CompositeFormat)] string format)