I agree with Jaden and Xiaodi above—making Never a proper bottom type and using ?? would accomplish the same thing, and it's more general because it doesn't imply fatalError.
IMO, I don't think we should be making it *easier* to hide traps in our code. I don't think having to write a full guard/fatalError is all that bad a thing—on the contrary, I want major failure points to stick out when I read code. That being said, if some users want something like this, Never + ?? would get us there with something already planned for the language, rather than introducing a new operator (for which the bar should be set high). On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > > it gives me the creeps to leave something like ‘fatalError’ in a > shipping application > > > Agreed, and I would use it for _exactly_ this reason. > > I avoid force unwrapping in production code, looking first for ways to > gracefully handle the situation. Whenever I do use !, there is careful > reasoning behind its use: “this is safe because p → q, and there is no > reasonable way to handle this error because it cannot happen.” I take care > to note this reasoning in a same-line comment, e.g.: > > paramString.data(using: String.Encoding.ascii)! // ASCII safe because > paramString already URL escaped > > Such reasoning will, of course, eventually fail somewhere. It would be > helpful to get runtime diagnostics on such a failure: > > paramString.data(using: String.Encoding.ascii) !! "URL escaped > paramString must be ASCII" > > So Rien, I endorse this idea from the perspective of one who is !-averse. > > Cheers, P > > > > On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I would not use it. > > Somehow it gives me the creeps to leave something like ‘fatalError’ in a > shipping application. > > During development it could make sense, but then again I like to keep > development and shipping the same as much as possible. > > > > Regards, > > Rien > > > > Site: http://balancingrock.nl > > Blog: http://swiftrien.blogspot.com > > Github: http://github.com/Balancingrock > > Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift > > > > > > > > > > > > > > > >> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> Using an operator to provide feedback on the context of a failed unwrap > has become a commonly implemented approach in the Swift developer > Community. What are your thoughts about adopting this widely-used operator > into the standard library? > >> > >> guard !lastItem.isEmpty else { return } > >> let lastItem = array.last !! "Array must be non-empty" > >> > >> Details here: > https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b > >> > >> Thank you for your thoughtful feedback, -- E > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution