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

[Mathew Huusko V]

I'm sure the implementation is fine, and I'm not criticising the proposal's
intent/concept, least of all simply because it might be misused (because
everything can and is).

Instead, I firmly believe — not to say I necessarily *deserve* a contrary
explanation/argument if no one thinks this is a big deal, but just to be
clear.. — that it is clean but fundamentally misleading (and thus
potentially non-ergonomic) to transparently convert `Python.open(filename)`
to `Python.get(member: "open")(filename)`.
The former line reads as "this lines calls this Swift function the compiler
knows exists, as usual", and the latter reads as "this line looks for/tries
to call something that may exist" — two very/importantly different things,
and you will only be able to tell the difference by option-clicking the
call site.
When we want to deal with a value that may not exist at runtime (an
optional), there's extra syntax ('?') for that. It seems like the same
thing for a function/call that may not exist *might* be appropriate.
Equally happy to hear why not.

On Mon, Nov 27, 2017 at 6:30 PM, Chris Lattner <clattner at nondot.org> wrote:

> 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.
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/754376b4/attachment.html>