| Dear Bjarne, Please, please, please reconsider not enabling x.f(y) resolve to f(x, y). You must explain to the detractors that they must reconsider allowing x.f(y) to resolve to f(x, y). This is not a selling out to OO, but in fact the opposite! Allowing x.f(y) to resolve as such enables us to finally get _away_ from OOP by using an alternative style called 'Data Abstraction Style'. I have written up an example of this style here - https://github.com/bryanedds/das I have also written an entire C++ core library in said style here - https://github.com/bryanedds/ax In PLT terms, data abstraction is the dual of OOP. In fact, I use it significantly in F# as a way to do pure functional programming where others just fall back into OOP - https://vimeo.com/128464151 Data Abstraction Style with resolution of free-standing functions to dot syntax gives us the best of both worlds - the increased modularity and extensibility of free-standing functions as well as the nice tooling and API explore-abily of the dot intellisense. Additionally, there are precedence for this functional is less OOP-y language like D and Rust -
http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327...
https://github.com/rust-lang/rust/issues/16293 Finally, this syntax is important just to allow extension methods without a more specialized syntax that won't likely appear anyways. Please pass along this information to the people holding out on allowing x.f(y) resolve to f(x, y) - it is not selling out to OOP - it's an elegant path to finally move beyond it. People must be made to understand this before making their final decision! |