<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 28, 2017, at 5:58 PM, Greg Parker 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 8:57 AM, Mathew Huusko V 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=""><div dir="ltr" class="">You're saying that there is universally no inherent difference, and that all calls "determine if you have called it" correctly, but then picked one of only a handful of cases in current practice where that is actually true. Yes "+" (/other math operators) and array access are unsafe, but most other things in Swift are safe by default, and you have to opt into un-safety (e.g. forcing or checking an optional or throwing call) — this is a main tenant of the language.</div></div></blockquote><br class=""></div><div class="">FYI this is not the definition of "safe" that Swift uses. Deliberately halting the process in response to an error counts as "safe". This is what Swift's arithmetic overflow and out of bounds array access do. </div><br class=""><div class="">"Unsafe" is when incorrect code both does something wrong and also doesn't halt the process immediately. For example, using something like UnsafeMutablePointer to perform an unsafe memory access that is incorrect might read or write random memory and might do so without crashing.</div></div></div></blockquote><div><br class=""></div>Right.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Swift often prefer throws or optional returns instead of runtime checks that halt the process, but as you noted it does not always do so. I don't know if we have a good phrase analogous to "safe"/"unsafe" for the presence/absence of a runtime check that can halt the process.</div></div></div></blockquote><br class=""></div><div>Note that this proposal is safe by both definitions, because (as is shown in the proposal) an implementation of the protocol can implement the dynamic member as returning optional. This provides a 100% safe interface to the client that doesn’t not "halt the process".</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>