fslang-suggestions
fslang-suggestions copied to clipboard
fsharp
Allow implementation of generic methods with constraints of the form 'T :> 'U
Allow implementation of generic methods with constraints of the form 'T :> 'U [5927125]
Submitted by Gusty on 5/14/2014 12:00:00 AM
136 votes on UserVoice prior to migration
Currently this is solved as 'a = 'b. This limitation does not exists in C# and it makes impossible to interact with some existing libraries, as in this case http://stackoverflow.com/questions/23643989/is-it-possible-to-implement-the-idbsett-interface-in-f This will also allow to work around F#'s lack of generic (co/contra)-variance.
Original UserVoice Submission Archived Uservoice Comments
And this https://github.com/fsharp/fslang-suggestions/issues/566 and this https://github.com/fsharp/fslang-suggestions/issues/629
Yes please, would also be immensely helpful for abstracting away asp.net core apis behind a nicer functional api.
@cartermp this is impossible to do today for say the whole DI stack as many methods are of the form <'TService, 'TImplementation when 'TImplementation :> 'TService>.
Had this issue many times also and would welcome this change/improvement
@dsyme, are there any serious drawbacks to implementing this, or can you 'approve in principle'? I'd assume an RFC is needed.
I'd also be interested if there's a workaround available to achieve this.
@abelbraaksma Here's the current situation: The constraint solver engine of F# has no ability to represent constraints of this form - constraints "T :> U" are solved to "T = U" immediately.
This doesn't block adding the feature: we could add this form of constraint and delay solving them until U is a nominal type. We would perhaps somehow have to require that the solution for U arrives earlier rather than later (at the worst you could require that it is explicit in an instantiation on each use of the generic thing, the most extreme approach)
How do you mean @dsyme ? I guess this property used often in c# isn't useful in regular f# code. I guess a workaround is to write an interface in a c# assembly?
This is a highly upvoted suggestion and reading @dsyme's comment it appears that there aren't any serious technical drawbacks, albeit that it may not be trivial to implement. Can we mark this approved-in-principle so we can weed out the details in an RFC (/cc: @dsyme, @cartermp)?
The issue looks far more severe. A simple C# + F# interop seems to fail. Basically, it means that C# code with generic constraint that some generic class inherits from some generic interface cannot be consumed in F#.
The example is posted here: https://stackoverflow.com/questions/64103022/f-generic-constraint-to-have-one-generic-type-inherit-from-another .
@dsyme, I'd call it a bug in F# compiler and/or the type system.
The issue looks far more severe. A simple C# + F# interop seems to fail.
There are a lot of cases where C# interop fails, it's a matter of choice how much of C# we'd interop. Sure, that's a good argument to introduce a new feature, but that doesn't make it a bug. I mean, we could then label any missing feature as a bug. This was a conscious decision as this thread has shown and requires a significant effort to implement.
@dsyme, I'd like to move forward with drafting an RFC, if you'd agree in principle ;)
I am sure that my exposure to C# - F# interop is very limited, as this is the first time ever when I encountered that F# cannot consume C# code no matter what. However, the severity of this problem (and I am talking about the interop one, not the original pure F# one) is due to the fact that such constraints power DI, which is a de facto standard in C# world.
And I have not even started talking about the things like this one:
public abstract class SetBase<T, TValue> : IEquatable<T>, IComparable<T>
where T : SetBase<T, TValue>
where TValue : IComparable<TValue>
{
...
}
which then can be used to produce some really cool stuff...
As much as I like F# (and these days I always choose it for my personal projects), the inability of F# to perform an interop with C# (which is a much bigger cousin) in one of the crucial junction points is scary. I don’t know why, but it seems that F# already has a fairly steep learning curve among C# developers (only a handful of C# developers that I know actually do know and/or willing to learn F#, no matter what). With that in mind, I’d call the inability of F# to consume C# code that powers DI as a severe constraint to the language progress...
@kkkmail these constraints:
where T : SetBase<T, TValue>
where TValue : IComparable<TValue>
Should work in F#, what's not currently supported is when on the right side you have a generic type variable.
I'm marking this as approved in principle because it's reasonable that it is possible to at least define, and, in some cases, use these methods in F#.
However it's not a simple issue to solve.
@dsyme thanks for approving this. I'm mulling over the details for an RFC atm.
Any progess on this?
Unfortunately, no it seems. Still needs RFC. @abelbraaksma do you need a hand with it?
@vzarytovskii thanks for the ping. I totally forgot (so long ago, sorry guys!). Fun fact, I was hit by this again a few days ago but didn’t find this issue. Anyways, I’ll follow up shortly.
@vzarytovskii is there a way we can enable assign to in this repo? With all github work going on, it is non-trivial to keep track of one's open items, but assigning it at least makes it stand out.
@vzarytovskii is there a way we can enable
assign toin this repo? With all github work going on, it is non-trivial to keep track of one's open items, but assigning it at least makes it stand out.
Not sure what do you mean? Like assigning to whoever works on RFC/etc? I'm not an admin for repo/org. Probably @dsyme can enable it?
Yeah, I mean that thing top-right that says “assignees”. It’s very useful to signal to the rest of the community that you’re working on something. At the same time, in your notifications, they will stand out until an issue is resolved (or you unassign).
But currently, it’s not enabled (or maybe only for maintainers/ admins).
@cartermp thanks! Isn't it simpler if we just allowed contributors to self-assign any issue? Just a suggestion :).
@cartermp thanks! Isn't it simpler if we just allowed contributors to self-assign any issue? Just a suggestion :).
I don't think GH is that granular, is it?
I do not see GH having it, but maybe a self-assigning action after specific comment text could do it. /selfassign
Mmm, yeah, it appears GH is quite lacking here. To assign, you need write access. I’d understand for assigning just anybody, but for self-assign this shouldn’t be so restrictive. Well, it explains why this feature (which could be so, so useful!), is barely used in the wild afaict.
https://stackoverflow.com/questions/26752902/how-to-assign-issue-to-myself-at-github#26761256