<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2017, at 6:45 AM, Nick Keets <<a href="mailto:nick.keets@gmail.com" class="">nick.keets@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><div class="">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 class="">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 class=""><br class=""></div><div class=""> </div></div><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></div></div></blockquote><div><br class=""></div><div>I don’t fear metamorphisis of the community in general. But there is no doubt that if we allow really dynamic code to be written in Swift some people will do it. I’m only asking for some guardrails that will encourage judicious use and help future maintainers work with the code they leave behind.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_extra"><br class=""></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></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_extra"><br class=""></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 class=""><br class=""></div></div></div>
</div></blockquote></div><div class=""><br class=""></div></body></html>