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.

Reply via email to