On Friday, 21 March 2014 at 17:03:17 UTC, Vladimir Panteleev
wrote:
Where this is done, it is on purpose. For example, the "invert"
declaration as it appears in the article wouldn't be possible
with the shorthand function template syntax.
Right, I only skimmed over the various aliases. It looks like
only `parallel` does not use such an alias in the article, but as
a higher order algorithm it's perfectly justified to use the
separated style, especially when all the other higher order
algorithms do it.
Yes. I've tried using unsigned coordinates in the past. It was
awful.
My conclusion is that if you ever need to subtract values, you
should use signed types.
What happens if negative values sneak into the code? Sounds
dangerous.
Yeah. A lambda would need to receive x, y, w and h, and we
don't have naryFun in Phobos. (It's there but commented out for
some reason.)
To a small extent, I made some compromises for the first
iteration for the sake of code looking good for the article,
and maybe with the help of feedback improve on that.
Bleh, I hope we can figure out some notion of lambda equality
soon; string lambdas are terrible in so many ways.
For example, a problem I've struggled with is avoiding having
two overloads for almost every function in image.d. I've tried
multiple approaches: default arguments (in the form of *new
Image!COLOR), templates, string mixins, UDAs, pointers, but
they all were rather ugly or impractical. Some related compiler
issues are 8074, 12386, 12425 and 12426 - fixing those might
make some of those approaches more feasible.
Referring to the overload sets with the `target` parameter?
(Looking at the source I also noticed some `isInputRange` checks
are missing; `ElementType` only checks for a `front` property.)
That doesn't work if you need two-way communication. Although
you can pass outer methods as aliases to the inner struct, but
then you have to use crazy tricks to make methods of the inner
struct static in respect to the inner struct but bound to the
outer one via the alias. I've played with this quite a bit for
ae.utils.serialization, but I don't think it fits here. Unless
I'm missing something?
Aye, to be a sane hierarchy it would need to be redesigned so
there are no circular dependencies, which does look rather
non-trivial.
That's what my previous design used. But ultimately, unless
you're dealing with very narrow images, I don't think there
will be a noticeable difference in performance. This design is
more flexible, though (e.g. vjoiner can serve scanlines from
different sources).
Maybe parallelized blitting makes sense, though it would really
require a use case where blit speed is a bottleneck to matter in
the first place.
