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

[Mathew Huusko V]

You're saying that there is universally no inherent difference, and that
all calls "determine if you have called it" correctly, but then picked one
of only a handful of cases in current practice where that is actually true.
Yes "+" (/other math operators) and array access are unsafe, but most other
things in Swift are safe by default, and you have to opt into un-safety
(e.g. forcing or checking an optional or throwing call) — this is a main
tenant of the language.

Perhaps I was not totally clear while mixing and matching my
observations/interpretations of safety and fallibility in compile vs.
runtime and readability vs. writability in my initial email, but I believe
the spirit of my concern was clear: there is obviously a difference between
dynamic and static languages/calls, and having the syntax the same is
misleading in a language centered around static safety, perhaps to a degree
where it is ergonomically counter productive.

On Mon, Nov 27, 2017 at 4:12 PM, Magnus Ahltorp <map at kth.se> wrote:

> > 27 Nov. 2017 22:38 Mathew Huusko V via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > 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.
>
> There is nothing that is inherently non-fallible with "normal" Swift
> calls. As far as the caller can tell, any function or method you call can
> fail. There is no difference here; the implementation of the "user-defined
> dynamic member lookup" object will determine if you have called it in a
> proper way or not, in the same way as "+" will determine if you have called
> it in a way that overflows or not.
>
> /Magnus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/3523738e/attachment.html>