Open haxscramper opened 3 years ago
IMO we should always allow passing the relevant hash/comparator to algorithms, it's explicit and more flexible, in particular doesn't affect unrelated code (if different hash/comparator is needed), as done in C++, D and other languages. This can be done in a backward compatible way and zero-cost way, avoiding a function pointer overhead even without lto
Good to know that this at least somewhat known issue. Even though it might be considered duplicate I would still prefer to leave it open, since this is a particularly tricky to reproduce, so more examples would be nice to have.
Is there any way currently to deal with this right now? Or I need to somehow instantiate needed generics earlier (by explicitly stating this limitation in documentation and carefully watching order of imports each time?).
PS: I'm also in favor of passing hash
/==
/<
explicitly to implementation.
Was fixed in #22828
Changing statement order in
simpleTreeDiff
causes compilation error. I'm not entirely sure if this is a bug, or some insanely convoluted generic interaction, but since the behavior of the compiler wildly differs only based on the order of generic instantiations it is probably a bug.Example
Current Output
Expected Output
No compilation errors
Additional
I added
static: echo typeof ...
intables.[]=
to printf-debug instantiation. Concreted code now is (module runnable example and documentation):And it produces different results based on order of the statements in code above or whether
var tmp: Table[string, seq[string]]
is present. When I try to compile example it outputsWhen I remove
var tmp: Table[string, seq[string]]
compilations succeeds, printing outWhich is what one could expect (
t.data
generic parameters are the same as in table itself).Nim version