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

[Jean-Daniel]

> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
> 
>> On 07 Dec 2017, at 22:26, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>> 
>>> 
>>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam <letanyan.a at gmail.com <mailto:letanyan.a at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171208/8076b97e/attachment.html>