[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Mathew Huusko V]

I tuned out the initial discussions of this proposal because there seemed
to be a lot of noise centered around implementation/maintainability. 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.

Cleanliness is a double edged sword, which Swift already suffers at the
hand of. Type inference and overloading are fantastic. Literal convertibles
are magic. Omitting "redundant" types/descriptors from signatures is so
right. But they (especially when combined) lead to a lot of Swift code
ranging from unclear to meaningless at a glance, with a couple
option-clicks per line necessary to extract exactly what's going on from
the all knowing compiler. This is a hindrance in Xcode, and not possible if
you've only got the text (like on GitHub).
    But whereas these features only really effect code comprehension, the
proposed syntactic conversion effects code comprehension and writing safe
code. Usually in Swift you have to opt in at the call site to unchecked
behaviour, but with these changes, working in a mixed pure Swift/Pythonic
Swift environment, if you don't pay a good deal of attention to each object
you're writing calls on (whether it conforms to the new protocol), you can
write totally unchecked code by accident. Not to say the code comprehension
itself isn't a problem — with type inferred/descriptor-cleaned code it's
evident the information isn't there, so if something isn't clear there's an
impetus to option-click/check it. With this dynamic-posing-as-checked code,
the truth and the evidence is disguised.

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?

Thanks,
Mathew

On Mon, Nov 27, 2017 at 6:04 AM, Chris Lattner via swift-evolution <
swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/8d515d6a/attachment.html>