On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell <[email protected]> wrote:
> > On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > I would like to see an example where this string plausibly makes the > difference between having to hunt down the code and not have to do so. I do > not believe that "array must not be empty" or "array guaranteed non-empty" > is such an example, and I cannot myself imagine another scenario where it > would make such a difference. > > > You needn’t imagine. There was one up-thread: > > let paramData = params.data(using: String.Encoding.ascii)! > > Huh? Why is force unwrap safe here? OK, the code plainly says the author > thinks that `params` must already be ASCII, but why is that a safe > assumption? What reasoning lead to that? What other sections of the code > does that reasoning depend on? If we get a crash on this line of code, what > chain of assumptions should we follow to discover the change that broke the > original author’s reasoning behind the force unwrap? > > This is a job for a comment: > > let paramData = params.data(using: String.Encoding.ascii)! // params > is URL-escaped, thus already ASCII > > Aha, it’s URL escaped. > > That comment does not repeat information already stated in the code > itself. It does what any good comment does: it explains intent, context, > and rationale. It doesn’t restate _what_, but rather explains _why_. > > For those who appreciate comments like that, this proposal simply allows > them to surface at runtime: > > let paramData = params.data(using: String.Encoding.ascii) !! "params is > URL-escaped, > thus already ASCII" > > And those who see no value in such a runtime message — and thus likely > also see no value such a comment — are free not to use either. > If this is the most convincing example, then I'd actually be adamantly _against_ such an operator (where now I'm merely skeptical and would like to see evidence of usefulness). This example is, quite simply, _wrong_. Here's why: First, if force unwrapping fails, the message should explain why it failed: the reason why it failed is _not_ because it's URL-escaped and _not_ because it's ASCII, but rather because it's **not** ASCII. Second, even supposing the wording were fixed, it's at best not more useful than `!` and at worst misleading. If the error message is "params not ASCII-encoded" then it restates the code itself. If the error message is "params not URL-escaped," then it's misleading, as that's not at all what the LHS is actually asserting: it can be unwrapped *whether or not* it's URL-escaped and it only matters that it's ASCII. You **absolutely cannot** proceed from this point in the code assuming that `paramData` is a URL-escaped string. > Cheers, > > Paul > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
