lang: add explicit type widening (As)
#122
Conversation
It's a simple value operator for making sure an expression is of the expected type, up-converting if possible, but without coercing. This is currently most useful for creating constructing unions.
The implementation is straightforward: making the sure the target type is valid, fitting the source expression to the target type, and discarding the type qualifiers is enough. Error correction (the lack thereof) for fitting errors is also fixed, so that no ill-formed `Expr`s are created.
`As` is used in-place of a custom procedure, significantly simplifying the tests.
| e = c.exprToIL(t, a) | ||
| typ = c.expectNot(c.evalType(t, b), tkVoid) | ||
| expr = inline(c.fitExpr(e, typ), stmts) | ||
| result = typ + {} # lvalue-ness and mutability are discarded |
There was a problem hiding this comment.
I'm still learning to read the source, but it seems that lvalue-ness and mutability dropping isn't there, I'm guessing it can't be represented?
I guess the drop is required right now because if we're actually widening the bits then a new location would be required?
There was a problem hiding this comment.
I'm still learning to read the source, but it seems that lvalue-ness and mutability dropping isn't there, I'm guessing it can't be represented?
It's there, albeit not easy to spot. exprToIL (the enclosing procedure) returns an ExprType, which is a type + qualifiers (ExprFlags, currently a bunch of flags), where the qualifiers track both mutability and lvalue-ness.
If the qualifiers were to be kept, the result assignment would look like this:
result = typ + e.attribs # e.attribs are the source expression's qualifiers I guess the drop is required right now because if we're actually widening the bits then a new location would be required?
Yep, that's the idea. If no widening takes place, then no new location is needed, so the lvalue-ness and mutability could be kept, but I decided against it because:
- to the human reader, a large context window is potentially required to know what a specific
Asdoes (the same problem exists in NimSkull with lvalue conversions) - the lvalue-ness/mutability changing depending on the target type could become an issue once/if per-procedure type inference is introduced
This doesn't have to (nor should it have to) be the final decision, however. If it turns out that the current rules are problematic (for whatever reason), we should alter them.
Summary
Add the
(As x typ)expression to the source language, which is usedto explicitly widen the type of a value.
xhaving a type that isequal to
typis not an error.Details
Astakes an expression and a type, fitting the former to the latterwhere possible, reporting an error if not. At the moment, it's main
use is constructing values of
UnionTytype, but in the future, it'llalso be useful for guiding type inference.
Implementation
Asdirectly into a type conversion throughfitExprExprs,by keeping or discarding the trailing expression depending on the
target type
Tests are added for
As, and existing tests for union types now useAsinstead of helper procedure for creating union values, greatlysimplifying the affected tests.
Notes For Reviewers