<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Felix, I understand what you're saying, but I still don't see how it shapes this discussion. There are many things you can't do at that level of system programming in pure swift at the moment, and there are better ways to solve those problems later than to make UnsafePointer bear the burden for an extremely narrow use case.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Swift had no notion of volatile pointers for example.<br><br><div>-Chris</div></div><div><br>On Mar 17, 2016, at 10:09 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Well, they can also choose to not conform, or someone could use something lower-level than C to put something useful at address 0. I don't have any recent example, but for instance, in real mode, x86 has its interrupt descriptor table starting at 0.<div class=""><br class=""></div><div class="">It's true that it's a net win if you do app development, and it's probably a net win in most other cases too, but I just think that it's a little scary to make it 100% impossible to access anything at address 0. It's a tiny thing but it would make Swift the wrong tool if you ever needed to do it for whatever whacky reason that shouldn't exist in theory but ends up there in practice.</div><div class=""><br class=""></div><div class="">(My objection entirely goes away if `ptr!.pointee` tries to dereference the null address, but I think that this requires more compiler magic.)</div><div class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 18 mars 2016 à 00:32:38, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">On Mar 17, 2016, at 8:21 PM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><blockquote type="cite" class="">Fortunately, when a type has a single invalid value for which no operations are valid, Swift already has a solution: Optionals.<br class=""></blockquote><div class=""><br class=""></div><div class="">To me, this makes it sound like dereferencing an unsafe pointer is unsafe only if the pointer is nil. (Nil does have the merit that it's generally one of the only addresses known to be invalid, though.)</div><div class=""><br class="webkit-block-placeholder"></div><div class="">One thing that I would worry about, though, is the case where dereferencing address 0 is legal. My understanding is that Swift is aimed to be a systems language, and this case is relatively frequent on embedded devices.</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">This is definitely an important case to consider, but I don't think this is a problem for the proposal.</div><div class=""><br class=""></div><div class="">C compilers for these sorts of embedded systems have two choices: they can either reserve 1 byte for the null value (wasting a byte of physmem) or they can use a null value with a representation that is not equal to zero.</div><div class=""><br class=""></div><div class="">In either case, the null value (whatever it is) maps to the swift none case. Everything works out properly.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 17 mars 2016 à 21:59:49, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hey, everyone. If you're like me, you're sick of the fact that 'UnsafePointer<Int>' doesn't tell you whether or not the pointer can be nil. Why do we need to suffer this indignity when reference types—including function pointers!—can distinguish "present" from "absent" with the standard type 'Optional'? Well, good news: here's a proposal to make pointer nullability explicit. 'UnsafePointer<Int>?' can be null (nil), while 'UnsafePointer<Int>' cannot. Read on for details!<div class=""><br class=""></div><div class=""><a href="https://github.com/jrose-apple/swift-evolution/blob/optional-pointers/proposals/nnnn-optional-pointers.md" class="">https://github.com/jrose-apple/swift-evolution/blob/optional-pointers/proposals/nnnn-optional-pointers.md</a></div><div class=""><div class=""><br class=""></div><div class="">Bonus good news: I've implemented this locally and updated nearly all the tests already. Assuming this is accepting, the actual changes will go through review as a PR on GitHub, although it's mostly going to be one big mega-patch because the core change has a huge ripple effect.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></blockquote></body></html>