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

[Letanyan Arumugam]

> On 04 Dec 2017, at 07:47, Joe DeCapo <snoogansbc at gmail.com> wrote:
> 
> 
>> On Dec 3, 2017, at 11:35 PM, Letanyan Arumugam via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I‘m not always the only one writing code (I could inherit a code base). I’ve used languages with only dynamic lookup before and knowing about something doesn’t always help especially when the documentation isn’t clear. Which is very possible in this case were libraries could be made by third parties.
> 
> I find it very hard to believe that Swift libraries are going to end up exposing this as a public api en masse. And if you inherit a code base where it's used internally, then it's fully within your power to wrap these dynamic calls in more strongly typed wrappers (you could even do this with third party libraries if necessary). You could just as easily inherit a code base where force unwrapping or IUOs are used irresponsibly, but this doesn't mean that these language features have no legitimate use. The solution is to refactor the code to use these idioms in the correct way.

The whole point of this proposal is to get more people into Swift. People who are from a very dynamic field so who’s to say what path new library vendors will go down. Getting people into Swift that only end up working in this dynamic world that is on par with our current world would serve no benefit to anyone.

Is it really as likely to inherit a code base that uses features that from day one Swift made clear was not the ideal way to go. Versus something that has nothing to differentiate it from “normal" Swift members.

What it means to be “normal" here could be a sticking point between us because I don’t think dynamic member lookups should be a thing that is common place to do and should be discouraged in some way not a lot but enough to make people think I should do this differently. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/83b6dd17/attachment.html>