Unified rasterization API proposal about gil HOT 6 CLOSED

I like your proposal very much. Both, interfaces and implementation. Such unification via an extra level of indirection does not change the existing, let's say, low level interface, yet offers a clean and friendly one.
It would be nice to have it for Boost 1.80

from gil.

At the start I thought about providing some sort of fancy iterator that would avoid creating temporary vector. Now with the advent of coroutines I believe it would be great to just create a coroutine that would yield coordinates, then build an easy to use frontend that would support the basic use cases.

from gil.

Yes, I also thought that lazy-evaluated coroutines could eliminate the need for extra memory allocation. This proposal here could serve as a stable API across different kind of rasterizers and the implementation could easily be changed in C++20 without having to change the interface.

from gil.

I think there is nothing wrong with hosting conditionally-compiled implementation based on coroutines enabled for C++20 compilation.

from gil.

I will close the issue as it is merged.

And regarding coroutines: If P2502 makes it into C++23 (looks promising), my personal preference would be to delay implementation of generators until then rather than reinventing the wheel.

from gil.

Yes, thanks. I'm so used to issues being closed via commits and I tend to forget to check they have been closed indeed 😊

I agree with your plan.

from gil.