The bug has been closed (not a bug).
I would appreciate pointers to any thorough documentation on this as I've
only found very brief and incomplete descriptions.
The information from Mathew et al in this discussion and the comments to
the bug-report are the best I've seen so far.
/Jens
On Sun, D
Sent from my iPad
> On Dec 10, 2017, at 4:32 PM, Jens Persson wrote:
>
> Oh btw Matthew, you wouldn't consider https://bugs.swift.org/browse/SR-6564 a
> bug then?
It does not look like a bug to me. The witness table only contains entries
based on type information available at the site of t
Sent from my iPad
> On Dec 10, 2017, at 4:30 PM, Jens Persson wrote:
>
> Thank you Matthew, I will try to digest and incorporate your explanation.
>
> I'm using a recent snapshot where
> struct X : P {
> func f() { print("this one is actually best") }
> }
> compiles fine without requiring
Oh btw Matthew, you wouldn't consider https://bugs.swift.org/browse/SR-6564
a bug then?
/Jens
On Sun, Dec 10, 2017 at 11:30 PM, Jens Persson via swift-users <
swift-users@swift.org> wrote:
> Thank you Matthew, I will try to digest and incorporate your explanation.
>
> I'm using a recent snapshot
Thank you Matthew, I will try to digest and incorporate your explanation.
I'm using a recent snapshot where
struct X : P {
func f() { print("this one is actually best") }
}
compiles fine without requiring that type alias.
/Jens
On Sun, Dec 10, 2017 at 10:52 PM, Matthew Johnson
wrote:
>
>
Sent from my iPad
> On Dec 10, 2017, at 3:41 PM, Jens Persson via swift-users
> wrote:
>
> I'm trying to get my head around the current behavior, but its very hard to
> understand and remember, and judging by the comments here and on my bug
> report (SR-6564), so does even people in the cor
I'm trying to get my head around the current behavior, but its very hard to
understand and remember, and judging by the comments here and on my bug
report (SR-6564), so does even people in the core team. It would be nice if
someone could present a complete set of rules (all the ones I've seen are
f
Consider this example:
protocol P {
associatedtype T
func f() // *
}
extension P {
func f() { print("T is unknown") }
}
extension P where T == Int {
func f() { print("T is Int") }
}
struct X : P {
func f() { print("this one is actually best") }
}
struct Y where U: P, U.T == I
Thanks Slava and Greg,
(
I'm aware that it prints "T is Int" from both calls if I remove func f()
from P itself, that's why I wrote "... unless * is commented out." in the
comment of the last line
Note that the "U.T == Int"-part of
struct Y where U: P, U.T == Int {
is key here. If it had been on
Evidence in favor of Slava's analysis: if you remove `func f()` from P itself,
leaving it in the extensions only, then you get "T is Int" from both calls.
> On Dec 8, 2017, at 12:12 PM, Slava Pestov via swift-users
> wrote:
>
> Hi Jens,
>
> I think the problem is that overload ranking always
Hi Jens,
I think the problem is that overload ranking always prefers a protocol
requirement to a protocol extension member, because usually you want the
dynamic dispatch through the requirement instead of calling the default
implementation. But it appears that this heuristic does not take into
11 matches
Mail list logo
