> The strongest your argument can be is “someone could use dynamic member > lookup in their API to produce an API with a footgun that hurts their users”. > I submit for your consideration that there are lots and lots of ways that > people can create poor APIs that hurt users. If someone uses this feature > inappropriately, then their API is crappy and you shouldn’t use it, just like > any other misuse of languages features.
I wish that attitude had more weight in the past, when things like forbidding inheritance or adding warnings for unused results were discussed… You can write stupid code in every real programming language, no matter how safe it claims to be, so you can’t argue against a feature just by pointing out that it can be misused. But I guess many people got the impression that Swift tries very hard to protect us: Things like let and struct help ensuring that things aren’t changed unexpectedly (and sometimes, you are forced to acknowledge that a parameter can be changed with „&“), Optionals help to eliminate nil-value problems, and a strong type system protects us from trying to call methods that aren’t there. Now we are talking about something that allows us to call methods that "aren’t there“, and although I wouldn’t call it a footgun, it’s definitely a huge change for the language. Even if it is no contradiction to the spirit of Swift (who could decide that if not you?), big changes tend to make people afraid — especially under the prospect that they might come before next year, and will stay forever. Yes, dynamic dispatch isn’t completely new to Swift, but you barely notice that Cocoa-types have special rules (unless you have to keep it in mind because you implement those rules in the compiler). The two proposals have benefits, but they have risks as well — and imho nobody can foresee their full impact now. Therefor, I’m convinced they should not be accepted under the normal terms: Look back at what renaming private to fileprivate did to Swift, and all the churn that could have been avoided with a trial phase.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
