Closed markspanbroek closed 1 year ago
IF this whole .?
construct could be inside a loop and IF user code in expression[index].some
can be the equivalent of something like the user code in () below:
var y = 0
for i in 1..10:
var x = i
# if true: # 5
block: # 385
y += x*x
try: # User Code in () of try: here
(if y > 2: break # like "goto block"
raise newException(KeyError, ""))
except KeyError:
discard
echo y
then you can just run that Nim code in a test file and see how block:
and if true:
produce different answers as noted in the comments.
Now, I am not sure if we can strictly exclude both IFs in this highly specific .?
situation. Maybe. OTOH, if you just change block:
to if true:
then neither the user nor the lib author need think/worry about it which is..a nice property. :-)
It's a kind of subtle gotcha - mostly from many years of Nim folk recommending the control flow construct block
for its scope side effect rather cavalierly. There is more discussion here. (Thanks to @Menduist for tracking that down.) I mostly figured you would want to know about this potential issue (EDIT: if you did not already!). As a community, we should perhaps not abuse block
like we often have or get that template scope
into std/sugar
or something.
Wow, that's a real gotcha, I had no idea. Thanks for letting me know! I'll make sure to update the code to remove the block
s.
Should be fixed in #28 @c-blake.
In rare instances, the Nim compiler will generate the same symbol more than once. Adding a
block
works around this issue.Reproducing this behavior in a unit test has proved elusive.