I actually don’t know if that’s as clear of a signal of intent (not that anything is foolproof). I see many examples where people declare conformances on the type and then implement their requirements elsewhere.
Do you propose for the silencing fixit to move the conformance to an empty extension when the overload and synthesized conformance are both declared directly on the type?
Generally, a fix-it offers to address the inferred underlying problem. It is usually a manual operation to silence the warning without fixing the inferred problem in situations where there’s a false positive. I don’t think a “silencing fix-it” is in general a wise idea and I don’t think it’s usually offered in Swift (the “it” to be fixed is the code, not the presence of the warning).
We now have near-miss diagnostics for protocol conformances—i.e., warnings about a member resembling but not matching a protocol requirement in an extension stating conformance. The way to silence that warning is to separate the conformance from the member. I don’t think we offer a fix-it there; and if we did, it should offer to correct the typo, not to separate the member from the conformance.
I surmise here that in the vast majority of cases the implementation will be unwanted (because it doesn’t do what the author thought it would) and the conformance is wanted. Hence the warning to begin with. We shouldn’t just delete code that can’t be trivially recovered as part of a fix-it though.
A workable fix-it might propose that the user delete any generic constraints so that the custom logic is used under all circumstances. (That is, if an automated fix-it is desired at all.)
But I would not offer a “fix-it” that silences the warning without actually fixing any potential problems in the code.
We often do offer silencing fix-its. If we can also offer a fix-it to correct the assumed mistake, we put that one first, of course. But if correcting the mistake requires a deeper understanding of intent then the compiler has, or is simply too difficult to implement at the textual level fix-its operate at, the silencing fix-it may be the only one we offer.
Thanks for the advice. The not so great part of near-miss conformance diagnostics is that nothing cues for what to do when you actually need to silence the warning. The fallback fixit suggests to make the method private; unless you have the experience this can easily come across as the only possible way to silence the warning. I am taking this back – given the requirement should be optional and the diagnostic itself triggers on things like argument name typos, this is just too iffy.
Right now there are a couple of existing circularity issues around protocol type aliases getting in the way. I will look into how to best implement the warning once I sort those out.
1 Like