I got it from
https://forum.nim-lang.org/t/3752#43859
to test for the existence of a module. That test is necessary as a user from Japan wants to use libnice with gintro on windows, without having full GTK installed.
That test is fine when there are zero errors in that module, but it gives strange bugs if there is an error.
This behaviour is the reason for
https://forum.nim-lang.org/t/7212
I just did a few tests, and it leads to various crashes -- crashes of the Nim compiler with segfault or crashes of the gcc.
Well, at least it is not a real problem with my own code.
Because you have a good memory and we talked exactly about that construct about 6 weeks ago:
https://forum.nim-lang.org/t/3752#43859
Or maybe it is because I forget to frame the title with the words "Let us praise Nimrod, the greatest language ever!".
But seriously, so I assume there is no other test for the existence of a module available? I was thinking about something like fileExists(), for that I would have to know the compiler import paths.
Because you have a good memory and we talked exactly about that construct about 6 weeks ago
Good point. I thought it was because your unique style of choosing titles.
Anyhow, iirc os.fileExists is available at compile-time but then you still need to duplicate the compiler's logic for quering the --path (if there is such a way).
A builtin canImport looks much more useful.
However, the feature itself only encourages even more fragility during a build. So now we can have "optional dependencies" depending on whether some other module is available. It's a bad idea. Either use the module or don't, don't "try". If the module implies a dependency so be it. Dependencies are bad, pretending that you don't really have them because they are optional is worse.
A builtin canImport looks much more useful.
Actually the one I'd like to implement is whichModule (https://github.com/timotheecour/Nim/issues/376) which subsumes canImport.
const path = whichModule("exitprocs")
(from which canImport is easy to implement, simply via whichModule("exitprocs").len > 0)
There are valid cases, and the workarounds without it are not good.