-
Notifications
You must be signed in to change notification settings - Fork 2
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
pattern vs standard specializers #3
Comments
At which level should this happen? I can imagine at least three possibilities:
|
Jan Moringen [email protected] writes:
I think both of these are necessary -- point (1) because then the As well as these, there's also the issue of constructing specializer |
To summarize
One of the remaining questions is how to compute
Independent of this choice, I think the "fall back to the next |
Suggested-by: Christophe Rhodes in #3.
* Adapt ACCEPT-SPECIALIZER, CONS-SPECIALIZER, PROTOTYPE-SPECIALIZER Suggested-by: Christophe Rhodes in #3. for arg-position
I think it would be really nice if
class
andquote
pattern specializers (without any further restrictions or variable bindings) were treated identically to the standardclass
andeql-specializers
. This would allow the brave user to default to using pattern generic functions, and only paying for the cost when a non-trivial pattern specializer is actually included on a generic function.The text was updated successfully, but these errors were encountered: