Hi everyone,
I’ve been implementing SE-0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> (here <https://github.com/apple/swift/pull/3293>\) and have hit an issue around how Any.self is treated.
When in the type position, I parse Any like any other type, and resolve it to be an empty protocol composition in the constraint system <Implement SE-0095: Replace protocol<P1, P2> syntax with P1 & P2 by joewillsher · Pull Request #3293 · apple/swift · GitHub, in resolveTopLevelTypeComponent.
This does not work for metatype lookup, where the lookup is unconstrained and I need to find a ValueDecl for the Any type. Currently I have kept the stdlib’s typealias Any = protocol<> so the type system can look to the stdlib through getAnyDecl to find it. Does anyone have an idea about how this could be done without this; there are no other keywords that need this sort of unconstrained lookup and are implicitly declared?
Another question I had: does SE-0095 extend to SIL syntax? The proposal does’t mention it, but I think it would seem out of place to keep the protocol<> pattern in .sil if we are replacing it in .swift, the AST, and the demangler.
Thanks,
Joe
Hi everyone,
I’ve been implementing SE-0095 (here) and have hit an issue around how Any.self is treated.
When in the type position, I parse Any like any other type, and resolve it to be an empty protocol composition in the constraint system, in resolveTopLevelTypeComponent.
This does not work for metatype lookup, where the lookup is unconstrained and I need to find a ValueDecl for the Any type. Currently I have kept the stdlib’s typealias Any = protocol<> so the type system can look to the stdlib through getAnyDecl to find it. Does anyone have an idea about how this could be done without this; there are no other keywords that need this sort of unconstrained lookup and are implicitly declared?
A ValueDecl for a type shouldn't be required for a metatype expression, since something like (Int, String).self or (() -> ()).self ought to work too. Type resolution ought to handle this by turning the subexpression into a TypeExpr before we do type checking; see PreCheckExpression::simplifyTypeExpr.
Another question I had: does SE-0095 extend to SIL syntax? The proposal does’t mention it, but I think it would seem out of place to keep the protocol<> pattern in .sil if we are replacing it in .swift, the AST, and the demangler.
SIL mostly reuses Swift's type syntax, so this should fall out. You will want to ensure the demangler and the runtime use the new syntax when printing metatype values.
-Joe
···
On Jul 4, 2016, at 9:29 AM, Josef Willsher via swift-dev <swift-dev@swift.org> wrote: