On Monday, December 24, 2012 06:20:04 Martin Nowak wrote: > On 12/23/12 03:35, Walter Bright wrote: > > On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote: > >> I think this is a fallacious argument because it concludes that apples > >> should be > >> peeled because oranges should. > > > > Given, in C++: > > > > struct S > > { > > > > public: > > void foo(int); > > > > private: > > void foo(float); > > > > } > > > > void bar() > > { > > > > S s; > > s.foo(1.0f); > > > > } > > > This is an error in C++: > Yeah, and it must stay one for D overload sets too. > In my pull request I always used the most accessible protection for the > visibility of an overload set without removing the access check after > overload resolution. > > http://dlang.org/hijack.html > https://github.com/D-Programming-Language/dmd/pull/739
How is it hijacking if one of the overloads is private? It wouldn't even end up in the documentation. No one else would even know that the function existed unless they read the source code. I see _zero_ problem with making this use the public version, and it won't break any code in doing so, because it'll make _more_ code compile, not less. Also, making the compiler take the most accessible function is _wrong_. In the example above, if bar were in the same module as S, it would then call the public foo, whereas if it were in another module, you'd get an error (assuming that inaccessible functions are still kept in overload sets). If multiple overloads of a function are accessible and they conflict, then they should conflict. It's definitely hijacking if you just grab the most accessible one. So, unless I've misunderstood what you're suggesting, you're suggesting that the above code should continue to be broken out of fear of there being a hijacking issue (though I don't see how there could be one) but you've suggested _adding_ a hijacking issue by simply grabbing the most accessible function. That sounds like a really bad idea. I'd propose that all accessible functions be put into overload sets, that no inaccessible functions be put into any overload sets, and that accessibility not have anything to do with overloading beyond that (so which function in the overload sets wins has _nothing_ to do with accessibility). And that's what most of us have been asking for. I find your stance to be very confusing. - Jonathan M Davis