First class modules avoid some of the problems with protocols/typeclasses but it seems like it would be more verbose in many cases - what is the state of the art here?
We thought about doing something like that but decided against it because it seemed like it would have unknown ramifications. Figured it was better the devil you know (typeclasses)
-
-
I think I was the one who proposed to just do typeclasses with a no-orphan-instances check. Memory is a bit fuzzy.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
At runtime, generic parameter conformances are stored in the type metadata alongside the parameter types - so Set<Int> has Int followed by the Int : Hashable witness table. Makes sense to use both as part of the uniquing key
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
It’s more or less what you get in a system with explicit applicative functors. I agree though that in a system that tries to hide the module-ness like Swift does, it would take a lot of diagnostics work to make it usable if we promoted overlapping instances
-
Yeah, what worried me was the action at a distance. Having “use” declarations at the top of the module subtly and invisibly affecting the semantics of the rest of the module is scary.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.