Open
Description
Background and motivation
There is already StringSyntaxAttribute.GuidFormat but there is no syntax for GUID.
a proposal is to add StringSyntaxAttribute.Guid which expects GUID in one of allowed formats which Guid.Parse understands: B, D, X.
API Proposal
namespace System.Collections.Generic;
public class MyFancyCollection<T> : IEnumerable<T>
{
public void Fancy(T item);
}
API Usage
void f([StringSyntaxAttribute.Guid)] string guid){}
Alternative Designs
No response
Risks
No risk
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
ghost commentedon Dec 14, 2022
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 commentedon Dec 14, 2022
Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.
Issue Details
Background and motivation
There is already StringSyntaxAttribute.GuidFormat but there is no syntax for GUID.
a proposal is to add StringSyntaxAttribute.Guid which expects GUID in one of allowed formats which Guid.Parse understands: B, D, X.
API Proposal
API Usage
Alternative Designs
No response
Risks
No risk
api-suggestion
,area-System.Diagnostics
,untriaged
tommcdon commentedon Jan 9, 2023
@ericstj @karelz
ericstj commentedon Jan 9, 2023
It looks like this is related to #62505 and #65634
GuidFormat
is only for specifying the format specifiers and we don't have anything that would validate a string for actual GUID syntax.@stephentoub @CyrusNajmabadi it looks like you were involved with this feature during 7.0 - any thoughts on the request?
stephentoub commentedon Jan 9, 2023
I'd be interested in seeing some examples where we expect this would be used, e.g. beyond Guid.Parse and friends, what APIs are taking guids as strings rather than Guids (and why)? But assuming there's a reasonable number of them, it'd be reasonable to add this.
NN--- commentedon Jan 9, 2023
If it was possible to specify the validation using regular expression and not by only predefined types, this feature would be generic enough to cover almost any need.
E.g.
[StringSyntax(@"\d{4}-\d{4}")] string twoNumbers
CyrusNajmabadi commentedon Jan 10, 2023
So, from the roslyn perspective, what we're working on is making this an extensible system. For example, the ASP.Net 'route syntax' support is provided through a plugin provided by the asp.net team. This takes the costs off of us, and allows API owners to determine if they want to invest in this space.
We are committed to Regex and Json, but we're not likely to add more languages ourselves. In a case like this, we would just expose the same extensibility point and let the Guid owners decide if they wanted to add anything here.
Joe4evr commentedon Jan 10, 2023
S.R.IS.GuidAttribute
? Or did you already count that as a "friend"?stephentoub commentedon Jan 11, 2023
I was thinking of it as a "friend". Mainly I'm wondering about use outside of the core libraries.
tommcdon commentedon Jul 10, 2023
Moving this feature request to .NET 9, feel free to pull back to .NET 8 if we plan on addressing this soon
stephentoub commentedon Jan 15, 2024
Can anyone point to concrete examples where this would be used outside of the core libraries? Thanks.
NN--- commentedon Jan 15, 2024
I have a project using string type for GUID.
Changing everything to use type Guid is a big breaking change and there is no built-in way specifying whether I want braces or not when serializing data.
KennethHoff commentedon Apr 25, 2024
Anywhere GUIDs are used in attributes this would be highly appreciated, which comes up often in Optimizely (EPiServer) CMS.
terrajobst commentedon Jul 12, 2024
@CyrusNajmabadi @stephentoub what are your thoughts on supporting a Regex-based syntax representation as proposed here?
Supporting open-ended Regexes has its issues, mostly because they could be written in a way that can make them dog-slow. However, I like the fact that it allows people to quickly add support for simple syntaxes with basic validation.
stephentoub commentedon Jul 15, 2024
There are multiple things that identifying an argument as a particular syntax enables, including colorization (e.g. different parts of a regex being colored differently), coarse valid / not-valid validation (e.g. does this parse or not), more fine-grained validation (e.g. the JSON string is missing a closing brace), IntelliSense menus (e.g. the drop-down you get showing all the different datetime format options), etc.
The regex you're citing would be solely about the coarse valid / not-valid validation and none of the other aspects?
KennethHoff commentedon Jul 15, 2024
Roslyn could add something akin to
IStringSyntaxProvider
, but that's way bigger in scope.terrajobst commentedon Jul 15, 2024
I haven't designed this in detail; it was more of a question whether we want to lower the bar for simple syntaxes using data in the attribute, rather than having to build extensions into analyzers/IDE colorizers that process specific language names.
I'd imagine if we go down this path, then there are several aspects to coonsider:
Expose a regex for tokenization which could be used for colorization. This would likely require named capture groups to indicate a specific built-in color group (e.g. "number", "whitespace", "text" etc).
Expose a regex for validation. If the regex matches the entire input it's considered valid, if not a diagnostic is raised. Presumably this regex could be optional and if not provided use the first one to make sure the text is a sequence of tokens.
Instead of an attribute, we could allow some kind of well-known file format (e.g. a TextMate file) that people can add to their project file that the IDE and an analyzer could use.
I'm not convinced that this is necessary yet. But if there are enough "small languages" like GUIDs, then this seems like a better direction than having to decide for each language if we add support for it or leave it to third parties as the barrier of entry for a third party seems fairly high.
terrajobst commentedon Jul 15, 2024
@KennethHoff
I'm not sure it's bigger in scope because if we go down the path to allow the user to provide data regardless of mechanism, we'd want Roslyn to light up on this. I suspect this likely would result in an extension point like that, if that doesn't exist already anyway.
However, from the user's perspective extending Roslyn (at the compiler level or IDE level) requires much more work.
So the question is really: