That is plainly contrary to what the proposal says. It is to be sugar for a string argument to fatalError, which would be read: "x, which fails iff y." On Wed, Jun 28, 2017 at 23:35 Paul Cantrell <[email protected]> wrote:
> On Jun 28, 2017, at 10:49 PM, Xiaodi Wu <[email protected]> wrote: > > On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell <[email protected]> > wrote: > >> >> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu <[email protected]> wrote: >> >> 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. >> >> >> Fine, then: >> >> let paramData = params.data(using: String.Encoding.ascii) !! >> “params must be URL-escaped, and thus ASCII" >> >> …or format the runtime message to fit that style of phrasing: >> >> fatal error: unexpectedly found nil while unwrapping an Optional value >> Failing underlying assumption: >> params is URL-escaped, thus already ASCII >> Current stack trace: >> … >> >> 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 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. >> >> >> Yes, of _course_ it’s not what the LHS is actually asserting. That is >> precisely the point of having a message. There is pertinent information not >> already present in the code. >> > > See below. > > >> The message describes an invariant not captured by the type system. In >> other words, the author of this code believes they have guaranteed >> something that the compiler itself cannot check. Thus this statement is >> exactly backwards: >> >> You **absolutely cannot** proceed from this point in the code assuming >> that `paramData` is a URL-escaped string. >> >> >> The author of this code is telling you they have _already_ proceeded from >> this point assuming that `paramData` is URL-escaped. >> > > No, the author proceeded from a previous point assuming that `params` is > URL-escaped. The act of unwrapping does not demarcate the transition > between where `params` is assumed to be URL-escaped and where it is not. > > > Well duh. But that’s not what the message conveys. > > Read x !! y as “x! /* which is guaranteed to succeed because y */”. > > P > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
