Skip to content

[API Proposal]: StringSyntaxAttribute.Guid #79655

Open
@NN---

Description

@NN---
Contributor

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

Activity

added
api-suggestionEarly API idea and discussion, it is NOT ready for implementation
on Dec 14, 2022
ghost

ghost commented on Dec 14, 2022

@ghost

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 added
untriagedNew issue has not been triaged by the area owner
on Dec 14, 2022
ghost

ghost commented on Dec 14, 2022

@ghost

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

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

Author: NN---
Assignees: -
Labels:

api-suggestion, area-System.Diagnostics, untriaged

Milestone: -
tommcdon

tommcdon commented on Jan 9, 2023

@tommcdon
Member
ericstj

ericstj commented on Jan 9, 2023

@ericstj
Member

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

stephentoub commented on Jan 9, 2023

@stephentoub
Member

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

NN--- commented on Jan 9, 2023

@NN---
ContributorAuthor

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

CyrusNajmabadi commented on Jan 10, 2023

@CyrusNajmabadi
Member

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

Joe4evr commented on Jan 10, 2023

@Joe4evr
Contributor

beyond Guid.Parse and friends, what APIs are taking guids as strings rather than Guids (and why)?

S.R.IS.GuidAttribute? Or did you already count that as a "friend"?

stephentoub

stephentoub commented on Jan 11, 2023

@stephentoub
Member

Or did you already count that as a "friend"?

I was thinking of it as a "friend". Mainly I'm wondering about use outside of the core libraries.

removed
untriagedNew issue has not been triaged by the area owner
on Feb 21, 2023
added this to the 9.0.0 milestone on Jul 10, 2023
tommcdon

tommcdon commented on Jul 10, 2023

@tommcdon
Member

Moving this feature request to .NET 9, feel free to pull back to .NET 8 if we plan on addressing this soon

stephentoub

stephentoub commented on Jan 15, 2024

@stephentoub
Member

Can anyone point to concrete examples where this would be used outside of the core libraries? Thanks.

NN---

NN--- commented on Jan 15, 2024

@NN---
ContributorAuthor

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

KennethHoff commented on Apr 25, 2024

@KennethHoff

Anywhere GUIDs are used in attributes this would be highly appreciated, which comes up often in Optimizely (EPiServer) CMS.

terrajobst

terrajobst commented on Jul 12, 2024

@terrajobst
Contributor

@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

stephentoub commented on Jul 15, 2024

@stephentoub
Member

what are your thoughts on supporting a Regex-based syntax representation as proposed #79655 (comment)?

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

KennethHoff commented on Jul 15, 2024

@KennethHoff

Roslyn could add something akin to IStringSyntaxProvider, but that's way bigger in scope.

terrajobst

terrajobst commented on Jul 15, 2024

@terrajobst
Contributor

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:

  1. 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).

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

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

terrajobst commented on Jul 15, 2024

@terrajobst
Contributor

@KennethHoff

Roslyn could add something akin to IStringSyntaxProvider, but that's way bigger in scope.

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:

  1. How many "small" languages exist
  2. Can they be formalized sufficiently to allow for a data-driven approach
  3. How much do we care making this easy
modified the milestones: 9.0.0, 10.0.0 on Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @NN---@Joe4evr@stephentoub@CyrusNajmabadi@terrajobst

        Issue actions

          [API Proposal]: StringSyntaxAttribute.Guid · Issue #79655 · dotnet/runtime