Traditionally (C++08 or earlier, as well as C), function headers
looked like this:
Type function ( Type param, ... );
C++11 introduced a new (optional) syntax extension:
auto function ( Type param, ... ) -> Type;
It was introduced to make template programming easier, as well as to
make lambda functions (also new in C++11) work better.
Inline::CPP doesn't parse function/method bodies, so the syntax's use
in lambda functions presents no problem. Nor is it a problem for
private methods that aren't intended to bind to Perl. However, if a
user has code that uses this syntax for a function header that needs
to bind to Perl, that user will be out of luck.
int add ( int x, int y ) { return x + y; } // OK.
auto add ( int x, int y ) -> int { return x + y; } // Not ok: Won't
bind to Perl.
This probably isn't a big deal for now; many compilers require flags
to be passed to the compiler even to enable C++11 features, and it's
unlikely to turn up in Inline::CPP-targeted code right away. But for
the future it would be nice to permit the syntax.
Surprisingly, this is just about the only new syntax I've found
(outside of the world of templates) that is problematic for
Inline::CPP. I fully expected the "enum class Type {...};" syntax to
be a problem, but enums don't bind to Perl anyway, so they're just
passed straight through to the C++ compiler.
Is there anyone out there comfortable enough with the
Parse::RecDescent grammar for Inline::CPP to take a stab at the late
return type specification syntax?
I'm happy to add unit tests for the new syntax, and apply patches that
pass without breaking any existing tests. If anyone wants to tinker
with it, fork the Github repo, and issue a pull request if you're
successful.
Dave
--
David Oswald
daosw...@gmail.com
