-
Notifications
You must be signed in to change notification settings - Fork 29
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
Generics #6
Comments
Option 2 feels more intuitive, I will do a quick spike with that. |
Yes, I would not recommend option 1. |
Quick and dirty working program to prove that there exists a program that will compile and run and produce the result I expect: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4c28796d072a15bec7f6464f6a78d063 |
Deemed to not possible for implementation using the approach taken by this library. PRs have been closed and so should have been this issue. Closed. |
As a follow up to #3, from @Robbepop: #3 (comment). Should be included in a
0.1
release.Seeing this we still have the problem that our encoding is not generics-aware which it should imo. So we end up having a different type definition for each
Option<T>
with a differentT
instead of re-using the one generic definition. I have made some thoughts about this and came to the conclusion that it should even be fairly simple to actually implement this with some additional built-ins.There are actually 2 ways we could implement this:
By introducing two new built-in type classes
generic_type
andgeneric_param
:By introducing flags for all
type
fields:The text was updated successfully, but these errors were encountered: