> 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

Reply via email to