A bit of background for the unified C++ call proposal
1–10 of 46 posts
Re: A bit of background for the unified C++ call proposal
#2I'm curious, would C++ ever consider categories like in ObjC? I.e. class extensions that unlike inheritance don't change the type.
It kind of gets close with the unified call: if you have a call f(x,y) then either x.f(y) is matched or some f(x,y) that may be defined elsewhere. But still not the same as the ability to define a new x.g(y) for an existing class.
(Edit: I can't even start to think what implications this will have on templates. They will probably become even more impenetrable.)
Re: A bit of background for the unified C++ call proposal
#3I like the proposal. It took me 20 years to master the 10% of C++ I understand and use. I wonder how new programmers will be able to pick up this language.
Re: A bit of background for the unified C++ call proposal
#4I'm curious, would C++ ever consider categories like in ObjC? I.e. class extensions that unlike inheritance don't change the type. It kind of gets close with the unified call: if you have a call f(x,y) then either x.f(y) is matched or some f(x,y) that may be defined elsewhere. But still not the same as the ability to define a new x.g(y) for an existing class. (Edit: I can't even start to think what implications this…
Their proposal to allow x.f(y) to match a free function f(x, y) would obviate the need for anything like categories. I'm puzzled and saddened that this part of the proposal didn't go through.
Re: A bit of background for the unified C++ call proposal
#5>> I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces.
I think the concern is that a class "owns" its methods either directly or through inheritance. Therefor, the interface is expressed by this namespace and it can't be "invaded" or modified. From that perspective, having f(x,y) being callable as x.f(y) would be a violation of your interface.
But... the dot syntax does not make an interface, and neither does it make "object oriented programming". It implies that "f" is a specialized function for somehow applying "y" to "x".
If you have a generic "f" that can be compiled to a specialized "f" for your type... you are just adding composability to your language. That's a good thing! Calling "f" as x.f(y) in this case makes a lot of sense. It's just another specialized function for applying "y" to "x".
Re: A bit of background for the unified C++ call proposal
#6I'm reminded of the language Nim, where x.f(y) and f(x,y) are both the same thing with different syntactic sugar.
Re: A bit of background for the unified C++ call proposal
#7I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c.
I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascript gets this a right by having `function f` largely equivalent to `var f = function`.
I'm impressed that C++ continues to evolve 37 years later. It's a stark contrast to, say, the Go 1 Compatibility Promise.
Re: A bit of background for the unified C++ call proposal
#8Ahh I'm sad. I really wanted x.f(y) to find f(x,y). Then std::algorithm and ranges would combine to make sweet linq-like filter/map operations.
Re: A bit of background for the unified C++ call proposal
#9I'm reminded of the language Nim, where x.f(y) and f(x,y) are both the same thing with different syntactic sugar.
I thought of Nim, too.
To add to your comment, Nim's "Unified Call Syntax" recognises as the same len(x), x.len() and also x.len (this is similar to Ruby's poetry mode, if I am not mistaken). I find it cool, but I can also imagine reasons for which the latter would not be appreciated by the C++ community.
Re: A bit of background for the unified C++ call proposal
#10Ahh I'm sad. I really wanted x.f(y) to find f(x,y). Then std::algorithm and ranges would combine to make sweet linq-like filter/map operations.
Yeah, I'm really disappointed. It's one of my favorite things about D. I guess f(x,y) finding x.f(y) is better than nothing but the other way around makes for some beautifully composable code.