> Am 18.10.2017 um 22:31 schrieb Adam Kemp <adam_k...@apple.com>: > > >> On Oct 18, 2017, at 1:20 PM, David Sweeris <daveswee...@mac.com >> <mailto:daveswee...@mac.com>> wrote: >> >> How many bugs have been caused by floating point types violating the >> programmer's mental model of how numbers work? To me, their both in the same >> category... both involve specific types that claim to adhere to a certain >> behavior, and both don't in sometimes subtle ways. > > I think we have plenty of evidence that misunderstandings about floating > point lead to bugs. For example: > https://www.theinquirer.net/inquirer/news/1047844/floating-point-bugs-explode > <https://www.theinquirer.net/inquirer/news/1047844/floating-point-bugs-explode> > > It took me about 30 seconds to find a clear example for floating point, and > we all know there are many many more. > > Can anyone find even a single example of this function leading to a shipping > bug in the real world?
Well, it took me not much longer to find a clear example of a bug in a suggested usage of `elementsEqual` on Stackoverflow: "And, finally, if the two arrays of permissions are actually sets of permissions then you can use return Set(tokenPermissions).elementsEqual(Set(permissions)) " (https://stackoverflow.com/questions/33354709/swift-compare-set) Clearly the example will given random results depending on the order of `tokenPermissions` and `permissions` which is obviously *not* what the author had in mind. Now this is not production code (hopefully) but it demonstrates the problem. How will I know if the code behind a generic function taking a Sequence as argument will internally use `elementsEqual` so that I cannot use a Set as argument? -Thorsten
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
