> On 08 Dec 2017, at 18:14, Jean-Daniel <mail...@xenonium.com> wrote: > > > >> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> >> >>> On 07 Dec 2017, at 22:26, Chris Lattner <clatt...@nondot.org >>> <mailto:clatt...@nondot.org>> wrote: >>> >>>> >>>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam <letanya...@gmail.com >>>> <mailto:letanya...@gmail.com>> wrote: >>>> >>>>>>> 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? >>>>> >>>>> You are aware that Int traps on overflow and arrays trap on out of >>>>> bounds, right? >>>>> >>>> >>>> Were each of them not decided upon separately based on certain tradeoffs? >>>> Arrays for speed and Int overflow because having the addition operator >>>> return an optional would be too cumbersome? If these reasons were not so >>>> influential would they still be designed to trap? >>> >>> Yes, each of these decisions was carefully made. >>> >>> My point is that pretty much all code can fail at runtime, including >>> "something that goes out with production code”, because integers and arrays >>> are pervasive. I do not understand your claim that Swift APIs do not >>> generally fail at runtime. >>> >>> -Chris >> >> I’m just saying that we should try to avoid failure at runtime as much as we >> can whenever we can. We shouldn’t think it’s okay to add more reasons to >> fail at runtime because there’s already reasons to fail. We should be trying >> to reduce these. And even if this is impossible I think its always good to >> try. > > Failure at runtime is an intrinsic property of dynamic languages. This > proposal does not explicitly specify what append when a lookup fails and let > the bridge take care of this. I don’t think forcing a model would be the > right way to introduce dynamic features in the language. With an open > proposal, time will tell us what is the best way to bridge dynamic language > and unfitted bridges/libraries will just be forgotten. > > If having a dynamic bridge that trap on failure is an issue, just use one > that don’t. If dynamic code feel unsafe to you, you don’t use it and keep > using the safety offered by static code that will remain the main swift > paradigm. > > This proposal offer new capabilities that will probably be used only for very > specific jobs and that is not here to replace any existing swift paradigm. > As dynamic capabilities will only applies to specific classes, it is easy > enough to avoid them if you don’t like it. > And as the coding experience with such classes is going to be very poor (no > IDE assistance), I doubt people are going to use them to replace existing > swift patterns.
I never wanted to disallow this just discourage it. If your design warrants trapping behaviour then by all means you should have a way to do that.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
