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

[Vincent Esche]

On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner <clattner at nondot.org> wrote:

> On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution <
> swift-evolution at swift.org> wrote:
> > 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.
>
> This is all orthogonal to the proposal.  I’m certainly not opposed to the
> generics system getting better :-), […]
>

Exactly. That’s my whole point. How do we make sure these are understood to
be orthogonal? We’re talking about the average Joe here.
For someone used to stringly-typed dictionaries (Python e.g.) and
stringly-typed reflection (many message-passing/dynamic languages) it will
not be clear that 9/10 times dynamic stringly-typed member lookup is not
the right tool of choice for modeling type relations in a statically typed
language, which is exactly how these things are done in many scripting
languages.

> 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.
>
> I’m not disagreeing with your point about other things needing to be
> improved, but the only question is whether this proposal fits with the
> right long term direction for Swift.  It is not a prioritization question.
>

I’m not so much thinking of it as a prioritization issue (as you already
did the implementation and made clear from the beginning that you would do
the heavy lifting, not the core team), but more of a timing issue. It
absolutely is a timing issue from my point of view, for the very reasons
that I gave previously.

A frequent argument against any of the reasonable doubts expressed in this
thread is the notion that the community “would figure something out” and
“prevent any anti-patterns and misuses from gaining a foothold”.

I have doubts about this. There is plenty of evidence for the contrary:

- We don't have a strong unit testing culture in the swift community.
Hardly any Swift project on Github has proper unit test coverage. Most have
none at all.
  And I can’t blame them/us, as XCTest is more of a burden to use than a
help. XCTest on Linux is even worse if not border-line offensive to work
with.
- We don't have a strong culture of “avoid IUOs at all costs” either. I see
them all over the place when going through random Github projects.
  They are everywhere. I would give you numbers, but “!” is kinda hard to
search for (i.e. impossible) using Github’s source code search feature.
- There is still plenty of use of AnyObject and its cousins where for a
long time we have had better solutions.
- There is still incredible amounts of non-typesafe APIs (and I’m talking
about fresh 3rd-party stuff here, not legacy frameworks).
- …

> At this point in time it's like opening Pandora's box.
>
> I, still, have yet to see any evidence of harm that this proposal can
> cause.
>

The harm from my perspective is not so much of technical nature than more
of a cultural one.
And plenty of “evidence” has been provided in this thread for why this
proposal is a risk for the language.

If not then Letanyan put it perfectly:

On Thu, Dec 7, 2017 at 7:37 AM, Letanyan Arumugam via swift-evolution <
swift-evolution at swift.org> wrote:

> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
>
> The goal of this proposal is to *bring people from a culture where
> excessive use of this would be the norm for them*. *Why would it be so
> hard to imagine that people would adopt bad principles, knowing or
> unknowing, because this is what they’ve always done?*
>

> Evidence is going to be hard to get since I don’t know any other language
> like Swift that has done this for the same reasons before. As far as C#
> goes were they trying to get people from a heavily based dynamic community
> or help those already in the community?
>

[…]


My fear is that a design pattern around dynamic members and calls arise
> that is *used to bypass the perceived initial annoyance of Swifts type
> system from new developers that come over to Swift* and are now starting
> to try and go native. They *have no reason to think* about their
> conforming types as *something that might fail* because *they’re using it*
> to model behaviour that they’re used to (good or bad). I don’t see why it’s
> so bad to remind people that these conformances should be failing and only
> in rare cases should you ever have a dynamic member lookup that is fine to
> ignore all failing lookups.

*People coming from JavaScript could perceivably make dictionaries conform.
> And later JSON, database, file and basically all resource API’s would
> follow.*

Why would all of this happen rather than people behaving the way current
> Swift community members behave?

Because I worry that by bringing in people from other languages that *a new
> learning path is created*. One where you start by learning your language
> interoperating with Swift. And then pick up other Swift features as you go
> along using your Python API for example. *This would create a disparate
> Swift community.*


"This would create a disparate Swift community” is the money quote here and
the elephant in the room.
I fully agree with Letanyan. Couldn’t have said it any better.
What more evidence do we need that there _is_ potential for harm? This is
no blind and reactionary fear-mongering.

> - 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?
>
> This is an expert-only feature like the ExpressibleBy protocols.  This is
> not something that will be introduced or taught in chapter one of the Swift
> book, or in the Swift Tour.


So expert-only features don’t need to be documented/taught or get
human-friendly diagnostics or debugging support?

Regardless of whether something is an expert-only feature it will come into
contact with users of all levels of expertise.
And regardless of whether something is an expert-only feature it begs the
question of …

- How we will introduce & teach this feature to people coming from static
languages? How for those coming from dynamic languages?
- How we will make sure that users of all experience levels don’t get lost
when interfacing with an API that makes use of it?
- How we will make sure that we don’t create a blackboxed sub-language that
is void of any support for debugging and/or introspection.

I don’t understand this complete neglect of the community/educational
aspect of adding a language feature
with the potential to completely changing the shape of large parts of the
still young Swift ecosystem.

Vincent

On Thu, Dec 7, 2017 at 7:38 AM, Letanyan Arumugam via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Until, and if, the “resistance” presents some conceptual explanation of
> how this could cause harm (I’m not asking for anything concrete, just a
> logical series of events that causes a plausible problem in practice), my
> belief is that the Swift community will see this as unwarranted fear.
> >
>
> My fear is that a design pattern around dynamic members and calls arise
> that is used to bypass the perceived initial annoyance of Swifts type
> system from new developers that come over to Swift and are now starting to
> try and go native. They have no reason to think about their conforming
> types as something that might fail because they’re using it to model
> behaviour that they’re used to (good or bad). I don’t see why it’s so bad
> to remind people that these conformances should be failing and only in rare
> cases should you ever have a dynamic member lookup that is fine to ignore
> all failing lookups.
>
> People coming from JavaScript could perceivably make dictionaries conform.
> And later JSON, database, file and basically all resource API’s would
> follow.
>
> Why would all of this happen rather than people behaving the way current
> Swift community members behave?
> Because I worry that by bringing in people from other languages that a new
> learning path is created. One where you start by learning your language
> interoperating with Swift. And then pick up other Swift features as you go
> along using your Python API for example. This would create a disparate
> Swift community.
> _______________________________________________
> 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/20171207/8bd7613b/attachment.html>