And cliff takes care to error out when the wrapper description doesn't match the C++. "When in doubt, refuse the temptation to guess."
Our internal clients really like it. Someone described it the other day as "magic".
In can mean something so beautifully advanced that you cannot distinguish it from advanced tech and you really don't care how it works, since it works so flawlessly you couldn't bother looking behind the scenes. I.e. a praise.
Or it can mean something that uses some arcane unearthly constructs and at the moment you need to look behind the scenes you find yourself utterly lost. I.e. a critique.
At least if you weren't in the room as well. I'm assuming you weren't?
I understand why SWIG needs a .i file, as it doesn't understand much about the code. But when you control the compiler you can 1> as in the example I gave, look at actual explicit instantiation instead of doing the synthetic thing SWIG does, as well as make other, smarter decisions and 2> use #pragmas or attributes to direct translation at the point of use.
And the author even said himself that "code two files is a pain."
Thus my question remains: why the need for a .clif file?
Structured comments could work, but because the C++ compiler doesn't parse them, you essentially have a file-with-a-file, and 80% of the problems you encounter with the dual-file system.
You also have the problem of the API's client trying to understand what the API looks like. We don't want to make them read C++ code in any way, and a pyclif file looks a lot like python.
Finally, CLIF is substantially more terse than SWIG--on the order of 1/10th the number of lines. This makes it less of a big deal to have a separate file.