proc testTemplate[X, Y]() =
echo "Sizes are ", sizeof(X), " and ", sizeof(Y)
when X is Y:
echo "The two types are the same"
else:
echo "The two types are different"
echo "* * * int/int * * *"
testTemplate[int, int]()
echo "* * * int/float * * *"
testTemplate[int, float]()
echo "* * * int32/int64 * * *"
testTemplate[int32, int64]()
echo "* * * float32/float64 * * *"
testTemplate[float64, float32]()Based to what the Type equality section in the Manual says, I was expecting to see that all the pairs were different but the first one (int/int). Instead, what I get is the following:
* * * int/int * * * Sizes are 8 and 8 The two types are the same * * * int/float * * * Sizes are 8 and 8 The two types are different * * * int32/int64 * * * Sizes are 4 and 8 The two types are the same * * * float32/float64 * * * Sizes are 8 and 4 The two types are the same
It seems that is does not allow to discriminate among integer/float sizes. Is this the expected behavior?
The reason why I'm interested in stuff like X is Y is because I am trying to do the following:
proc convertSeq*[X, Y](arr : seq[X]) : seq[Y] =
when X is Y:
result = arr
else:
result = newSeq[Y](len(arr))
for i in countup(low(arr), high(arr)):
result[i - low(arr)] = Y(arr[i])However, the compilation fails near the line result = arr if I call convertSeq[float32, float64](arr), saying: "Error: type mismatch: got (seq[float64]) but expected 'seq[float32]'"
stefan@AMD64X2 ~ $ cat istest.nim echo int64 is float64 echo int32 is int64 echo int64 is int32 echo float32 is float64 echo float64 is float32 $ ./istest false true false true true
var x, y: float echo x.type == y.type echo float.type == int.type Error: type mismatch:
OK, I indeed had the feeling that a bug may be involved. But I think the initial poster just thought that he did something wrong.
[EDIT]: And no, it is not easy to find that bug in issue tracker -- just tried a few minutes with search terms like "is operator" or "is float64".
Araq, I am probably quite stupid, but I'm not lazy. I wasn't expecting this to be a bug, but some design decision I did not understand. In fact, I was sure somebody would have answered with a link to the relevant section in the manual explaining such behavior.
I agree with Stefan_Salewski, finding issues related to "is" in the bug tracker is not easy, I spent some time navigating through the 17 pages of bugs. I think the bug Araq is referring to is float types are not distinct. However, the bug description only tells part of the story, as the problem happens with int32/int64 as well.
I will no longer waste anybody's precious time. Thanks for the help and so long.
@zio_tom78: ..overreacted to your comment, it was a childish behavior from my side..
I totally see your point. I think people should not bash others for asking questions, especially ones supported with code they try to understand. For newcommers getting feedback from experienced users on the forum makes more sense to me.
The optimal route would be to have a sticky post with a title like "Read this before posting a compiler bug" or "Have a bug? Read this".
Unfortunately, the forum doesn't support sticky posts. (Actually, what would need to be done for sticky-post support?)
I sympathise with @zio_tom78's statement that "finding issues related to "is" in the bug tracker is not easy".
In general, operators are chosen precisely because they are either (i) short, frequently-used English words ("is", "of", "and", "or", "not") or (ii) punctuation characters.
Short, frequently-used English words will probably be difficult to search for (high recall but very low precision) and punctuation characters might not be searchable (if they are considered special characters by the search function) or might not be indexed (if they are considered punctuation tokens). In fact, short, frequently-used English words might be considered stop-words and also not indexed.
Thus, it might be helpful to minimise this problem in the future, if issues relating to operators were labelled in Github with consistent, standardised labels like operator is and operator % (or operator percent, if % is not allowed in a label).