I think this is a bad idea.

I’ve worked with APIs like this in Perl, Ruby, and Obj-C. Even in a dynamic 
language, IMO it’s almost always a mistake to use them. It makes code harder to 
reason about when reading and debugging. 

This seems especially true with Swift because you can no longer autocomplete or 
introspect these sort of things. (Not that Swift has that much introspection at 
the moment. Aside: how would these work, if at all, with `KeyPath`s?)

I personally don’t want to work with APIs like this. And while I can understand 
the appeal of easier interop—especially if you’ve come into a large library of 
Python code—IMO this would inevitably lead to other misuses of dynamic lookups 
in 1st- or popular 3rd-party libraries.

But apart from my general philosophical complaints, I have 2 specific 
criticisms of the proposal:

1. I don’t think this would actually be good for writing Python

The examples in the proposal are very shallow, highlighting single lookups. But 
what are the types of the returned values?

Since all the lookups resolve to a single type, it must either (1) require 
casting or (2) only use dynamic lookups.

If you’re casting, then the dynamic lookups serve no real purpose. Any serious 
development project would quickly add a typed interface on top of the dynamic 
one. It would be better to build this typing into the bridging instead of 
performing dynamic lookups.

If you’re only using dynamic lookups, then you’re no longer really writing 
Swift. Any real typing has gone out the window and you’re left writing a 
strange variant of Python. When you do need to get a value out, I’d imagine 
you’d need to cast.

I think the proposal should include a more complete example that demonstrates 
how meaningful interop code could be written.

2. The JavaScript example will be popular, but isn’t actually that useful

Swift already has `Codable`, which provides more automatic and more type-safe 
(in that it encourages all-or-nothing decoding) JSON decoding. On that basis 
alone, I don’t think it’d be useful.

But this also ignores the ugly reality of JSON: the difficulty isn’t in 
accessing fields. The real trouble comes when you try to map a real, evolved, 
flawed API into a well-typed, thought-out data model. (This criticism applies 
to `Coding` too. Mapping JSON to an `enum` gets ugly quick.)

Arguably, this proposal’s JSON interface would be better for throwaway 
scripting, but IMO that case isn’t worth optimizing for.


> On Nov 27, 2017, at 1:04 AM, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to