Let's see what disasters were created by people abusing NSProxy, the ObjC moral equivalent of a dynamic member lookup type.
I'm not aware of anything. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> >>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution >>> <swift-evolution@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? > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
