[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
Matthew Johnson
matthew at anandabits.com
Mon Dec 4 10:15:34 CST 2017
> On Dec 4, 2017, at 6:45 AM, Nick Keets <nick.keets at gmail.com> wrote:
>
>
>
> On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
> 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 didn’t 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.
>
>
> 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!
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.
>
> 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.
>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/652e254e/attachment.html>
More information about the swift-evolution
mailing list