> I have another idea/iteration to run by you then.  One of your chief
> quibbles, although I don't think it's your underlying one, is Cython must
> understand what's going on.  So how about we support a block of C/C++ code
> as a proper construct.  Same name but now, I guess braces maybe get involved
> (since semicolons do too).  Then to transform (mangle) the nested
> identifiers in accordance with scoping/shadowing rules we pull in the python
> bindings to llvm/Clang to parse that complicated code, work with the AST (or
> further down the rabbit-hole) appropriately and spit it back out.  Obviously
> you could detect and analyze embedded statements to your hearts content to
> decide to do something smart about that (you mentioned exception handling
> and return statement as concerning items).
>
> The potential hazards here are that LLVM/Clang is brought in (LLVM is
> already on ~ everybody's linux boxes as a graphics shader dependency) and
> it's [python] api changes somewhat often.  I've used it before with success
> for python driven C++ POD boiler plate (IO, size checks, visitors methods
> etc) autocoding.
>
> If you can understand the underlying C/C++ and get over that Cython will
> always run on a C/C++ compiler in our universe,  and make that a feature to
> embrace, not a detail to hide (who actually benefits in the later case?) -
> are you still against the significant convenience - and potentially only way
> to make things work when Cython is not supporting a C++ way of doing things
> (say things aren't finished/working yet)?

That would help solve the analysis, though enormous cost in complexity
(one now has two ASTs one must understand and reconcile, and a huge
amount of C++ knowledge must be baked in to understand the AST (or
even lower levels) and it'd be neigh impossible to do "partial
analysis" for features we don't yet understand, probably harder than
putting them into Cython itself modulo parsing) and making LLVM/Clang
a dependency for Cython is probably a non-starter as well.