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

[Letanyan Arumugam]

> On 07 Dec 2017, at 18:21, Joe DeCapo <snoogansbc at gmail.com> wrote:
> 
> 
>> On Dec 7, 2017, at 10:12 AM, Letanyan Arumugam via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> My original argument about failing for no discernible reason still stands. precondition is a thought out check for a failing state. member lookup failures are going to be because things don’t exist for which you presumably expected to exist.
> 
> Is it necessarily true that things will have to fail "for no discernible reason"? It's up to the implementers of the protocol for how they want to handle the failure case (trap/return option/throw error/etc.). But I imagine it could be possible to add a generic debug error message/warning message about lookup failing for invocations of this kind, which would give a pretty clear hint about what went wrong and why. Would that be enough to address your concerns about silent failures?


I’m aware that the implementation and design is fully type safe and does not deviate from current Swift behaviour. The thing is that some people will not want to not deal with errors at compile time because they’re used to dealing with them at runtime. 

I think warning and error messages would be too much. I’m not concerned about things being implemented in this way just as long as it’s appropriate. I would think all language layers like Python should have trapping lookups and calls.

However I wouldn’t mind a way of making a dynamic type return an optional when it doesn't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/70e86890/attachment.html>