Required Reading: "How Non-Member Functions Improve Encapsulation"

[Jonathan M Davis]

On Monday, October 30, 2017 22:10:26 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 10/30/17 9:59 PM, codephantom wrote:
> > On Tuesday, 31 October 2017 at 01:47:39 UTC, Steven Schveighoffer wrote:
> >> I once thought as you do (though not as the syntax you propose). I now
> >> embrace UFCS fully, it's awesome.
> >>
> >> -Steve
> >
> > Yeah. I do like UFCS ... I was convinved after seeing Ali talk about it:
> >
> > https://www.youtube.com/watch?v=vYEKEIpM2zo
> >
> > What a great ambassador for D he is!
> >
> > But being able to differentiate whether a line of code is calling a
> > method of an object, or a free function... that's the area that concerns
> > me.
> >
> > I'm lazy.. I would like such code to be more explicit....and not leave
> > it to me to work out what's going on.
>
> Except... then you can't use generic code with UFCS.
>
> For example, arrays couldn't be ranges, because you can't just do
> arr.front, you'd have to do arr.\front.

Honestly, I think that generic code is the _only_ technical advantage of
UFCS - everything else is just subjective preference about syntax. But the
fact that you can call a function without worrying about whether it's a
member function or a free function is huge for generic code - especially if
you want a type to be able to provide an optimized version of a function
(e.g. implementing its own find if it can implement find more efficiently
than the default linear implementation). Without UFCS, it gets way more
complicated to be able to call a function that might be a member function or
a free function, and in likelihood, the result would be that code would
always use one or the other rather than supporting both.

- Jonathan M Davis