> > 1. a+b is also is a dynamic method call in this example. How would you > explain to a programmer that they have to use single quotes around some > expressions but not others?
Operators already have dynamic behaviour with operator overloads. Operators like + fail without warning as well, this is precedent in the language. Swift has decided to make the default for operators simple while safer usage comes at the cost of more explicit operators: &+ and the likes > 2. Having this kind of special syntax would feel very arbitrary to the > programmer, and hard to look up. Fixits would of course be able to help here, > but if the compiler already knows what you should write, why does it require > it? Which brings me to my third point: For the reasons I mention above. Yes it’s arbitrary but it conveys meaning just like ! conveys meaning. "let x: Int” vs “let x: Int!” have vastly different behaviours > 3. This feels like punishment, like Python making a special syntax for static > language bridges where they have to use the phrase > "static_typing_is_for_losers" in front of every method call. Getting Python into the language is a goal for this proposal not the proposal. The actual proposal has far reaching changes. Theres a reason why we don’t explicitly let any string subscripts of an object be accepted as members on objects like JavaScript. I have nothing against Python and think it would be fine without any markings as I mention in the end of my last email. This is because it has a precedent of being dynamic and anyone choosing to use it knowns exactly what they’re in for. Choosing to use Python in Swift would be a calculated decision by someone with prior experience in Python. Anyone coming into a Swift codebase with Python should be made aware of this before accepting the task (for example in a job description, requires Swift and Python knowledge). However for things that are not obvious that they should be dynamic should tell the reader that what I’m doing here is different from just getting members from my well defined object. I’m accessing dynamic information which by its very nature is dynamic and might exist in some situations or might change over time. I need this information to be sure that when I’m debugging that the pitfalls of dynamic members are made aware to me. You might say that's what protocol conformance tells me. But right now I’m debugging and I don’t know what's going to trigger my aha moment. Constant reminders of here lie dragons of dynamic code certainly helps. > > It's not like dynamic method calls will appear in your code if you don't use > these kind of bridges, and even if you do, it will only be when you call > methods on that bridge's types. When you call a method on an object, you > already have to know what that object does, or you will be in trouble. 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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
