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

[Vincent Esche]

On Tue, Dec 5, 2017 at 12:48 PM, Benjamin G via swift-evolution <
swift-evolution at swift.org> wrote:
>
>
> For what i'm concerned, let's be very clear : i do not consider my
> personal opinion to matter AT ALL compared to what people like you, who
> code compilers for a living, think. And i feel even more embarrassed
> participating in that conversation since it's about a language you
> invented. I've only done it because people in the core team said it would
> be interesting.
> Now, the only area where I may have more experience than people like you,
> is working with the average programmer, in the industry. And my personal
> experience shows that what a language doesn't enable is as important as
> what it enables (because every feature that can be abused will be,
> eventually and in ways nobody can expects).
>
> Regarding your proposal regarding the impact it could have on pure swift,
> i think it comes down to letting the developer masquerade dictionaries into
> proper structs or classes. I tried to recreate a dynamic BaseDynamicObject
> based on dictionaries and your new protocols, but it's pretty hard without
> the finished implementation (i will try to recompile swift using your pull
> request wheneve i got the time, if i feel people are sincerely interested).
> The "benevolent" purpose for doing that would be anything regarding
> mocking, proxying, mixins objects and their properties. There are various
> examples of those patterns in every dynamic languages.
>
> About C#, in which i did program a few years ago (but before dynamic was
> in the language), it already had powerful metaprogramming and introspection
> capabilities, as well as very convenient  generics and interfaces ( easier
> to work with than what swift offers today, but that was a long time ago so
> my memory may be wrong). So, in some way, the potential for abusing dynamic
> or "stringly typed" programming was a lot lower.
>

This is in essence what my concerns boil down to as well (as described in
my initial response to this thread).

If Swift had a rock-solid Generics system at this point and plenty of
support for Meta-Programming via hygienic example-based or procedural
macros and/or compiler plugins, then I'd be way less concerned about this
feature getting misused.

Alas while Swift's generics provide a nice basic foundation, they still
have big gaps in what can be expressed through them.
And i'm not talking about HKT or any such more advanced use of types). I'm
talking about the basic stuff. Generic abstractions over type conversion.
Generic abstractions over arithmetic operators. This kind of stuff. Stuff,
that ironically would be necessary for a generic yet idiomatic
implementation of Linear Algebra algorithms in Swift.

I would prefer to get these gaps filled up before providing an orthogonal
feature that can easily be misinterpreted as a solution to the deficits in
Swift's generics system by someone coming from a dynamic language and/or
doesn't fully understand the use of generics.

We'd in essence be providing what looks like a solution in a time where
thousands of people are looking for workarounds to the limited
expressiveness of Swift's type system. That's like handing out bottles of
Methanol for its use as a household item in a time of severe drought. What
could possibly go wrong?

It's also a completely different situation than what (from my
understanding) C# was in when they added `dynamic`.

---

Further, adding something like .dynamic would completely undermind the
> proposal.  You can already write:
> x.get(“foo”).get(“bar”)
> having to write:
> x.dynamic.foo.dynamic.bar
> has no point.


By the law of demeter you shouldn't be accessing `.foo.bar` on `x` in the
first place. This is optimizing for bad use.
I would instead consider this a form of syntactic salt. Intentionally
pushing people to refine their APIs.

As such you should only ever have a single `.dynamic` per object in a scope:

x.dynamic { x in

    x.foo
    x.fooBar

}


---

On a technical level I think that this is a well thought-out proposal.
And I wouldn't expect any less from you, Chris.

But I think that it's too early for it. The language simply isn't ready for
it.
And I think that we have more urgent topics at hand that need to get fixed.
Swift's generics are very limited. We hardly have any tooling.
Diagnostics are just shy of migrating from "utter garbage" to "getting
usable", by modern standards.
Integration with Xcode still to this day is an utter clusterfuck. With
errors pointing to the void, regularly.
I'd prefer the team to focus on these, solidifying the foundation and once
that's done
and the result have been proven to be sound by time I'd love to see Swift
get some more dynamism.

At this point in time it's like opening Pandora's box. Regardless of how
small and clean the implementation is.
I can understand that you prefer to focus on the technical discussion (with
Doug e.g.), but there is always a
non-technical side to the addition of a major and potentially disruptive
feature.
And the proposal as it is right now pretty much avoids addressing it
entirely.

Your section "Reducing Potential Abuse" only talks about technical abuse
mitigation.
For me the technical challenges are secondary. It's creating a culture
problem from my point of view.

- How do you plan to teach the proper use of this feature? How would the
documentation introduce it
and how would it ensure that people fully understand its purpose and what
it decidedly is _not_ for?
- How would the diagnostics (in particular in code mixing static and
dynamic Swift) look like?
- How would the debugging of dynamic APIs look like?
- …

Could you shine some light on where you see this going in the context of
educating about this feature?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171206/bae64805/attachment.html>