Private visible?

[Jari-Matti Mäkelä]

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)?

-- 
Jari-Matti