This is really cool! Every time I look into freetype/agg bindings I want them to be written with something like this.

This requires a C++17 compiler

The C++17 standard has not yet released 😉

C++11 is fully supported only by VS 2017 (and except some bugs in by VS 2015), what makes it Python 3 only if it is going to stay a part of mpl and not an independent library.

Why not use Cython? I do not see a big difference in bringingpybind11 orcython dependency.

• "C++17" = whatever C++17 spec gcc and clang currently support. I am fine with waiting for MSVC support too (http://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features), there are other things that need to be fixed first (e.g. setupext).
• https://pybind11.readthedocs.io/en/stable/faq.html#working-with-ancient-visual-studio-2009-builds-on-windows actually explicitly states that you can compile this module with a modern compiler and link it with old-compiler-generated modules.
• I think C++17 + pybind11 is much more expressive than Cython (and in any case you can also call py::eval from pybind11 :-)). Feel free to try rewriting this with Cython...

If you want a backend binding written in the same style you should look athttps://github.com/anntzer/mplcairo... (why did I not fix Agg? because I can't find half-decent docs for Agg anywhere...).

I think@anntzer is right, pybind is the better choice here. In cython, one has to replicate a lot from the header files in cython declarations, which is quite nightmarish for a library like freetype. Maybe cffi could deal with it, but in my experience it also requires a lot of wrangling with complicated headers.

Where is this at now that we are at MPL3.0?

I do not have problem with pybind11 or recent C++ standards, however while we can bundle/download pybind11 it is not a case for a compiler. I can take downgrading compiler version requirement work. Will this work for you?

I don't mind making the thing C++14 compatible (this doesn't look too hard, as you mentioned); C++11 would be annoying at least because it lacks std::(experimental::)optional, haven't checked if more things are needed.
The annoying part of the work now is just the rebase, and the multiple additional rebases that will likely be needed while this wanders through reviewing ;)

Isstd::optional used in the PR? It is a C++17 thing, but if it is needed for pybind11 we could try to borrowoptional from Boost/libc++ (which implementation actually does not require even C++11), and evenvariant if it is also needed.

What about C++14: Python 3.5+ on Windows requires MSVC2015+, so the problem is in some linux distros, and we can just tell to use recent Clang targeted system standard library (however it is most likely not an option for distro maintainers).

std::optional is used but we can also fallback on the older std::experimental::optional, which is also supported by pybind11, dunno how far back this lets us go compiler-wise.

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.