[swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

Ramiro Feria Purón ramiro.feria.puron at gmail.com
Fri Dec 2 06:37:57 CST 2016


Anton,

Thanks for the explanation. Interesting!

I can understand the difference [I assume you are using the term template
specialization (developer code to provide a special implementation for
specific generic arguments) to refer to the term template instantiation
(compiler generated code for a set of actual generic arguments)]; however I
believe this is an implementation detail that should not influence
higher-level decisions unless it is strictly necessary. At the moment I
fail to see why it needs to be so.

Regards,
Ramiro

On Fri, 2 Dec 2016 at 22:34 Anton Zhilin <antonyzhilin at gmail.com> wrote:

> 2016-12-02 3:55 GMT+03:00 Ramiro Feria Purón <ramiro.feria.puron at gmail.com
> >:
>
> *Unlike C++'s templates, a Swift's generic function is semantically a
> single function.*
>
> Anton, could you provide further insight on this?
>
>
> Basically, generic functions in Swift are implemented as functions taking
> an additional parameter -- witness table, which contains implementation of
> all functions in the protocol.
> For example, the following:
>
> func f<T: P>(a: T, b: T)
>
> Turns into something like:
>
> func f(a: Any, b: Any, witnessTableForT: UnsafePointer<_WitnessTable>)
>
> Returning to my cited phrase, Swift specializes generic types (with
> duplicated metadata; think C++ class specialization), but implements
> generic functions without using specialization. One can say that a generic
> type in Swift becomes a collection of distinct types, but a generic
> function remains a single function. So we can't view them equally, and
> current situation, where we can "explicitly specialize" types, but not
> functions, is not an inconsistency.
>
> I used word "semantically", because compiler can apply *specialization
> optimization* to a function, which is usually followed by inlining. But
> this optimization is guaranteed not to break the above assumptions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161202/bd66c23b/attachment.html>


More information about the swift-evolution mailing list