> 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 > <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
