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

Joe DeCapo snoogansbc at gmail.com
Wed Dec 6 22:11:32 CST 2017


> On Dec 6, 2017, at 9:45 PM, Paul Cantrell <cantrell at pobox.com> wrote:
> 
> 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.


Yeah, I think I'd prefer this to stay as a normal protocol conformance. But if the proportion of resistance is high enough, I think the adoption of some annotation above and beyond the norm would be ok (again, at the declaration site, not the call site). Especially since this is a somewhat privileged protocol if any of the restrictions suggested in the proposal go forward, since they don't really apply to normal protocols.

> 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.

I agree wholeheartedly. I was just trying to bring some specifics to the examples given so far.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171206/d326ff7d/attachment.html>


More information about the swift-evolution mailing list