[swift-evolution] Tuple subtype problem

[Slava Pestov]

Hi Cao,

You’re right, this should be fixed some day. The constraint system understands the subtyping relation here. The diagnostic is generated by the rewriting pass, which currently has no way to express tuple conversions in the AST since its slightly tricky.

A tuple conversion needs to be able to wrap each component of a tuple in its own expression, since subtyping conversions can get pretty hairy and involve multiple nested Exprs. Think if a conversion as a lambda form, like \(x,y)->(f(x),g(y)), that we’re applying to some tuple value that results from evaluating some other expression.

The way to do this in the AST is with OpaqueValueExprs, which are already used for opening protocol existentials:

(open_existential_expr
    (opaque_value 1)    ;; first sub-expression — establish a binding for the existential payload and type
    (apply_expr … (opaque_value 1))    ;; second sub-expression — do something with the payload — the result of this expression is the result of the whole OpenExistentialExpr
    (load_expr someVar))    ;; third sub-expression — this is something that evaluates to an existential type, and is bound to the opaque value in the first expression

There needs to be a new TupleConversionExpr or similar that also uses OpaqueValueExpr in the same manner, except now we have several opaque values, one for each component of the tuple being destructured:

(tuple_conversion_expr
    (tuple_expr     ;; first sub-expression — establish bindings for components of a tuple value — this is sort of like the left hand side of ‘.’ in a lambda expression \(x,y).(f(x),g(y))
        (opaque_value 1)
        (opaque_value 2))
    (tuple_expr    ;; second sub-expression — define result of conversion in terms of the bindings
        (upcast_expr (opaque_value 1) A)
        (upcast_expr (opaque_value 2) A))
    (load_expr tupleB))    ;; third sub-expression — input tuple for conversion, must have same number of components as the input pattern

Then SILGen needs to know how to lower these, by evaluating the input expression, loading its components as individual values, binding them to the unique OpaqueValueExprs in the first expression, and finally evaluating the result to yield the ultimate result of the tuple conversion.

It would be great if someone could take a look at this :)

Slava

> On Feb 15, 2016, at 10:47 PM, Cao Jiannan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Another problem about sub-typing system in Swift is tuple.
> 
> Why tuple does not support sub-typing feature?
> 
> for example:
> 
> class A{
> 
> }
> 
> class B:A {
> 
> }
> 
> let tupleB:(B,B) = (B(),B())
> let tupleA:(A,A) = tupleB
> 
> 
> This should be allowed in Swift. But a compiler typing-check error.
> 
> Thanks!
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/7429beb7/attachment.html>