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

[Magnus Ahltorp]

> 28 Nov. 2017 00:57 Mathew Huusko V <mhuusko5 at gmail.com> 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.
> 
> Perhaps I was not totally clear while mixing and matching my observations/interpretations of safety and fallibility in compile vs. runtime and readability vs. writability in my initial email, but I believe the spirit of my concern was clear: there is obviously a difference between dynamic and static languages/calls, and having the syntax the same is misleading in a language centered around static safety, perhaps to a degree where it is ergonomically counter productive.

You can never expect everything that is type safe to be non-failing. Also, the only two alternatives I feel would be acceptable to you is to either require that all return values from dynamic languages are optionals or to require a fully name and type specified layer between the dynamic language and Swift.

The first one would be non-ergonomic, since unwrapping would have to be done for every call and member access, maybe with the exception of direct use of implicitly unwrapped ones. This would likely be rejected by most users, since the need to check the existence of a member every time will seem unnecessary to them.

The second one will either place the burden of writing that layer on the API provider (which likely doesn't care about Swift) or the user of the API (which likely just wants to use the API without spending the time studying the API in that amount of detail and then writing the required code/rules).

Neither of these seem like acceptable alternatives to me.

Also, if the bridge author wants to return optionals all the time, that is possible, right?

/Magnus