[swift-users] Constrained protocol extensions

[apetrovic@outlook.com]

Hi Ian,

You're right, if there's a function that's specialized everything works well (actually, I deleted exactly the same function from my example, in an attempt to be brief and succinct :) ). But that kind of ruins the whole point of interface specialization and violates the principle of least surprise, don't you think?

I don't have enough knowledge about how Swift compiler implements generics to speculate is the "right" solution possible or not. If the compiler emits different implementations for functions testPrint<Int> and testPrint<String>, then it definitely have enought info to pick the right specialized implementation, and this is a bug; If not... well, then it's probably best to remove the whole feature from the language.

Alex

On June 9, 2016 at 16:05:47, Ian Terrell (ian.terrell at gmail.com) wrote:

Hi Alex,

This is definitely a little confusing. I think it may be intentional behavior though.

I don't believe it's tied to scope, but tied to the fact (I think!) that all generic specialization methods are statically dispatched.

Although it looks like the printMe method chosen would be based on the T of the specialized class at runtime, it's actually based on the T of the printPrinter method at compile time. At that time printPrinter has no information about T, and so it is tied to the general version of printMe. You can see that if you add a specialized printPrinter method:

func printPrinter<T: SignedIntegerType>(printer: PrintClass<T>) {
    printer.printMe()
    testPrint(printer.value)
}

Now the further constrained version of printPrinter is called, which calls the further contrained version of printMe.

I hope this helps! And I hope if I got anything wrong someone chimes in to correct me. :)

Ian





On Wed, Jun 8, 2016 at 4:44 PM, Aleksandar Petrovic via swift-users <swift-users at swift.org> wrote:
Hi swift-users,

I'm trying achieve something similar to C++ template specialization with protocol extensions, and I found a strange behavior: 

// ----------

protocol Printer {
    associatedtype TestType
    var value: TestType { get }
    func printMe()
}

extension Printer {
    func printMe() {
        print("Base printer: \(value)")
    }
}

extension Printer where TestType: SignedIntegerType {
    func printMe() {
        print("Int printer: \(value)")
    }
}

func testPrint<T>(value: T) {
    print("testPrint")
}

func testPrint<T where T:SignedIntegerType>(value: T) {
    print("testPrint for int")
}


class PrintClass<T>: Printer {
    var value: T
    init(value: T) { self.value = value }
}

func printPrinter<T>(printer: PrintClass<T>) {
    printer.printMe()
    testPrint(printer.value)
}


let intPrinter = PrintClass(value: 42)
let stringPrinter = PrintClass(value: "test value")

intPrinter.printMe()                    // Int printer: 42
stringPrinter.printMe()               // Base printer: test value

testPrint(intPrinter.value)          // testPrint for int
testPrint(stringPrinter.value)     // testPrint

printPrinter(intPrinter)               // Base printer: 42    (!!!)
                                                 // testPrint                (!!!)

// ----------

The compiler correctly chooses specialized protocol extension as long as the function call is in the same scope with the object declaration. But all knowledge about types seems to be lost in the last line, when the scope is changed, in function printPrinter(). 

Is this a bug or desired behaviour?

Alex


_______________________________________________
swift-users mailing list
swift-users at swift.org
https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160609/37bb2a25/attachment.html>