On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
