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

[Paul Cantrell]

> On Dec 6, 2017, at 8:52 PM, Joe DeCapo via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 6, 2017, at 5:46 PM, Letanyan Arumugam <letanyan.a at gmail.com <mailto:letanyan.a at gmail.com>> wrote:
>> 
>> But IUO’s are marked with an “!” to differentiate it from a normal type, where as DynamicMemberLookup is just a normal protocol conformance. I would be curious as to what you think of this idea [1]? Would this still be too much of a constraint just to make sure that when people use this they’re explicitly aware of what they’re doing?
> 
> I think that sort of approach seems like an acceptable middle ground. There's probably some bike-shedding to be done about the terminology and such. I just think it's overboard to require explicit annotations at the call site (especially for every single call site invocation). I would totally be fine with some sort of extra annotation at the declaration site beyond a normal protocol conformance. I do think this jibes well with C#'s `dynamic` approach from what I've gathered so far, and which other people seem to think is a worthy standard we should look toward for inspiration.

This seems marginally tolerable, but excessive.

Do we mark every usage of a type that can generate precondition failures or fatal errors for reasons other than “no such method?” No, we don’t.

Do we use a syntactically privileged marker instead of just using words like “unsafe” for types that expose direct access to raw memory? No, we don’t.

Has all of this ruined the language thus far? No. Because the Swift core team doesn’t design, and the Swift community doesn’t adopt, ill-designed APIs that turn these facts into problems.

> My main objection to many of the critical responses to the proposal is that the examples all seem to ignore where the variables that are being invoked come from. I think we all tend to have a pretty good idea of what types we're dealing with, and what their behaviors are. And when we run into issues, we inspect those types. If this makes it more apparent on inspection that it has some special behavior, then I'm all for that. It would be similar to inspecting a type that crashed which turned out to be an IUO.

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.

If a little extra language ceremony helps assuage those fears, I guess I’d consider it. I still think static analysis — starting and mostly ending with boring old syntax coloring — answers most all the concerns people have raised, and this debate is a tempest in a teapot.

Cheers, P

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171206/d38fcb1a/attachment.html>