[swift-users] How do generics interact with overloaded methods?

Wallacy wallacyf at gmail.com
Fri Jan 15 10:35:42 CST 2016


Talk: https://developer.apple.com/videos/play/wwdc2015-409/

There is a part called: How Generics Work

There is another talk with other details, but cannot remember which.

And also is a doc:

May you can see: Generics is more about protocols than "type substitution".

The point is: Unconstrained T, can be anything, so when compiler try to
compile this:

func read() -> T {
        return self.myBar.read()

self.myBar.read() can only point to generic version. The overload will be
resolved once.

The compiler will not generate another version of this read() -> T for
every single call of Baz<T>.

Usually, unconstrained T and "Any" is the same thing. Generics is more
about "which overload Im will call at this point".

Generic specialization is a optimization phase.

Em qui, 14 de jan de 2016 às 16:13, Ryan Conway <theconmethod at gmail.com>

> Thank you for your responses. I'm grateful for having been given several
> different perspectives, especially in such a short time, and have some
> ideas for things to try this weekend.
> If I'm understanding correctly, the salient point is that Swift will
> resolve a call to an overloaded function to exactly one implementation of
> that overloaded function, even if for all types of a generic class' generic
> function.
> I'd like to understand Swift's design philosophy better. Why were things
> implemented this way? For example, in the following line of code:
> let thisDoesntWork = Baz<UInt>().read()
> The compiler knows that read() is being called on Baz<UInt>, so it could
> know that read() must return a UInt, so it could know that it can safely
> use the Bar.read() that returns a UInt. From what I'm hearing, this is what
> C++ would use, but not Swift, and I imagine there is a good reason for it.
> Wallacy, if you're able to provide a link to this WWDC talk I would
> greatly appreciate it.
> Ryan
> On Thu, Jan 14, 2016 at 6:07 AM, Wallacy <wallacyf at gmail.com> wrote:
>> Generics are compile time feature, but like said, not like c++ templates.
>> Unconstrained generic T will be like Any. " return self.myBar.read()" can
>> only be translated to a "function pointer" to the generic version, because
>> is the only information available at compile time.
>> Has a talk on wwdc explaining this.
>> Swift can do generic specialization, but only when information enough to
>> do this. Usually constrained generic is the way to go.
>> Em qui, 14 de jan de 2016 às 05:05, Ryan Conway via swift-users <
>> swift-users at swift.org> escreveu:
>>> Hey swift-users,
>>> I'm teaching myself Swift, coming from a mostly C and Python background,
>>> and would like to understand generics more deeply. Right now, I'm seeing
>>> generic data types invoke overloaded methods in ways I do not understand,
>>> and am seeking clarification why.
>>> In an effort to model a data structure whose data can be represented as
>>> multiple data types simultaneously, I've made this class. Here its
>>> implementation is mocked using constants.
>>> class Bar {
>>>     func read() -> Int {
>>>         return -1
>>>     }
>>>     func read() -> UInt {
>>>         return 1
>>>     }
>>>     func read<T>() -> T {
>>>         print("Unsupported data type requested")
>>>         exit(1)
>>>     }
>>> }
>>> Objects of that class return the requested type as expected when used
>>> like so:
>>> let thisWorks: Int = Bar().read() // returns -1
>>> let thisAlsoWorks: UInt = Bar().read() // returns 1
>>> However, when I introduce generics on top of that class, the expected
>>> method (the "most precise" method) is not called. For example, given this
>>> other class:
>>> class Baz<T> {
>>>     let myBar = Bar()
>>>     func read() -> T {
>>>         return self.myBar.read()
>>>     }
>>> }
>>> Both of these invocations call the generic read<T>() -> T method rather
>>> than the read() -> UInt method:
>>> let thisDoesntWork = Baz<UInt>().read()
>>> let thisDoesntWorkEither: UInt = Baz<UInt>().read()
>>> Am I using generics wrong here? Is there some other language feature I
>>> should be using to capture this data? Any pointers would be greatly
>>> appreciated.
>>> Thank you,
>>> Ryan
>>> _______________________________________________
>>> 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/20160115/a7db3b16/attachment.html>

More information about the swift-users mailing list