> On May 16, 2017, at 4:41 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>
> I object to this characterization. People have tried to bring up such
> proposals, and it is invariably pointed out (usually by the same group of us)
> that these proposals don't discuss retroactive modeling, and then the thread
> dies. I can't remember a case where the proposal author actually incorporates
> this feedback into their proposal to handle retroactive modeling, or
> extension members of one protocol being used as the default implementation of
> another protocol.
>
> (This just means the problem space is more difficult than the proposer
> initially thought, and they're not going to take that on right now, which is
> fine. It's a learning experience; designing features that interact well with
> the whole language is not easy! We should probably add this to the "commonly
> proposed" list, though, so that we don't keep retreading that initial ground.)
There have been a number of suggestions made on the list; many involve the idea
of spelling retroactive conformances differently from non-retroactive ones
somehow, since the two look exactly the same but really aren’t doing the same
thing. Off the top of my head, I remember seeing suggestions for a
“retroactive” keyword, suggestions to include the method signatures without
bodies, various mapping syntaxes, etc. They don’t ever seem to get much
attention or traction.
The reason it’s frustrating to me is that I spent a lot of time last year
dealing with a refactor where I kept finding ‘stragglers’ at runtime,
post-refactor, a situation that wouldn’t have happened if I’d used classes and
inheritance. Also frustrating is the fact that it’s probably all off the table
now, since any change made at this point would certainly be source-breaking.
> On May 16, 2017, at 5:05 PM, Slava Pestov via swift-users
> <swift-users@swift.org> wrote:
>
> It’s not clear if such a keyword can be designed in a way that covers all
> cases. For example, consider a protocol extension that provides a default
> implementation for a requirement in a different protocol:
>
> protocol R {
> func f()
> }
>
> protocol P {}
>
> extension P {
> func f()
> }
>
> struct S : R, P {}
Huh, I didn’t know that that would work. I’d figured that since methods in
protocol extensions that aren’t in the protocol are strictly statically
dispatched, they wouldn’t participate in protocol method lookup.
Anyway, my ideal would probably be to broaden the concept a bit, since most of
the issue comes from the problem of knowing whether a protocol has a default
implementation or not. I’d prefer to require a keyword for *all* protocol
implementations:
protocol P {
func foo()
}
struct S: P {
implement func foo() { … } // doesn’t matter whether some extension
provides foo() or not
}
I think that would take care of the issue with the constrained extension. As
for retroactive, I’m pretty agnostic about how that’s handled, but I’ve seen:
protocol P {
func foo()
}
struct S {
func foo()
}
retroactive extension S: P {}
or:
extension S: P {
implement func foo() // with no body
}
I remember seeing some as well that actually allowed the struct’s method to be
named something other than “foo”, with a way to map “foo” to the actual method
name, but I can’t remember what syntax they used.
Charles
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
