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

[Letanyan Arumugam]

Regards

Letanyan Arumugam



> On 07 Dec 2017, at 17:34, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
>> 
>> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution <swift-evolution at swift.org <mailto: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).

One might call that a rhetorical question :) Which is probably not appropriate here so I apologies for that.

> 
> 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).
> 
I’m not sure anyone here ever said they wouldn’t use it. There’s just a concern about how much it would be used.


> 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!
> 

I’m not taking sides on which is better (each to their own use cases). I am talking about the proposals current design. The current design says that dynamic and static calls are on equal footing. This implies to the programmer that either way of doing things is correct. A programmer from a dynamic environment is usually going to choose the dynamic way because it’s more powerful and easier to use. I just merely want the design to have a way of showing the programmer that they should think twice about using it in an implicitly failing way. Whether that be renaming the protocol to something like UnsafeDynamicMemberLookup or something else along the lines of what Swift currently does.



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