> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution 
> <swift-evolution@swift.org> a écrit :
>> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> <swift-evolution@swift.org <mailto: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?

When a question is framed so that there is only one possible answer, the 
question is flawed.

The question is not whether one likes dynamism or not (the answer is pretty 
obvious for many people here, and we don't learn much).

It isn't if one would use the discussed features if the proposals were accepted 
(many here would swear they wouldn't, even if many of them will lick those 
dynamic features like candy, whenever appropriate, as every sane person would).

Currently, it's a static vs. dynamic debate. But we should talk about a precise 
proposal, and a good one after that, which comes with plenty of information, 
and even playgrounds to look at!


swift-evolution mailing list

Reply via email to