> On 07 Dec 2017, at 18:21, Joe DeCapo <snoogan...@gmail.com> wrote:
>
>
>> On Dec 7, 2017, at 10:12 AM, Letanyan Arumugam via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
