37 lines
1.4 KiB
Markdown
37 lines
1.4 KiB
Markdown
# C# Language Design for Aug 21, 2017
|
|
|
|
***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
|
|
|
|
|
|
# Type classes
|
|
|
|
Multiple implementations (ints and groups)
|
|
- You can explicitly provide the type argument for an implicit type parameter
|
|
- (but it might get messy)
|
|
|
|
|
|
Need explicit instance
|
|
- Nothing fundamental preventing a more structural approach
|
|
- Two levels of inference possible:
|
|
- a: explicit instance, infer members
|
|
- b: implicit instance even
|
|
|
|
|
|
To bridge to existing interface-based abstractions, you can just provide a very general, generic instance
|
|
|
|
|
|
Need an implicit type parameter but don't use it. Maybe a bit too magical. Might be better to require dotting off of the implicit type parameter. For operators that would be nice, though.
|
|
|
|
|
|
Instance members? need some syntax like extension methods, maybe, or like explicit interface implementation.
|
|
|
|
|
|
Concepts can be for more than one type, so they are not always tied to a single domain type. This may be a step too far, but it does have real value: Graph algorithms that have both Node and Edge types.
|
|
|
|
Main competitor, conceptually, would be something that allows for interfaces to play the role of concepts. That comes with challenges of its own, and lots of limitations. But that sort of the thing you have to justify why you're not.
|
|
|
|
|
|
Could you use this to make the environment of a lambda a struct? Combined with closures as structs, passed by ref.
|
|
|
|
|
|
|