codex-storage / questionable

Elegant optional types for Nim
Other
116 stars 5 forks source link

Fix redefinition of 'T`gensymXX' error #27

Closed markspanbroek closed 1 year ago

markspanbroek commented 1 year ago

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.

c-blake commented 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.

markspanbroek commented 1 year ago

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 blocks.

markspanbroek commented 1 year ago

Should be fixed in #28 @c-blake.