Clarify getting a key that does not exist from a map

[domenic]

Contrast lists:

An indexing syntax can be used by providing a zero-based index into a list inside square brackets. The index cannot be out-of-bounds, except when used with exists.

with maps:

To get the value of an entry in an ordered map given a key is to retrieve the value of any existing entry if the map contains an entry with the given key, or to return nothing otherwise. We can also use the indexing syntax explained above.

I think we should say "must not" and disallow out-of-bounds keys in both cases, requiring you to test with "exists" first.

An alternative is to define "nothing" to mean some special no-value, but the web has enough of those already (null, undefined, some specs use "failure") so I'd rather not do that.

Thoughts? Happy to whip up a PR if people agree. /cc @mkruisselbrink; this came up in w3c/FileAPI#92 (comment)

[annevk]

I've been using nothing in whatwg/xhr#176. It is somewhat awkward to do an exists test first.

Is it really bad to have some special values that make things more convenient? E.g., the reason I like failure a lot is that you then don't have to try/catch things. Just branch on the return value and carry on.

[domenic]

I think having null, undefined, failure, and nothing is way too many... That example you gave seems straightforward to replace with an exists tests, unless I'm missing something? It doesn't even use the returned value.

[annevk]

Way too many? What else do you want to get rid of? Agreed that we can probably drop "nothing" though. I misremembered.

[domenic]

I'm not sure we can get rid of the others, although we can limit undefined to just the cases where we need to directly interface with JS (and, as such, not make it an Infra concept). But having 2 in Infra/3 in the platform already feels like too many, thus not wanting to add another :)

[annevk]

Note that we also have "argument not given" which is arguably also a special value.