On Sunday, 21 February 2016 at 00:52:13 UTC, bitwise wrote:
On Saturday, 13 February 2016 at 10:27:59 UTC, Daniel N wrote:
"Abstract
This is the proposed wording for a unified call syntax based
on the idea that f(x,y) can invoke a member function, x.f(y),
if there are no f(x,y). The inverse transformation, from
x.f(y) to f(x,y) is not proposed."
They were considering 6 alternatives and chose the worst...
https://isocpp.org/files/papers/P0251R0.pdf
Am I crazy, or is this paper proposing the exact opposite of
what would be needed to do chaning of ranges or extension
methods?
I don't get how it would be useful at all to type f(x, y) and
have the compiler call x.f(y) for me. Why would I ever not want
to just use member invocation syntax?
Because UFCS is not about chaining function calls. It's about
being able to call a function without worrying about whether it's
a free function or a member function. Without some form of UFCS,
it really doesn't work well for generic code to be able to call a
function when some types define the function and others work with
a free function with the same name, because the syntax to call
them is different, meaning that the same code won't work with
both types. Regardless of whether UFCS is foo(x, y) or x.foo(y),
it allows for a _universal_ way to call a function (hence the
name Universal Function Call Syntax). That's the whole point.
Much as many folks love how D's version of UFCS makes it really
easy to chain function calls, it's really not the main goal of
UFCS. It's just a nice side effect of how we've done it. C++ will
still get all of the benefits for generic code the way that
they're doing it. So, they'll get the intended benefit of UFCS.
They just won't get the side benefits that many folks like about
the syntax that D chose.
- Jonathan M Davis
