Private visible?

[Dave]

Jari-Matti Mäkelä wrote:
> Dave wrote:
>> Dave wrote:
>>> Lars Ivar Igesund wrote:
>>>> Dave wrote:
>>>>
>>>>> Lars Ivar Igesund wrote:
>>>>>  > Lucas Goss wrote:
>>>>>  >
>>>>>  >> Was there ever any resolve as to private being visible? I know
>>>>> Walter
>>>>>  >> said he saw the value of private by default, but what about private
>>>>>  >> being visible? It just seems to have dropped off the radar and I
>>>>> don't
>>>>>  >> know if thats good or bad.
>>>>>  >>
>>>>>  >> Lucas
>>>>>  >
>>>>>  > Did you mean accessible? Anyway, see Bruno's post, although I'm
>>>>> quite
>>>>> sure
>>>>>  > it won't be forgotten by some of us ;)
>>>>>  >
>>>>>
>>>>> Here's my take - feel free to correct:
>>>>>
>>>>> - accessible: the symbol can be used (accessed). Must be visible as
>>>>> well
>>>>> for the lookup (I realize this is obvious).
>>>> Yes, that would be the sane thing, but one of the privacy problems in
>>>> D, is
>>>> that it has been possible to access symbols by using the FQN, even
>>>> though
>>>> it really isn't visible (declared to be private). As it is, I see no
>>>> reason
>>>> to differ between visible and accessible, IMO they're two sides of
>>>> the same
>>>> coin, or should be.
>>>>
>>> See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39754
>> A little too terse, I was... I tend to agree that they should be two
>> sides of the same coin but the gist of it is that they aren't in D
>> because they aren't in C++ for (possibly obscure) reasons that might not
>> apply to D.
>>
>> Everyone seems to agree that 'private' should not be accessible and the
>> current behavior is a bug.
> 
> IMO 'private' works quite well now. The only problem is that there's no
> access control when using FQN's. I haven't yet tested all the special
> cases like inner classes, but overall it seems to be better now in 0.162.
> 
>> What we're all wondering is if 'private' can
>> also mean 'invisible' because that seems to be more intuitive. Than you
>> don't have that extra level of complexity for lookup resolution and
>> things like error messages describing a private interface.
> 
> IMO more compiler logic here makes programmer more productive. I find
> this situation analogous to includes in C/C++ vs. imports in D. C/C++ is
> lacking a lot of great functionality there. I'm not that sure if it's
> that much slower to handle both levels of accessibility separately, but
> I can surely see the benefits arising from better compiler error messages.
> 
> AFAICS the only argument against current behavior is that people think
> it's somehow "easier" to implement a compiler that does only visibility
> checks. Of course it's a bit annoying to see that this "bug" has been
> open for many years now, but Walter has been long busy working on the
> cool new features that have added much to the value of D. But now that D
> is reaching stable, maybe it's finally time to find a solution to these.
> IMO fixing the FQN's would be enough. Walter, could it be possible to
> implement these checks as a special case for FQN's if it's too difficult
> to form some general rules for the order of phases (access control, name
> lookup)?
> 

Here's an example that doesn't require FQN to expose the bug:

module foo;
void bar(int i)
{
   printf("bar(int)\n");
}
private void bar(char[] str)
{
   printf("bar(char[]): %s\n",cast(char*)str);
}

module main;
import foo;
void main()
{
   bar("test");
}

If you comment bar(int) out then it issues the correct compiler message 
otherwise it happily prints what you'd expect if bar(char[]) was not 
private.

- Dave