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
Defer monomorphization for data constructors #4376
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
e23ccb4
to
bb976a0
Compare
This PR hasn't gotten much conversation yet, so I guess I'll stop waiting for someone else to ask smart questions and instead start asking stupid questions. Why do we want this? Is it just to make the implementation of #4235 easier or simpler, or does it fix an independent issue? What exactly is happening here? The changelog indicates that the inferred type of Are there downsides or is there an argument that this is unambiguously what we should have been doing all along? |
The issue in the VTA context was briefly mentioned here: The issue is that the re-generalization would discard the VTA information, even though the constructors supported VTA by definition. |
Sure, but would we still want this change in the (probably counterfactual) world where we decide not to implement VTA? If so, why; if not, what consequences does this have for things that are not related to VTA? |
Description of the change
Related to #4235. This defers the monomorphization of data constructors introduced by #835. As such, constructors now infer to their "true" type, instead of having to go through generalization.
Checklist: