Consider supporting named algorithm return values.

[mikewest]

What problem are you trying to solve?

As discussed in whatwg/fetch#1867 (comment), it's sometimes helpful (and at least somewhat common practice) to return some prose value from an algorithm that makes the result clear. For example:

• https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check returns "blocked" or "allowed" (as do several algorithms in CSP, SRI, etc).
• Several algorithms in URL, HTML, etc return "failure" (e.g. https://url.spec.whatwg.org/#concept-domain-to-ascii, https://url.spec.whatwg.org/#concept-host-parser, https://html.spec.whatwg.org/#rules-for-parsing-dimension-values, ...).
• WebDriver defines "success" and "error" (https://w3c.github.io/webdriver/#algorithms).

These aren't well-supported by Infra. Perhaps they should be?

What solutions exist today?

No response

How would you solve it?

It seems ideal to agree on some way of representing these kinds of algorithms and their results in Infra.

Based on very little research, I'd suggest that we define "failure" in any event, and consider defining "boolean" algorithms in some way, with a set of truthy values ("Allowed", "Valid", "Success", whatever other common patterns we find) and a set of falsy values ("Blocked", "Invalid", "Failure", etc).

Anything else?

No response

[mikewest]

Digging a bit more, #545 touched on a big chunk of this in the past.

[annevk]

Yeah, "failure" we need to define as its own type, very similar to how null is defined already.

I think these others we could define in the Booleans section and consider them "named booleans" whereby you always have to compare them explicitly (so you don't have to know which is true and which is false). And if we give them <dfn>s they can be linked so it's at least explained somewhere.

Not sure who else might have thoughts on this. Maybe @tabatkins or @zcorpan?

[mikewest]

If we require explicit comparison (which I agree sounds correct), then perhaps we shouldn't call them booleans at all but something like "named return types"? That heading could explain that these are prose values with no platform representation, and thereby encompass "failure" as well as any other widely-used value we came up with?

[tabatkins]

Yes, I think they should be considered and defined as something separate from bools (which are always true/false, or true/false/unknown at worst). I like @mikewest's suggestion. Maybe <dfn for=return>failure</dfn> so they're easily linkable with [=return/failure=]?

[aphillips]

Note: an I18N best practice for enumerated keywords is to make them human legible, but obviously "computerese", so that developers will remember to wrap them in localizable display values and be less tempted to pipe them to the display (because they are already in English, which is only great if the rest of the display is in English too). All lowercase (failure) is fine. Shouted (FAILURE) is a bit better. Ugly (RETURN_FAILURE) is ideal, but, well, ugly and verbose. Values in Titlecase (Failure), such as in the original proposal, usually provoke me to write a comment like this because they look like already localized messages.

Also, if you go down this path, don't forget to define matching as ASCII case-insensitive somewhere prominent (so that failure matches even when the runtime locale is e.g. Turkish).

[tabatkins]

@aphillips Note that this is talking about internal spec algorithm values, not author-exposed enumerations.

[aphillips]

@tabatkins Yes, I know. But people (or their robot friends) often write code from the specifications. So "return Success" becomes code like return "Success". Also, this is just a reminder.

[annevk]

Lowercase and (optionally?) linked seems good. That goes well with "continue" and "break". I'm not entirely sure about calling them return types as they can be used as arguments as well (failure certainly is in a few cases).

Also, if we don't make these be like booleans, what is their type? With booleans it's clear there's two values that go together. If we define all of them like we define null you'd have to always say "success or failure", but maybe that's okay? I guess we could do that and null would just be another "singleton type".

[mikewest]

I put up #687 just as a first pass to have something concrete to talk about. Not sure how much detail or advice is desirable (e.g. around "failure" as per the discussion in #545), nor am I sure about the name.

Regarding comparison, it seemed most straightforward to rely on equality comparisons through "is", rather than asking for "ASCII case-insensitive" comparisons. It seems inconsistent with existing usage to do anything beyond "is", but if there are good reasons to do so, we can consider it.