> On 04 Dec 2017, at 07:47, Joe DeCapo <snoogan...@gmail.com> wrote:
>> On Dec 3, 2017, at 11:35 PM, Letanyan Arumugam via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@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 

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. 
swift-evolution mailing list

Reply via email to