> On Nov 28, 2017, at 5:58 PM, Greg Parker via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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. > > 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. > > "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.
Right. > 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. 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". -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
