expecting simple FALSE instead of error:
import strutils
import std/[unicode, sequtils]
echo isAlpha("a") # true - works
echo isAlpha("ą") # true - works
echo type ("ą") # string
echo isAlpha("ą") # true - works
echo isAlphaAscii('a') # true - works
# echo isAlphaAscii("ą") # why error message?
# why not simply FALSE ???
# it seems that only type 'char' can be used
# how to check if a Unicode string is ASCII?
#[
Error: type mismatch: got <string> but expected one of:
proc isAlphaAscii(c: char): bool
first type mismatch at position: 1
required type for c: char
but expression '"ą"' is of type: string
expression: isAlphaAscii("ą")
]#
Python is weakly typed - so it is not a fair comparison - but it is much more forgiving:
Is it some kind of security risk? What would be a good, practical example of the risk?
Is it a principle of a strongly typed language?
I do see benefits of strongly typed language (that is the reason why I am learning Nim) - but this is a first disappointment with strongly typed language :-)
To answer the other questions in your post:
What is the risk of taking both types: the string AND the char type and gracefully respond with false if the string is not ASCII?
There isn't any risk, this is just down to API design. The Nim isAlphaAscii is simply meant to work on single characters, and not on a full string. For that we have allCharsInSet. And since Nim is a strongly typed language a single ASCII character is a char type. The fact that isAlphaAscii and isAscii behave differently is a bit weird.
Is it some kind of security risk? What would be a good, practical example of the risk?
No security risk, but a performance issue. If you wanted to check only if a single character is an alphabet character but we only had a string version then you might be tempted to write your own for performance reasons.
Is it a principle of a strongly typed language?
In a way. Because we have a type system that we can leverage to do checks for us and report errors to the user on compile-time it is more common to see stricter definitions of procedures over something like Python where you are forced to deal with whatever type the user hands you and the norm quickly becomes to write less specialised and more generic functions. This is even more the case in a language like Nim that has overloading and distinct types.
Python is weakly typed language - so it is not a fair comparison - but it obviously due to its weak types it is much more forgiving:
You're right, it isn't a fair comparison for some other reasons too. Python doesn't have a char type or a byte type for that matter, so the ONLY implementation python has for it's isascii function accepts strings. Nim has the ascii implementation for a char instead of string. Like @ElegantBeef demonstrated, making your own string isAlphaAscii function for strings is trivial. Could be worth including in the stdlib though, as this is so simple.
I see that we have allCharsInSet, nice.
As an aside, I feel we should follow python's example in adding any and every small utility function to Nim's stdlib that we can. Since frankly, a lot of comparison happens between Nim and Python, whether we like it or not, it'd be great to try and match it's capabilities. I am referring to even potentially obscure functions like bit_length() on numeric types.