[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner]

> On Nov 28, 2017, at 5:58 PM, Greg Parker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/ba669d64/attachment.html>