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

[肇鑫]

>
> The compiler knows that read() is being called on Baz<UInt>, so it could
> know that read() must return a UInt,


I think there are two steps here.

   1. compiler choose func read<T>() -> T base on the return type of func
   read() -> T
   2. compiler replace T with UInt

In your mind, the steps are reversed.

In fact, there is no overload here.

Code:

let thisDoesntWork = Baz<UInt>().myBar.read() // error: ambiguous use of
'read()'

Compiler doesn't know which function to choose as there is no return type
to derive from。

z
​haoxin​

On Fri, Jan 15, 2016 at 2:13 AM, Ryan Conway via swift-users <
swift-users at swift.org> wrote:

> 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
>>>
>>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


-- 

Owen Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160115/0e28ecec/attachment.html>