two-fer: Add blank test case

[jpreese]

I'd like to propose adding a blank string as a test case. Through mentoring I've definitely noticed that there's some ambiguity in what dictates no name given.

I personally think both null and a blank string should return "you".

[coriolinus]

I'm not in favor of this change.

There are plenty of languages where null and an empty string would idiomatically be considered equivalent. In these languages, this test makes a lot of sense.

However, in languages with Option types—here, I'm thinking Rust, Haskell, and the like—the two are not equivalent. If the function is called with the Some("") variant of an Option, then the output really should be "One for , one for me". The whole point of structuring the function signature that way is to separate the special-casing from the string contents. Adding this test would force those languages to abandon that distinction.

[rpottsoh]

I am impartial to the change. At the moment in the Delphi track for this exercise I am treating the null case as an empty string. Adding an empty string case will be redundant for me since I am already implementing the null case as an empty string case....

[petertseng]

Although this was discussed in #290 , my read of that issue detects no conclusion at that time.

there's some ambiguity in what dictates no name given.

I agree that it is ambiguous whether "" indicates "no name given".

Further, it is definitely true that the is at least one pair of languages that (by the customs of the respective languages) demand different answers.

• In Go, twoFer("") indeed must be One for you, one for me.
• In Haskell, twoFer (Just "") must be One for , one for me. (same for any other language using optionals)

I would find it unwise to list either of the above options (One for you, one for me. or One for , one for me.) as the only choice, as it would disadvantage languages that choose the other option.

I attempted to provide a structured way to represent this situation (different languages may make different choices) for all-your-base in #1002 but I deemed it unsuitable for that exercise.

Consider whether such an approach is suitable for this exercise. This is a great time to come up with a solution since it is a small exercise. Much better to have this problem now than later on with a large exercise.

[ErikSchierboom]

This PR has been open for quite some time. Maybe we could try reaching a decision? I don't really have a preference here.

[sshine]

I think this PR should be rejected on the argument that @coriolinus provides.

As for @petertseng's suggestion to provide alternative expected results a la "choices": { ... }, wouldn't this challenge test generators a bit?

Maybe we should add two-fer to a list of exercises that stand to benefit from this format change and consider adding it once enough tests stand to benefit - until then, the cost seems a little high.

[bitfield]

Closed as suggested. Happy to reopen it if there's any change in the circumstances.