How do I know notnull, use type or kind, not use string.

[zms9110750]

i have

public void Hello3<T, H, E, G>()
 where T : class, E, new()
 where E : notnull, IList<E>, IEquatable<E>, new()
 where H : unmanaged, allows ref struct
    where G : unmanaged
{
}

but

class                     :       ClassConstraint
E                            :       TypeConstraint
new()                     :       ConstructorConstraint
notnull                   :       TypeConstraint
IList<E>                  :       TypeConstraint
IEquatable<E>        :       TypeConstraint
unmanaged             :       TypeConstraint
allows ref struct       :       AllowsConstraintClause
unmanaged             :       TypeConstraint

i want IList<T> => global::System.Collections.Generic.IList<E>. ti's is TypeConstraint
but unmanaged and notnuul is TypeConstraint too

[333fred]

Sorry, I have no idea what you're asking here.

[zms9110750]

Sorry, let me start from the beginning.

When the user writes:

global using IList = System.Int32;

Then I cannot write in the source generator:

where E : IList<E>

I must write instead:

where E : global::System.Collections.Generic.IList<E>

These type parameter constraint types can be found in IMethodSymbol.TypeParameters.ConstraintTypes.

But what about these constraint types: unmanaged, allows ref struct, class, notnull, new()?

I can find them in MethodDeclarationSyntax.ConstraintClauses.Constraints.

Then I can check with if (item is TypeConstraintSyntax) or if (item.Kind() == SyntaxKind.TypeConstraint).

If neither condition is met, then it's a keyword constraint.

However, these two approaches have exceptions for unmanaged and notnull.

So currently I have to use: if (item is TypeConstraintSyntax typeConstraint && typeConstraint.Type.ToString() is not "unmanaged" or "notnull")

But I don't like working with strings - if I make a typo, it's hard to detect. So I'm looking for a way to do this without string comparison.

[CyrusNajmabadi]

since you have an ITypeParameterSymbol, look at the properties on it. For example: https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/Symbols/ITypeParameterSymbol.cs#L75 and https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/Symbols/ITypeParameterSymbol.cs#L70

[zms9110750]

@CyrusNajmabadi

Oh, yes. That would indeed work. However, if new APIs are introduced, I would also need to update my code accordingly.

For example, allows ref struct is a relatively new constraint.

If I don't keep up with language version updates, I would get incorrect results.

Therefore, for those constraints that I haven't specifically considered, I want the logic to simply copy them regardless of what they are, rather than ignoring them just because I haven't accounted for them.

[CyrusNajmabadi]

However, if new APIs are introduced, I would also need to update my code accordingly.

Yes. That's correct.

Therefore, for those constraints that I haven't specifically considered, I want the logic to simply copy them regardless of what they are, rather than ignoring them just because I haven't accounted for them.

There is no reason to believe that's the right thing to do. As new language features are added, you must consider what it would take to support them.

We do not supply any sort of generalized "as the language changes, solve the problem for me of generating code that is correct based on my domain needs" for all types of symbols.

[zms9110750]

However, it's quite obvious that directly copying constraints has a much lower chance of causing errors compared to having nothing happen at all.

My logic is simply to distinguish between type constraints and other constraints. If it's not a type constraint, then just copy them as they are.

Oh, and one more thing - checking the syntax declaration serves another purpose. Some constraints can only appear in the first or last position.

So keeping them in their original positions through direct copying would be simpler.

[CyrusNajmabadi]

If you want to copy the original syntax, then go to the original syntax and copy that.

However, it's quite obvious that directly copying constraints has a much lower chance of causing errors compared to having nothing happen at all.

That is not obvious to me. But if htat's an acceptable resolution for your domain, then feel free to write your logic to do that. Nothing is stopping you :) You get to decide what is ok for your own code needs.

My logic is simply to distinguish between type constraints and other constraints. If it's not a type constraint, then just copy them as they are.

If you are using syntax, you can examine the syntax to determine it. And yes, that does mean now understanding the relationship between syntax and semantics (for example, that 'notnull' could bind to a type called 'notnull' or could fallback to having new keyword meaning):

So keeping them in their original positions through direct copying would be simpler.

Do whatever you feel is simpler. I'm just explaining what is available in the API to model analysis/introspection of the code. The generation side is up to you.

If you want to talk more about this, i def recommend our discord channels.

[zms9110750]

This is really astonishing. Writing code that considers all possible scenarios is truly difficult.
Although it's hard for us to access foreign websites (GitHub access is also very slow),
where can I find the entry method for that Discord channel? I'll take a look.

[CyrusNajmabadi]

This is really astonishing. Writing code that considers all possible scenarios is truly difficult.

Yes. And different scenarios will require entirely different approaches. Good examples are how interface-impls and overrides have a very different set of rules about how constraints have to work.

where can I find the entry method for that Discord channel? I'll take a look.

https://discord.com/invite/tGJvv88

Cheers.