> On 07 Dec 2017, at 17:46, Xiaodi Wu <[email protected]> wrote:
>
> On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>> On 07 Dec 2017, at 17:02, Xiaodi Wu <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
