About Go, D module naming

[Jonathan M Davis]

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