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

[Gwendal Roué]

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

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!

Gwendal

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