> 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’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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
