<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 4, 2017 at 1:45 PM, Nick Keets via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><span class="gmail-"><br><div class="gmail_quote">On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><div>Some people are big fans of dynamic behavior and this feature will make it much easier to write code in that style. They will do it without feeling malicious or considering this to be abusive, considering it to be a legitimate style preference. I wouldn’t be surprised to see people develop mixins that implement the subscript using mirror and other future reflection capabilities without considering that to be abusive (I would almost be surprised if this <i>didn’t</i> happen). Requiring some kind of usage site annotation would both discourage this and help anyone who walks into a such a code base to understand what is going on.</div></div></div></blockquote><div><br></div><div> </div></div></span><div class="gmail_extra">I really don't understand this fear of metamorphosis. People could also be using emoji for all their variables. So what? Let them do it!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Are you afraid that this kind of code will eventually become idomatic Swift and soon all the good 3rd party libraries will be written like this? If yes, that means that Swift has failed as a language, people really wanted another Javascript. If not, what's the harm? Maybe eventually people doing this will realize that "proper" Swift is better. Or not.</div></div></div></blockquote><br></div><div class="gmail_quote">Unless DynamicLookup is used to circumvent every compiler warning or errors thrown at you by the language because your design is unsound. Something like "ho, yeah swift generics and protocols aren't really working fine together for your case, but just make everything DynamicLookupable and you'll be all set". Or "This JSON document has a really complex schema. Let's just not specify anything, and call the fields like this, you won't even feel any difference anyway".<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The more i think about this proposal, the less i actually understand its purpose. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">1_ From what i understood from this discussion (please correct me if i'm wrong) python code is already callable from swift right now, without any modification to the compiler, but then the syntax to *some* very generic python function would just not be really pretty. If it's just library calls, we could just wrap those calls into pretty functions for our needs, but then : <br></div><div class="gmail_quote">2_ There are some python developers that hate python and would like to jump ship and start developing in Swift because of ? ( here, i suppose things like code completion, or anything "compile time", because that's the only part where swift would have an edge against python regarding data libs, since python is just glue code around high performance C). And we want to make it pretty for them. <br></div><div class="gmail_quote"><div>3_ So let's make swift more dynamic and disable compile-time checks for what those guys are going to use ??</div><div><br></div><div>Which means we're adding dynamic , runtime checks to a compile-time checked language, to help people moving out of a dynamic language... There's something in that logic that i fail to understand. Once again, if i can only bring one useful personal experience, people in my field (regular server-side development) are moving away from python to go. And believe me the reason has very little to do with syntax or power in the type system and more with good concurrency, fantastic compile time, fantastic stdlib, and "good enough" syntax for the general cases.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">Right now there are a lot of people writting Swift in an Objective-C style. e.g. using classes when they should have used structs, using inheritance when they should have used protocols. Should we add some language feature to stop them?</div></div></div></blockquote><div><br></div><div><br></div><br><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>