Protocol Requirement Error Missing

For some protocols, such as Equatable and Codable, the compiler will synthesize the implementation for you. If you need to customize the behavior of your equality, you can still implement the functions of the protocol to meet your needs.

How do I disable this? I would rather work with the compiler warnings and errors to ensure I implement the code correctly. In fact, I do not want the compiler to do any hidden implementations in the background beyond what is expected in the Swift documentation.

>> I do not want the compiler to do any hidden implementations in the background beyond what is expected in the Swift documentation

It's not any of those things. It's documented right out in the open (for the current version of Swift):

https://developer.apple.com/documentation/swift/equatable

When you add Hashable conformance to a custom type, then you're saying you want it to be Hashable, so it's hardly subverting your intentions for the compiler to make it Hashable (and, in the latest implementation, it does it in a really good way). Yes, if you're used to adding a conformance and expecting the compiler (via errors + fixits) to tell you what methods you need to implement, it feels a little odd that it often no longer happens for Equatable and Hashable. Yes, there might even be some cases where the synthesized implementation causes you to overlook providing the non-standard implementation you originally intended.

But the "win" of having this synthesized in most straightforward cases is so big — for all Swift developers — that I think there's no chance the behavior is going to be withdrawn or made optional.

Anyway, if you really think you have a case to make, it would be better to make it over at forums.swift.org, where it will be seen by the Swift team. Complaining here is a bit too far from ground zero.

I was not complaining. I was asking how to go about reverting to a known standard; one in which Swift is inherently type-safe. The tutorial which provided me a different resulting example, and which is now apparently obsolete, is the very one posted on iTunes and recorded only last fall at Stanford. I was expecting the compiler to provide errors and Xcode to provide fixits, as was demonstrated, to enforce comformance to protocol requirements. My post was simply asking why my efforts were not getting those same results, which I would have expected regardless, as the version without any automatic synthesis fell neatly within that type-safe paradigm I have come to enjoy. I am surprised to discover anyone has implemented "automatic synthesis"--I had not recognize the reference in the documentation until you referred me to it here--nor a way to change it, to either provide warnings, or to force errors for missing requirements. I definitely believe it opens the door to the type of coding errors I thought Swift was aimed at detering. Now that you have addressed my original question and provided me the answer I was missing, that this was a purposeful change in the Swift standard, I might do as you say, and bring my opinion to the Swift forum. In my mind, this is not a "win", but a regression back to those scary coding shortcuts existing in many languages that often cause more headaches than solutions.

It's a known pitfall that Swift tutorials out there on the web become obsolete very quickly. For the purposes of following a tutorial, it's important that you (or anyone) should use the exact version of Swift (usually meaning the exact version of Xcode) that matches the tutorial. Any sites providing tutorials that fail to be clear about the required version are doing you a disservice.

Automatic synthesis doesn't have anything to do with type safety. Even before synthesis was added, conforming a type to Hashable also conformed it to Equatable. The synthesis itself has nothing to do with how the conforming type is type-checked.

So, what kind of coding errors are you saying that auto-synthesis makes you vulnerable to?

For the record, "complaining" wasn't a criticism of you. It just meant "raising your voice in protest". The point was the rest of the sentence — the people you want to hear your voice don't normally visit this forum.

Well, in the example I was following, the creation of an automatically Hashable and Equatable Struct led to a run error where the equatable values were incorrect. The struct was supposed to equate on only one of its values, and not on all of the values. So, later in the code, a match was not detected where it was supposed to be detected. That kind of runtime error could have been easily avoided had the compiler reminded me I had not yet implemented my required Equatable func. I can see a similarly flaw when a hashValue is automatically synthesized.

When I talk about that type-safe paradigm, I am speaking to more than actual type checking. The warnings when you forget to use self in a closure can help coders avoid a memory loop. The warnings when a variable is not mutated, or a constant is not used, have obvious benefits. These types of stricture contribute to better coding. The errors for when a protocol is missing required properties and methods felt similar. It's why I am surprised they added the automatic synthesis. It seems like a step in the wrong direction to me. It would make better sense to at least include a warning, or a way to allow or deny synthesis explicitly, so such potential problems not overlooked.

So, there is no way to disable synthesis? A compile switch or something?

Your point about unexpected compiler behavior has some validity, but isn't a hard argument to sustain? For example, before there was Equatable synthesis, if you added a property to a struct — one that should affect equalness — there's nothing to remind you to update your custom == function. So, the whole thing becomes a back-and-forth about tradeoffs. I don't recall following the discussion about automatic synthesis over at forums.swift.org, but I've no doubt that the tradeoffs were discussed, and ultimately someone had to make a judgement call.

I'm not aware of any compiler options to disable this behavior. In general, Swift avoids providing compilation switches for language features.

Again, I encourage you to have your say over at forums.swift.org. Even if the ship has sailed on this point, you may influence subsequent similar decisions.