Ryan McConnell

> That's a breaking change. Instead the generic instantiation cache should distinguish between Option[uint32] and Option[Mode]. I don't disagree but a couple of things: - I assume this is only...

as a side note: it seems like the only utility in these "async tracebacks" is to condense the stack trace removing commonality from "reraised from" traces. It's not a bad...

For these async trackbacks specifically, something like that was the first thing that I tried to do. I didn't want to add anything to FutureBase or recolor the final exception,...

> @Graveflo I think this injecting the stack trace into the msg is from before "reraised from" existed and it should be removed. Unless there is something I'm missing there...

been messing with this some for a while. There might be another work around but this has run into the "`liftParamType` got messed up and was never fixed" thing again....

some background on this: ```nim discard not (let xx = 1; true) discard xx ``` Here, `xx` has to get added to scope, but only if the best candidate from...

Not that it's impossible to make this work, but the spec doesn't have any kind of rule that would make `int` match stronger then `uint` generically. I'm not sure this...

@nitely The substitution would be equivalent if both were a generic match. When you make `int` the generic constraint you are still matching generically with `T`. I guess `var x...

> Maybe just change it to `> isNone`? At this point, the reason to go `> isNone` is to maximize signature compatibility at the expense of increasing ambiguity. I don't...

fwiw this also compiles: ```nim type Concept = concept proc `$`(x: Self): string ConceptObject[A: Concept; B: Concept] = object # ok var a: ConceptObject[int, int] # error var c: ConceptObject[int,...