[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
Letanyan Arumugam
letanyan.a at gmail.com
Thu Dec 7 00:38:40 CST 2017
> Until, and if, the “resistance” presents some conceptual explanation of how this could cause harm (I’m not asking for anything concrete, just a logical series of events that causes a plausible problem in practice), my belief is that the Swift community will see this as unwarranted fear.
>
My fear is that a design pattern around dynamic members and calls arise that is used to bypass the perceived initial annoyance of Swifts type system from new developers that come over to Swift and are now starting to try and go native. They have no reason to think about their conforming types as something that might fail because they’re using it to model behaviour that they’re used to (good or bad). I don’t see why it’s so bad to remind people that these conformances should be failing and only in rare cases should you ever have a dynamic member lookup that is fine to ignore all failing lookups.
People coming from JavaScript could perceivably make dictionaries conform. And later JSON, database, file and basically all resource API’s would follow.
Why would all of this happen rather than people behaving the way current Swift community members behave?
Because I worry that by bringing in people from other languages that a new learning path is created. One where you start by learning your language interoperating with Swift. And then pick up other Swift features as you go along using your Python API for example. This would create a disparate Swift community.
More information about the swift-evolution
mailing list