> On May 12, 2016, at 11:21 AM, John McCall via swift-dev <swift-dev@swift.org> > wrote: > > Well, we can say "A program has undefined behavior if it does X or Y", or we > can say "A program which does X or Y lacks type safety". In all cases we are > referring to a concept defined elsewhere. If we say "undefined behavior", we > are using an easily-googled term whose popular discussions will quickly > inform the reader of the consequences of the violation. If we say "type > safety", we are using a term with that's popularly used in very vague, > hand-wavey ways and whose consequences aren't usually discussed outside of > formal contexts. If we say "memory safety", we're using a term that doesn't > even have that precedent. So we can use the latter two terms if we want, but > that just means we need to have a standard place where we define them and > describe the consequences of violating them, probably with at least a > footnote saying "this is analogous to the undefined behavior rules of C and > C++". > > John. >
IMHO “lacks type safety” implies you might get nonsense values but that’s it. I assume that’s the average lay-programmer’s interpretation of the concept too. I would wager that the vast majority of developers don’t understand undefined behavior or don’t fully understand its consequences. The whole “the program is free to format your hard drive or print SAUSAGE, beep, and exit” discussion almost never fails to surprise anyone I’ve had it with. Doesn’t the C standard still say that the entire program itself is undefined, not just up until the point of executing undefined behavior? I bet if you took a poll you’d be lucky to get 5% of responders who knew that. IMHO the standard library docs around Unmanaged, UnsafePointer, and OpaquePointer would benefit greatly with much more in-depth explanations of the concepts and consequences of failing to adhere to the rules. In theory developers should read the docs, check google, etc. In reality a huge number of them will possibly bother to check the headers or run with the QuickHelp pane open and that’s the extent of the exposure they’ll have. One could say they shouldn’t be messing with such unsafe features if that’s the case but that won’t stop someone from writing the next Heartbleed by abusing UnsafeMutablePointer (or perhaps less dramatically just create exploitable security holes in a framework used by a bunch of apps). Again just my opinion but I’d love to see Swift set a standard of over-explaining anytime potentially unsafe operations are involved. I think it would promote a culture of careful consideration around the use of unsafe operations. Russ
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
