<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I think this is a good change with an admirable premise: that unsafety should not necessarily be a binary proposition - either avoid it completely, or use it and silently run into all sorts of potential UB pitfalls. (This is compounded by the problem that exactly what UB is is poorly understood - for example, how many engineers working with C assume that signed integer overflow must wrap? What happens when unsigned integers overflow?)</div><div class=""><br class=""></div><div class="">While it is not possible (or desirable) to protect developers from making any possible mistake, it would be great if Swift eventually reached a state where there were only a few straightforward ways to use the APIs to produce UB, and those few ways could be learned by developers wishing to work with the unsafe APIs.</div><div class=""><br class=""></div><div class="">Someone with more experience working with C APIs or raw memory will have to comment on the ergonomics of the change, and whether or not it introduces any unforeseen problems therein.</div><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><div class="">P.S. On an unrelated note, it might be better to host a proposal in a Gist or elsewhere; the first time I sent this message the mailing list software caused it to bounce. I suspect the same might have happened to other people's responses.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 12:08 AM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello Swift evolution,</div><div class=""><br class=""></div><div class="">I'm sending this proposal out again for another round of RFC. The first round did not get much specific feedback, and nothing has fundamentally changed. In this updated version I beefed up the explanation a bit and clarified the language.</div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On May 9, 2016, at 11:14 AM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">Hello Swift evolution,</div><div class=""><br class=""></div><div class="">I sent this to swift-dev last week. Sorry to post on two lists!</div><div class=""><br class=""></div><div class="">Swift does a great job of protecting against undefined behavior--as long as you avoid "unsafe" APIs, that is. However, unsafe APIs are important for giving developers control over implementation details and performance. Naturally, the contract between unsafe APIs and the optimizer is crucial. When a developer uses an unsafe API, the rules governing safe, well-defined behavior must be clear. On the opposite end, the optimizer must know which assumptions it can make based on those rules. Simply saying that anything goes because "unsafe" is in the name is not helpful to this effort.</div><div class=""><br class=""></div><div class="">For a long time, I've wanted these rules nailed down. We have more users taking advantage of advanced features, and more optimizations that take advantage of assumptions guided by the type system. This seems like a particularly good time to resolve UnsafePointer semantics, considering the type system and UnsafePointer work that's been going on recently. Strict aliasing is something I would like addressed. If we do nothing here, then we will end up by default inheriting C/C++ semantics, as with any language that relies on a C/C++ backend. In other words, developers will be forced to write code with technically undefined behavior and rely on the compiler to be smart enough to recognize and recover from common patterns. Or we can take advantage of this opportunity and instead adopt a sound memory model with respect to aliasing.</div><div class=""><br class=""></div><div class="">This proposal is only an RFC at this point. I'm sending it out now to allow for plenty of time for discussion (or advance warning). Keep in mind that it could change considerably before it goes up for review.</div></div><div class=""><br class=""></div><div class="">-Andy</div></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>