Timothee Cour

Besides manual (via `extern(C++,ns)`) and automated (via SWIG), there is another approach to autogenerate C++D bindings but I haven't tried it: calypso: https://forum.dlang.org/post/[email protected] Calypso: Direct and full interfacing to C++...

* calypso: it would definitely make interfaces easier. However it's also a risky approach (eg it's based on a fork so risks further limiting the ecosystem on which it'd be...

not at the moment unfortunately. Would be happy to contribute on this though if that approach is considered

a lot of bugs have recently been fixed in calypso making non-trivial opencv programs work in D, so IMO this should be preferred way forward

would be good to have a document specifying a guidelines for all API's to conform to, to enforce consistency as much as possible. Here are a few design choices that...

ya, the simpler the code the better to not scare away people, the important thing is that the code compiles and runs

reopening as I'm noticing the examples are in readme.md instead of embedded in code. why not use documentation unittests? (https://dlang.org/spec/unittest.html) This will guarantee they stay in sync with code changes,...

can you please check whether upgrading C compiler would fix these windows-specific bugs affecting math issues https://github.com/nim-lang/Nim/issues/17017?

> tested, #17017 is not a problem on mingw 8.1 great, just to clarify, what's the output you get for: ```nim import math func c_frexp2(x: cdouble, exponent: var cint): cdouble...

> Nim should refuse to compile harmless looking stupidities like this one a more robust approach: setting limit on process memory usage (not GC memory as it doesn't cover everything),...