Disclaimer: Based mostly on my C++ experience with this kind of problem, did not run into it with Nim and can't test this second.
> If you're including other people code in your project you just have to trust > them in the same way you trust it to work. Linus Torvalds has said more than once that "security bugs are not special, they are just bugs that have security implications" (paraphrasing from memory), and I think he's right - the reason we (in general) care more about them is that rather than producing a wrong answer or no answer at all, they allow a determined malicious actor to willfully do disproportional damage. To put this in concrete terms, instead of `foo(x)`, assume it's `draw(x)` \- Library A deals with drawing on a canvas, and Library B deals with drawing money from a bank account; for whatever reason, Library A's `draw[T](x:T)` is a template that can draw anything that can be converted to a string. and Library B's previous version did NOT have a `draw(x:money)` (it only had a `transfer(x:money)` proc), but now it does. There is no malicious intent on the part of any library author (indeed, the library authors don't know each other or the user or the main program that uses those libraries), but a malicious user can cause money to be drawn from the account by triggering an action that needs to draw some money value on the screen. This example is a bit contrived and colorful (and based on one of Stroustroup's), but not so far fetched; You could have an `execute(x:T)` template that does a well defined, well secured thing -- and then another library adds `execute(x:string)` that shells out and executes a command line. Or -- much harder to catch -- the new proc has the same functionality as the old one it overrides, but implemented in a different way that overall creates a TOCTOU or race condition or otherwise harms integrity. I didn't have time to try these in Nim (maybe most cases already have a warning), I have encountered something similar (not security related, just plain old bug) with C++ templates, which is just one of the reasons I've avoided C++ for more than a decade. It should be possible to warn that "import B specializes template from A but they are not related" or something like that, I think - e.g. if both a concrete and a template definition match at a call site, then the template definition must be known at the concrete definition's site or something like that.
