On Saturday, December 22, 2012 00:21:33 Walter Bright wrote: > On 12/21/2012 11:23 PM, Jonathan M Davis wrote: > > But we _want_ that. The fact that inaccessible functions are even > > considered in overload sets is horrible. That's precisely the problem. No > > inaccessible functions should be in overload sets. Otherwise, simply > > adding a private function to a module can break code elsewhere. I don't > > see _any_ benefit in having inaccessible functions be in overload sets. > > It's leaking implementation details outside of the scope that they're in > > and breaking code elsewhere when changes are made. What do you think is > > so desirable about having inaccessible functions in overload sets? > > It's that way in C++ mainly so that it doesn't make the already complex > overloading system even more so. And in 25 years of working with C++, I've > never seen this make anyone's list of horrible things about C++.
C++ doesn't have module-level access modifiers or UFCS, so it's completely unaffected by this. In C++, you can't add functions to classes from the outside, so there's no concern about adding private functions to a class breaking code using that class. And you can't add a private function to a module, because there are neither modules nor private, free functions, so you aren't going to get breakage from adding a private function, because you can't add a private function. Either you add what is effectively a public function (though technically, it has no access modifier at all, since it's not part of a class) and risk breakage that way, or you create a function which is only in the cpp file. In D, on the other hand, you can add private functions to modules, and you don't normally have separate implementation files. So, the situation is completely different. We created this problem by adding modules and making it so that that the functions in them have access levels. We have extra layers of encapsulation which just don't exist in C++, and we made them leaky, because we made it so that the private functions affect overload sets. So, the fac that C++ doesn't get these complaints is pretty much irrelevant. It doesn't have the features which make this a problem. And regardless of whether you get complaints about this in C++, there have been plenty of complaints around here about it in D. Pretty much every time that this issue comes up, people are surprised by the fact that private symbols aren't hidden and pretty much no one wants them to be in overload sets. I think that you're the only one that I've seen post that they thought that the current behavior is a good idea (certainly, anyone who agrees with you is in the minority or is silent on the issue). What we currently have leaks implementation detalis and thus causes code breakage when the implementation is changed. It needs to be fixed. - Jonathan M Davis
