binary-search: Is searching for a nonexistent item an error?

[petertseng]

Notice that https://github.com/exercism/problem-specifications/blob/master/exercises/binary-search/canonical-data.json uses -1 to indicate "searched-for item is not in the array". The question: Should this be considered an error? If so, binary-search is covered by #1311 .

I consider searching for a nonexistent item an occurrence that the implementation should expect to routinely happen -- in a language with exceptions, for example, I would not recommend the use of an exception for this. A language with optionals would use its None for this case, and use Some(index) when there actually is an index.

However, I'll refrain from commenting on whether this should be represented in JSON as a -1 sentinel or an error object or null.

In the absence of any other preference, I would suggest to keep it as -1, and close this issue without changes.

[Insti]

I agree it is not an error.

I would suggest to keep it as -1, and close this issue without changes.

I'm fine with this.

[NobbZ]

I do not think this were an error, as it just tells that we do not have an item there.

I do not like it beeing -1, this reminds me pretty much of C or PHP. There are a lot of languages that have different idioms around this.

I'd prefer specifiying null as expectation in the JSON and let the tracks deal with their idioms and how it is representable.

If there is a literal -1 in the expectation, people will tend to mechanically copy and paste it into their testsuites.

[coriolinus]

The correct answer to this question is strongly dependent on the idoms of language being used. Some off the top of my head:

• C, PHP: -1
• go: 0, false tuple
• rust: None from the Option enum
• Haskell: Nothing from the Maybe monad
• python: KeyError exception or None
• bash: ""

The problem, to me, is that it is possible to return -1 to indicate this condition in all of these languages, but it is unidiomatic in the majority of them. If we use a non-error -1 to indicate this condition in the canonical data, it can be interpreted as a requirement that languages implement that, despite it being unidiomatic.

For that reason, I prefer to represent it as an error; this more clearly signals to track maintainers that special handling and rewriting may be required. This doesn't preclude tracks from using a magic value in languages where that is idiomatic, and it allows tracks with better error handling than magic values to proceed with their native idioms.