[Proposal] Generic constraint - specific type

[KalitaAlexey]

func<T>()
    where T : int or float

[whoisj]

👍 I've wanted this for years. Better if it can be a list of types. Perhaps with some rollup types like integral meaning byte or sybyte or int or long or uint or ulong or float or double.

[KalitaAlexey]

This is one of main purposes for what people want templates in C#

[HaloFour]

This would require some changes to the CLR as currently it's not legal to have multiple non-interface type constraints. The number of use cases might be fairly small as the IL for the method needs to be identical regardless of what the generic type arguments might be. Assume the following:

public T Add<T>(T x, T y) where T : double, int {
    return (x + y);
}

That could be legal since the IL for handling double and int are the same, but you couldn't add short as another constraint since the IL would need an additional conv.i2 instruction.

Update: Yes, if C# had a notion of compile-time templates this problem could be solved with quite a bit more flexibility, but that opens a completely different can of worms.

[whoisj]

@HaloFour I'd love compile-time templates! Somebody should post a proposal up 😉

[KalitaAlexey]

@HaloFour I want to this work like generics work. Let all what is used be instantiated on use.
Or if it require CLR support let method

private void Add<T>(T x, T y) where T : (int or double) {
}

will be expanded on compile-time to

private void Add(int x, int y) {
}

private void Add(double x, double y) {
}

And then will be used appropriate version.
Let it will be shortcut now. And then add CLR support.
I'd love to use it

[OJacot-Descombes]

The real problem here are not the generic constraints, but the lack of a common numeric base type or an interface definining the basic arithmetical operations.

[HaloFour]

Either would require heap allocations and virtual calls instead of using
the proper (and infinitely simpler but type dependent) IL opcodes. In
theory the JIT could figure that out and emit optimized native code.

On Thu, Jun 4, 2015, 7:36 PM OJacot-Descombes notifications@github.com
wrote:

The real problem here are not the generic constraints, but the lack of a
common numeric base type or an interface definining the basic arithmetical
operations.

—
Reply to this email directly or view it on GitHub
#3255 (comment).

[Thaina]

related : #2146

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.