> 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). 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. > 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? -- Brent Royal-Gordon Architechies _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
