[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
Chris Lattner
clattner at nondot.org
Mon Dec 4 10:35:16 CST 2017
> On Dec 4, 2017, at 1:42 AM, Vincent Esche via swift-evolution <swift-evolution at swift.org> wrote:
>
> I think the argument basically is "let's not add another footgun" (because the design of Swift , for example regarding null handling, is to have less footguns than other languages). The fact that there are footguns in swift isn't an argument for adding new ones.
>
> Couldn’t have said it better. This is what it all boils down to.
This is not a “footgun” in the traditional sense, because it does not affect someone who does not actively use it. It is not like UB in C.
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 also haven’t seen demonstration of an example where someone would non-maliciously [1] use it in an API, where it would cause harm, and what kind of harm that would be. You are creating a boogieman without taking any effort to explain the problem, so there is no way to do a cost benefit tradeoff analysis of whether the “benefit” of this feature is worth the “cost” that you claim exists.
I have said everything I intend to say about this topic.
-Chris
[1] Obviously if the API you are using was maliciously crafted, then you have tons of other problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/ee1cce0e/attachment.html>
More information about the swift-evolution
mailing list