>> This minor enhancement could most likely be obtained by just having a >> default ==, which is a project that I can get behind. > > Structs do not have a common ancestor, this is why swift uses existential > containers, in order to create polymorphic behavior for protocol types with > value type implementations. So implementing such a default == would bring > changes to swift either. But I didn’t bring this idea in the first place to > have some more convenience. I am sure (and literature as well as my > experience as a developer and project lead in many industrial projects proves > me right), that implementing equality is a major source of errors in software > development and I think that you underestimate this issue.
Please do point me to that literature that shows that developers frequently misimplement their own comparators. >> Also, what about C structures with character arrays? They get translated as >> tuples of CChar (if that's what they're still called now, didn't really keep >> track). The two are equal as soon as you hit a null terminator, but >> memberwise comparison doesn't know that. > > They can have its own standard implementation. There is a lot of translation > going on between Objective C <-> Swift as well as C <-> Swift (e.g., some > constants are automatically coerced into enums). No, they can't. There is no way to differentiate a char array that should be a null-terminated string from a char array that is actually a byte array at the C level. >>> Invisible behavior is everywhere: Automatic Reference Counting, Existential >>> Containers, Virtual Functions, … >>> >>> Swift is a high-level language, so it’s main appeal is invisible behavior, >>> but I would call it *rich semantics* or something like that. >> >> There is an actual demand for these. With ARC, I don't need to think about >> memory management (too much). Virtual functions let me implement OO design, >> which allows a ton of developers to leverage experience. With forced >> memberwise comparisons, I can trade easily debuggable problems for >> surprising behavior. > > With my proposal you wouldn’t make it harder to find these issues it makes it > easier. As I told before, you could have an instrumentation/error handling, > that (in debug mode) does both checks default and custom implementation (so > no short-circuit) and inform you about false-negatives automatically. This sounds like piling on more work for the sake of it. If we end up forcing a default equality check on everything, I hope that we can at least rely on it being there all the time, because otherwise that will also be a bug vector. >> Also keep in mind that most of these things are criticized to some degree. >> ARC is a common enough source of bugs that Apple has a relatively large >> investment into tools specially made to debug them. > > This is due to the tension between the goal „safety“ and „performance“. > Perhaps swift switches to garbage collection in the future. Or they decide to > use garbage collection on fast devices as well as ARC on slow devices. Who > knows. Swift won't switch to a GC in the foreseeable future. That discussion has already happened. The points brought forward are that you couldn't implement COW semantics because a GC doesn't keep a reference count around at all times; that ARC means that resources are deallocated deterministically; that a fast GC requires you to use up to 2-3x as much memory as you actually need. >> What? You want to force every equality check to start with a memberwise >> comparison of *everything*. > > I just proposed these two standard implementations executed before any custom > implementation (no recursion or anything alike): > > 1. a `memcmp` for value types (not recursing through referenced types or > anything) and > 2. a === check for reference types (just comparing one address) Exactly. >> Why can't you be content with a default implementation? People all over are >> saying "don't touch my code", there's a very easy way to not touch anyone's >> code, but it's like you really want to. > > As mentioned above AFAIK this would introduce a change to swift either, since > structs don’t have a common ancestor (in terms of „inheritance“) **and** this > would just be a convenience feature and not help to reduce really hard to > trace bugs. Here's one way this could be implemented: if you write `struct Foo: Equatable` without implementing a `func ==`, the compiler makes one for you. Done. Félix _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
