> On Apr 25, 2016, at 3:30 PM, Jordan Rose <[email protected]> wrote:
>
>> I, personally, *really* don’t want yet another decorator keyword to indicate
>> the intent here, because I believe the user has already indicated intent by
>> stating conformance to the protocol P.
>
> I don't find this so compelling in a language with defaulted requirements.
If we didn’t have defaulted/optional requirements, this wouldn’t be an issue at
all.
> The place where we're seeing this problem the most is optional requirements
> in ObjC protocols (because of all the name changes), but it's really the same
> thing: it's hard to know if a particular member is intended to be part of a
> protocol or just something that happens to be similar.
>
>> It’s somewhat frustrating that these are *all* false positives. However,
>> they seem like “reasonable” false positives, in the sense that they’re close
>> enough to the requirement to be justifiable, and the suggested recovery
>> strategies look acceptable.
>
> I agree that these are all reasonable, but I don't think moving decls to
> extensions is a great answer. A lot of these close names might be close
> because they're helper functions,
You can explicitly give them less visibility than the conformance, which makes
it clear that they’re helper functions and disables the diagnostic.
> or (in the case of removeLast) because they implement API that's in the same
> family as the protocol.
It seems less onerous to move removeLast out to a different extension than it
is to splat some “implements” keyword on a bunch of declarations within an
extension whose purpose is to conform to a protocol P:
extension X : P {
// this is how X conforms to P
}
- Doug
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
