You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
swift-ci opened this issue
Mar 25, 2016
· 3 comments
Labels
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler itselffeatureA feature request or implementation
This is a general problem with naming collisions between protocols. We could provide an attribute to let you satisfy a requirement with a different name, e.g.:
classC: A, B {
@implements(A.T)
typealiasAT = String@implements(B.T)
typealiasBT = IntvaraT = String()
varbT = Int()
}
Thanks for your feedback. Actually, it's very similar to what I had in mind.
In the case that I described, it should also be possible for the user to omit
@implements(A.T)
typealiasAT = String@implements(B.T)
typealiasBT = Int
The compiler, using type inferencing, would simply sugar it in. In fact, I'm hoping the user probably will only need to use the new attribute you've proposed in rare cases.
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler itselffeatureA feature request or implementation
Additional Detail from JIRA
md5: 0c2607d11e5f61e44888e564de443735
Issue Description:
When an entity adopts from two protocols that share an associatedType, surprising errors result from namespacing issues.
Type C does not conform to protocol 'B'.
Compiles without error.
Type C does not conform to protocol 'A'.
I would offer that I consider this a low priority or trivial issue, but undesirable behavior nonetheless.
The text was updated successfully, but these errors were encountered: