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

[Xiaodi Wu]

On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
swift-evolution at swift.org> 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.
>
> fatalError shouldn’t be used excessively. API surface areas for these
> types are going to be massive (infinite technically). I assume many people
> are going to be writing a lot of code would these types and calling many
> methods and properties which would all essentially have a fatalError. Would
> you consider it good code if the majority of all your types had methods
> defined with fatalError calls.
>

What is the basis for this claim? Probably the majority of standard library
methods check preconditions and trap on failure. That is how I write my
code as well.

What’s so wrong with adding another layer of protection on top to bypass if
> you want to do this.
>
> 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.
>
> Okay we use Unsafe. Then should we have something similar for this. A
> UncheckedDynamicMemberLookup [1] and a DynamicMemberLookup [2]? my one
> objection to this would be that I would like to convert a
> UncheckedDynamicMemberLookup to a DynamicMemberLookup.
>
> [1] would work like the current proposal for DynamicMemberLookup
> [2] would only allow returning an optional
>
>
> 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?
>
>
> 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'm unsure of this, but as far as I’m aware Swift language proposals
> shouldn’t rely on editor features. But like I said I’m unsure of this and
> if someone could clarify this that would great.
>
>
> _______________________________________________
> 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/d4304888/attachment.html>