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
Inline protocol implementations #802
Comments
wrt to (1), may be we can still generate the module, but do the inlining anyway? |
@yrashk We could but skipping the |
What are the implication of not generating the module besides the loss of the property? |
How about we make .beam file generation... optional (disabled by default for inlined impls?) |
@rafaelfranca I cannot think of anything we would lose. I raised this issue to see if someone can come up with extra drawbacks, including regarding the beam file. :) |
👍 This would allow me to implement Dict with a Protocol and not sacrifice performance. |
Closed in favor #950 |
Today, a protocol definition and implementation happens as follow:
When one calls:
It is then dispatched to:
I want to allow the following construct as well:
The example above will inline the
to_binary
implementation with the protocol one, giving the following advantages:However:
Binary.Chars.BitString
is no longer available, so we lose the property that every protocol implementation contains a module representing it (since in this case the implementation is inlined)If we are proceeding with this task, we should:
@moduledoc
false for all defimpl for default types@only
and@except
values on protocol pages__impl_for__
reflection from protocols (which I don't believe is used)The text was updated successfully, but these errors were encountered: