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

[Letanyan Arumugam]

> On 07 Dec 2017, at 17:46, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <letanyan.a at gmail.com <mailto:letanyan.a at gmail.com>> wrote:
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types are going to be massive (infinite technically). I assume many people are going to be writing a lot of code would these types and calling many methods and properties which would all essentially have a fatalError. Would you consider it good code if the majority of all your types had methods defined with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library methods check preconditions and trap on failure. That is how I write my code as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is something that goes out with production code while precondition is used for debugging. I think you would agree a shipped program that has many states of being unrecoverable is not a good design?
> 
> Precondition checks are active in release code. When a program encounters conditions that have no obvious recovery, trapping immediately is the only safe option; this is what Swift means by “safety” and the practice is encouraged.
> 

Apologies I was looking at the -Ounchecked flag reference.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/af54b320/attachment.html>