GeezerVison

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 bringing pybind11 or cython 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 at https://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?

@anntzer would you like to revive this?

It should not be a big trouble to lower requirements to C++14 (does it use any C++17 features besides nested namespaces and structural bindings?) which is +- adequately supported by MSVC2015U3 (July 2016), GCC 5 (April 2015), Clang 3.5 (September 2014), and is a default in GCC for 4 years (since GCC 6), in Clang for 2 years (since Clang 6).

Sadly, if we want to support any non-latest RHEL we have to use no more than C++11. Probably it is also not a big deal, since I cannot immediately recognize anything from C++14 that is used here.

Only if we can pre-agree that this (especially adding a requirement on a recent C++ compiler and adding pybind11 as build-time dependency) is a viable approach that could ultimately be merged (it's a lot of work and I don't particularly want to do twice the same proof of concept); even then it may take a bit of time because, well, it's a lot of work :)

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 ;)

Is std::optional used in the PR? It is a C++17 thing, but if it is needed for pybind11 we could try to borrow optional from Boost/libc++ (which implementation actually does not require even C++11), and even variant 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.