> On Feb 5, 2017, at 8:28 AM, Abe Schneider via swift-evolution > <swift-evolution@swift.org> wrote:
> The suggested method to get around this issue is to use a protocol to create > a witness table, allowing for runtime dispatch. However, this approach is not > ideal in all cases because: (a) the overhead of runtime dispatch may not be > desirable, especially because this is something that can be determined at > compile time; and Just as the compiler is able to generate specializations of generic functions, it can also devirtualize protocol method calls. The two optimizations go hand-in-hand. > One potential solution would be to add/extend an attribute for generic > functions that would force multiple versions of that function to be created. > There is already there is a `@_specialize` attribute, but you have to: (a) > manually write out all the cases you want to cover; and (b) only affects the > compiled code, which does not change this behavior. Due to the fact that > `@_specialize` exists, I’m going to assume it wouldn’t be a major change to > the language to extend the behavior to compile-time dispatch. In Swift, specialization and devirtualization are optimization passes which are performed in the SIL intermediate representation, long after type checking, name lookup and overload resolution. In this sense it is completely different from C++, where parsed templates are stored as a sort of untyped AST, allowing some delayed name lookup to be performed. Implementing C++-style templates would be a major complication in Swift and not something we’re likely to attempt at any point in time. The combination of specialization and devirtualization should give you similar performance characteristics, with the improved type safety gained from being able to type-check the unspecialized generic function itself. > > > Thanks! > Abe > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
