On Saturday, 3 September 2016 at 09:31:59 UTC, Manu wrote:
std.algorithm is extremely simple, it doesn't do anything
except raw algorithm-ey stuff. It doesn't attempt to invoke
functionality on the data it's working on.
Right now I'm working on image processing. There are lots of
image
data types, and they all have things like interpolation and
blending
functions. Write an image processing algorithm that calls out
to lerp
or blend, and you'll run into these problems instantly.
I was writing some audio software some time back, again, trying
to use
stream processing extensively because it's a perfect match for
that
workload, but same problem!
Write an algorithm that does _work_, rather than does algorithm
logic, and you can't miss this problem. You need to call
associated functions to do work.
I have had problems with not having C++ style ADL before, but in
the end I'm much happier without it.
At the risk of repeating previous posts, Is it specifically this?
auto someAlgorithm(T0, T1)(T0 arg0, T1 arg1)
{
// do some work
blend(arg0, arg1);
// more work
}
And you want some way for the author of the types being passed in
to define an overload of blend somewhere else that that
someAlgorithm is not explicitly aware of? What possible lookup
rules would you want to make that work? I can think of a lot of
different schemes depending on what you want/need for the
situation. D goes the simple, conservative route by default and
just looks in progressively wider scopes, which is
uncontroversial and good enough in most cases. More complicated
cases can be done with various other methods, all of which will
then necessarily involve some explicit choice (e.g. passing the
scope, passing the function, importing scope etc...) in order to
know which one you're using. This seems to me to be a good thing?
P.s. your ordinary programmer argument: can you imagine that same
ordinary programmer understanding how to properly use and avoid
abusing C++ lookup rules?
