-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add constraints as a language construct #456
Comments
William Blum commented · May 01, 2016 21:08Thanks Don for sharing the Gist but unfortunately the type alias trick does not solve the problem for purely static member constraints. In the following example for instance I want to express the same set of constraints for both ^T1 and ^T2 without having to repeat them. type Combine< ^T1,^ T2 when
^T1 : (static member print : string -> unit)
and ^T1 : (static member flush : unit -> unit)
and ^T2 : (static member print : string -> unit)
and ^T2 : (static member flush : unit -> unit)
> =
static member inline printAndFlushBoth m =
(^T1:(static member print : string -> unit) m)
(^T2:(static member print : string -> unit) m)
(^T1:(static member flush : unit -> unit) ())
(^T2:(static member flush : unit -> unit) ()) Following your gist I could define a type alias encoding the two constraints (write and flush) but my constraints being entirely static I have no way to refer to the type alias it in a type annotation since there exist no variable of static type. Another benefit of named constraints is that the 'comparison' and 'equality' constraints could be defined in the F# core library instead of being hard-coded in the language. Do you have another trick up your sleeve for the above example? If not, would you consider reopening this suggestion? |
Don, in your gist, you can't use the members without restating the constraints, what the point? I think Jared was after something like this: let inline go_wild (beast:^a when ^a: eatsDrinksSleeps) =
(* *) beast.chews "snack"
(* *) beast.drinks "potion"
(* *) if not beast.Hungry then printfn "BURP!" not something which force to state the constraint in a cryptic way at each usage of beast. |
Don Syme commented Because it is already possible to name sets of constraints using the technique below, I am going to decline this request. Also the request #243 is overlapping and can be used to cover the general suggestion to have a trait/constraint/type-class facility in the language |
Don Syme commented · February 04, 2016 16:49This gist shows how to name collections of member constraints today: https://gist.github.com/dsyme/bfed2eed788c7ba58ccc |
exercitus vir commented · June 22, 2015 13:32Related suggestion: #451 The advantage of that suggestion is that it simplifies the syntax of explicit member constraints, does not require a new keyword (albeit a new operator) and can reuse existing interfaces and its syntax. |
Submitted by Jared Hester on 6/22/2015 12:00:00 AM
36 votes on UserVoice prior to migration
Allow the declaration of named constraints that can have other named constraints nested within them and are resolved at runtime or compile time based on their structure , e.g.
They could also be defined on flexible types that take generic parameters -
Response
** by fslang-admin on 2/10/2016 12:00:00 AM **
Thanks for the suggestion. It is entirely reasonable and it’s taken me a long time to mark it as declined. I’ve listed the reasons below – and /archive/suggestion-5762135-support-for-type-classes-or-implicits can be used as a placeholder for requests in the type-class/constraint area
Don Syme
F# Language Evolution
Original UserVoice Submission
Archived Uservoice Comments
The text was updated successfully, but these errors were encountered: