> On Nov 2, 2017, at 6:07 PM, Brent Royal-Gordon <br...@architechies.com> wrote: > >> On Oct 26, 2017, at 9:28 PM, Douglas Gregor via swift-dev >> <swift-dev@swift.org> wrote: >> >> Unlabeled single-value initializers are probably going to cause a number of >> false positives, because we can’t figure out which one we meant. > > When we're dealing with unlabeled initializers, can we use tighter rules? For > instance, perhaps it should only warn if the near miss has the same parameter > types, but different fallibility/throwing/etc., or if the parameter types are > closely related (e.g. the concrete parameter type is a subtype of the > required parameter type).
Yeah, I’ll suppress the diagnostic for an initializer with unlabeled parameters. Also for unlabeled subscripts, I think, because they have the same general issue where the base name is fixed by the language. This is implemented in the last commit of https://github.com/apple/swift/pull/12808 <https://github.com/apple/swift/pull/12808>. > Alternatively, perhaps we should have an annotation saying that a given > default implementation is expected to be used by concrete types and it's not > surprising for them to miss. Or we could disable near-miss warnings if a > refinement provides a default implementation for a base protocol requirement. I’m really trying to avoid growing the language with additional annotations. >> The filter method it’s warning on produces a Set, whereas the requirement >> expects an Array<Element>. This is a case of intentional overloading, but >> IMO it’s a reasonable thing to warn about. > > > Would it make sense to suppress the warning if the requirement has some fixed > return type, but the implementation you're warning about returns (some > specialization of) `Self`? Or do you think this is too specific to > `Collection` and these kinds of return-type overloads are rare in practice? I suspect that these are too specific to Collection - Doug
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
