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

[Xiaodi Wu]

On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <letanyan.a at gmail.com> wrote:

>
>
> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
> 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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/bb212cdd/attachment.html>