You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the csharp track, many pangram solutions use the built-in method IsLetter(char). This method matches more than a-z, which leads to wrong results when the input contains Unicode letters. There are currently no tests that contain letters outside the a-z range, and thus a range of bugs are not caught.
The following strings should be tested as not pangrams (because they don't contain an 'a'):
Due to very different support of unicode across languages the problem-specifications do only cover ASCII (we haven't agreed if we use traditional 7bit or enhenced 8bit yet ;), some people imply the one, some people imply the other when reading ASCII).
If a language does cope well with Unicode handling, then its in the responsibility of the tracks maintainers to avoid and test against unicode pitfalls of that language.
Can you therefore file a bug at the C# issue tracker?
I say close it. If we care about handling unicode characters in a language track, seems like we should include an entire exercise around unicode handling and limit scope on other exercises.
@isani commented on Fri Dec 22 2017
On the csharp track, many pangram solutions use the built-in method IsLetter(char). This method matches more than a-z, which leads to wrong results when the input contains Unicode letters. There are currently no tests that contain letters outside the a-z range, and thus a range of bugs are not caught.
The following strings should be tested as not pangrams (because they don't contain an 'a'):
"äbcdefghijklmnopqrstuvwxyz"
"αbcdefghijklmnopqrstuvwxyz"
The following strings should be tested as pangrams (to ensure input with Unicode isn't just rejected):
"the quick brown fox jumps over the lazy dög"
"the quick brown fox jumps over the lazy dөg"
@NobbZ commented on Fri Dec 22 2017
Due to very different support of unicode across languages the problem-specifications do only cover ASCII (we haven't agreed if we use traditional 7bit or enhenced 8bit yet ;), some people imply the one, some people imply the other when reading ASCII).
If a language does cope well with Unicode handling, then its in the responsibility of the tracks maintainers to avoid and test against unicode pitfalls of that language.
Can you therefore file a bug at the C# issue tracker?
cc @exercism/csharp
@coriolinus commented on Fri Dec 22 2017
This has been discussed before in exercism/problem-specifications#428.
@NobbZ commented on Fri Dec 22 2017
Oh, it seems as if I am allowed to close here, so I'll move the issue over to C# repo directly.
The text was updated successfully, but these errors were encountered: