Hello guys,
while browsing the Nim standard library I noticed that a contructor for the Color type is defined as follows:
proc rgb(r, g, b: range[0 .. 255]):
Why would one limit the range of possible values for r,g and b with range[0..255] instead of using the char type? Unsurprisingly, the Nim manual states:
The character type is named char in Nim. Its size is one byte.
Hence range[0..255] and char should cover the same range of numbers.
My initial consideration was that range[0..255] doesn't require a explicit type cast but the program has to ensure that the argument is indeed between 0 and 255. In the end the compiler either knows the value of the arguments at compile time or the value is determined at run time (i.e. by reading stdin). In the latter case the bounds of the inputs would have to be checked anyways before passing it to rgb(). In the first case the compiler would yield an error message anyway in case the value is out of bounds.
Thus function signatures can be made more flexible as bound checks will or have to be performed either way.
Not in a strongly typed language. A char is a character while a range[0 .. 255] is an integer in the range 0 to 255.
Just like the temperature of my oven can not be interpreted as an amount in my wallet!;-)
Not in a strongly typed language. A char is a character while a range[0 .. 255] is an integer in the range 0 to 255.
@spip of course the type system distinguishes between char and range[0..255] as types. My last comment was about a char that can be seen as a (printable) character like 'w' or as a variable storing a byte (but still being of type char).
@sky_kahn in a script I initially char instead of range[0..255] as argument type to avoid that an integer gets passed (which itself is fine) which is out of bounds, e.g. when you using input from stdin. But with unkown inputs bound checks have to be performed anyway.
In conclusion, using char over range[0..255] doesn't add any more type-safety regarding the bounds of an argument's value and requires an additional cast from int to char.
To provide a bit more context: for a little project im using the nimPNG module, more spefically it's loadPNG24 proc. With the following snippet one can see that the rgb values for the pixels are stored as a sequence of chars.
import nimPNG
let scan = loadPNG24("image.png")
echo typeof scan.data # prints string
echo typeof scan.data[0] # prints char
Later I found the color module in the standard library, which may intend to use as well. The aforementioned rgb proc's return type is range[0..255].
This made me think about range[0..255] vs char for storing rgb values.
The aforementioned rgb proc's return type is range[0..255]. No, its return type is Color (which is represented internally as an int).
I actually meant the data type of the proc's arguments. I've corrected my last comment accordingly.
Why would one limit the range of possible values for r,g and b with range[0..255] instead of using the char type?
This is a matter of representation, RGB is represented as range[0..255] to clearly indicate as such while char is, well, literally a character. I rarely use the char past of 'z' so I don't know what char which has value of 198.
Another thing, to work with RGB is literally to work with the integer of each component, hence representing each component as char would internally has to change it to int. Also, I don't think anyone who works with RGB would think R, G, B component as character.