phone-number 1.5.0.6: add cases to test data that cover invalid use of "1" or "0"

[sshine]

This should catch solutions with a validation function that calls itself recursively when the first digit is '1'.

Addresses exercism/problem-specifications#1325

[petertseng]

So! Since exercism/problem-specifications#1327 was taken instead, I suggest either using those cases. Or an option can be to leave it for another person to use those cases.

[sshine]

I'll adopt the new cases.

[sshine]

To go to version 1.6.0 of problem-specifications for phone-number seems to require us to use Either String instead of Maybe: exercism/problem-specifications@7290b84 -- I'm not sure where the decision for this should rest.

[NobbZ]

@sshine Why? How a specific error object from the spec is represented in the actual implementations is totally up to the track.

[sshine]

@NobbZ I said it seems like that, but I'm happy to know that individual tracks can disregard errors.

If we're going to keep the Maybes here, we can trivially bump phone-number to 1.6.0.7.

[petertseng]

This is, as far as I can see, the correct thing to do for 1.5.0, so we should merge this.

1.6.0: Does the student learn anything more interesting if required to distinguish the different sorts of errors that could occur?

If yes, should use Either. Some possible types to use for the Left would probably be:

• discriminated union
• the leftmost invalid character and the position at which it occurs

I'd advise against using a String as Left type.

If no, should use Maybe.

[sshine]

I think we should keep to Maybe and think of a good gradient point for using Either as error handling.

I agree with your points.