[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
clattner at nondot.org
Mon Nov 27 12:30:24 CST 2017
On Nov 27, 2017, at 6:37 AM, Mathew Huusko V <mhuusko5 at gmail.com> wrote:
> I tuned out the initial discussions of this proposal because there seemed to be a lot of noise centered around implementation/maintainability.
There was some noise, but as I believe the patch shows, it was misplaced.
> I'm curious if the actual premise of the syntactic/sugar conversion has been discussed/debated yet? i.e. making dynamic/stringly calls look like normal calls is very clean, but it's also very misleading (by definition; they're not normal/safe/checked calls) with a potential net reduction in ergonomics.
In fact, the calls are fully type safe and checked. The JSON example shows that.
I think what you’re getting at here is that there is opportunity to misuse this feature. It is certainly not something that every one should use commonly on their types: it’s a power feature that is extremely important for some narrow cases.
I’ll observe that this is exactly the sort of feature that Swift traditionally includes, and there are many examples of this: generalized operator overloading, the ability to syntax extend almost everything in the language (e.g. literals), user defined pattern matching in switches, etc.
> Anyway, there's my primary concern. Has this been addressed yet? Has any thought been given to requiring '?'/'!' on these calls (or some other symbol, but this would retain some cleanliness..) to opt into the inherent fallibility and distinguish them visually?
This feature isn’t unsafe at all, I’m not sure why that would be appropriate.
More information about the swift-evolution