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
