-
Notifications
You must be signed in to change notification settings - Fork 434
Remove DynType
and resculpt ast::Type
#1322
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
base: master
Are you sure you want to change the base?
Conversation
@audunhalland it would be nice if you provide some input of this, if you have time to spare. Thanks! |
@tyranron I had a look, it's something like this I imagined. A variation of the The advantage of this is that the |
@audunhalland the reason I've used Thanks for the tip! It's very helpful. I'll think on it more and will try to do something of it. |
Follows #1247
Synopsis
In #1247 the
ast::Type
was made generic over the string type used for name.In the codebase, there are numerous places where it's required to convert both
ast::Type<ArcStr>
andast::Type<&str>
to some singular representation stored inValidatorContext
or similar places.However, the current
ast::Type
enum representation usingBox
es introduces a problem that it's not possible to cheaply receive a borrowed version ofast::Type<ArcStr>
asast::Type<&str>
without re-allocating all thoseBox
es. Furthermore, usingBox
es involves redundant re-allocations onClone
ing even when&str
is used.Thus, @audunhalland came up with a temporary
DynType
solution to solve this problem:The problem with this solution, that it duplicates
ast::Type
inner logic and pollutes some potentially public APIs.Solution
As @audunhalland kindly suggested in TODO comment:
This PR resculpts
ast::Type
in this manner:Checklist
CHANGELOG.md
updated