> if the condition is never met importing xyz is wasteful Yeah, unused imports still increase binary size despite deadCodeElim (`--d:release` `--opt:size`). In a perfect world that would not be the case...
* * * > you can use `from math import nil` Yup. But I [still](https://irclogs.nim-lang.org/15-06-2017.html) think Nim needs better syntax sugar for doing this, since preference for old-fashioned mandatory namespace prefixes are such a common complaint [(ex)](https://www.reddit.com/r/Python/comments/6gwv4a/a_glance_at_the_pythonlookalike_nim_programming/diu3g2y/). Writing `from blah import nil` for every import is ugly. One is tempted to do something like: macro load*(modulesSeq: varargs[untyped]): untyped = result = newStmtList() for module in modulesSeq: result.add parseStmt("from " & $module & " import nil") load os, math But doing this through an ad-hoc macro has some down-sides. **@Araq, how about adding a built-in keyword like that before v1.0?** If so, we should discuss if the keyword name `load` is ideal. I first thought about using `use`, but that would remind people of Perl, while `import` reminds people of Python - this would be topsy-turvy of how those two languages behave regarding mandatory namespace prefixes. It's of course too late to rename the `import` keyword. So it would mean: "not _just_ `load`, but _also_ `import` into current namespace". * * * > runtime imports are not really possible in Nim because Nim is not an > interpreted language Nitpick: Nim is a language that S2S-compiles to a "not interpreted" (C, a machine code targeting language) target, by default. But it can also compile to interpreted languages as well (JS now, maybe others later). Perhaps one could create a library for runtime imports, which would work differently on different targets: [JS](https://github.com/bluenote10/KaraxExamples/tree/master/JsIntegration), [so/dll](https://nim-lang.org/docs/manual.html#foreign-function-interface-dynlib-pragma-for-import), etc. (It would need to read the target code and generate headers at compile time.) But that's a whole nother opera.
