PatternSynonyms and ConstraintKinds should not be required at the use site.
Currently both PatternSynonyms and ConstraintKinds have to be enabled at the usage site, not just at the construction site.
This pretty much ensures that they'll never be used to 'clean up' or virtualize an existing API, because switching to pattern synonyms for constructors or switching a 'class alias' to a type synonym immediately break all users.
For instance right now, as a user I universally write
class (Foo a, Bar a) => Baz a
instance (Foo a, Bar a) => Baz a
rather than
type Baz a = (Foo a, Bar a)
because the former gives a better user experience and I can pay all the extensions needed for it at the definition site, rather than have all my users pay them at the use site.
I'd like to propose that the language extensions for these two cases, PatternSynonyms
and ConstraintKinds
only be required at the definition site, rather than at the use site.
The former is definitely needed at the definition site because of the new syntax, but unless you explicitly re-export a pattern, no syntax changes at the usage site.
This would also be more consistent with existing policies for other extensions:
We don't require users to turn on FunctionalDependencies to get the benefit of functional dependencies, or to turn on MultiParamTypeClasses to use an MPTC, merely to define them.
Trac metadata
Trac field | Value |
---|---|
Version | 7.8.3 |
Type | FeatureRequest |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |