Le 02/04/2012 22:59, Simen Kjærås a écrit :
> On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix <deadalnix@gmail.com> wrote:
>
>>> Now, there are a number of people very unhappy about this state of
>>> affairs and
>>> want private to hide symbols as well (personally, I think that the
>>> fact that
>>> it makes private aliases effectively useless is reason enough to
>>> seriously
>>> reconsider the current behavior), but I don't know if there's any
>>> real chance
>>> of convincing Walter or not.
>>>
>>
>> This would be a huge mistake. For instance, private method are
>> sometime meant to be overridden in subclasses, which is impossible if
>> symbol is inaccessible.
>>
>> NVI for instance would be impossible in such a situation.
>
> NVI is perfectly possible with protected.

You'll loose the ability to define a function, without being able to call it.

It is something you want if function have to be called by pair for example (using protected here would introduce temporal coupling). It make even more sense if you consider combining it with contract programing.

Le 03/04/2012 00:00, Timon Gehr a écrit :
>
> Making private symbols invisible to other modules or at least excluding
> them from symbol clashes is necessary. The current behaviour is not
> useful or desirable in any way.
>

This smells like religious coding to me.

>> NVI is perfectly possible with protected.
>
> Exactly. Furthermore, private implies final anyway.

Which is complete bullshit. Even in a module you may want to override a method.

On 04/03/2012 08:27 AM, deadalnix wrote:
> Le 03/04/2012 00:00, Timon Gehr a écrit :
>>
>> Making private symbols invisible to other modules or at least excluding
>> them from symbol clashes is necessary. The current behaviour is not
>> useful or desirable in any way.
>>
>
> This smells like religious coding to me.
>

Nope.

>>> NVI is perfectly possible with protected.
>>
>> Exactly. Furthermore, private implies final anyway.
>
> Which is complete bullshit.

It is a questionable design decision. It might be reasonable to allow overriding private members, but that would mess with the vtable layout.

> Even in a module you may want to override a
> method.

... which is excluded from the public interface. There are better ways to hide a method than to mark it private in an implementation class.

On Mon, 02 Apr 2012 08:05:09 -0500, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> On 02.04.2012 16:04, Adam D. Ruppe wrote:
>> On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
>>> It's all nice and well, but I believe part of the reason of say
>>> private protection is that user is never ever able to see(!) it. Thus
>>> it user can't depend on private members being there, which is a good
>>> thing.
>>
>> That's not the way it is right now in D: if you use the
>> reflection traits, you can see and access private members.
>>
>> Worse yet, the way it is now, there's no way to tell
>> they are marked private when using reflection!
>>
>
> Awful.

As someone who has implemented a runtime reflection library in D, it is entirely possible to detect whether a function is marked private/protected or not using __traits today. In fact, IIRC, there is no way to break protection using __traits; what the op is referring to is .tupleof, which can be used to break protections of fields if you have the full source code.

On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
> As someone who has implemented a runtime reflection library in D, it is entirely possible to detect whether a function is marked private/protected or not using __traits today.

How did you do it? __traits(compiles) is the best I could
find, and that breaks down if you are friends (easy to
happen with mixins, even if the code is in a separate file)
and is kinda fragile in general since it will swallow unrelated
errors too.

On 4/3/12, Adam D. Ruppe <destructionator@gmail.com> wrote:
> is kinda fragile in general since it will swallow unrelated errors too.

That's an issue I've noticed recently. msgpack-d allows me to define a custom serialization routine in my structs/classes, but it has to be a template. Then msgpack tries to instantiate it via __traits(compiles), and if it doesn't work it just skips calling the routine alltogether. So if I have invalid code in my template I'll never know because the external library just swallows the errors.

It took me a long time to figure out why my routine wasn't called. I really wish DMD would semantically check templates at least partially even if they're never instantiated.

On Tue, 03 Apr 2012 08:30:25 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
>> As someone who has implemented a runtime reflection library in
>> D, it is entirely possible to detect whether a function is
>> marked private/protected or not using __traits today.
>
> How did you do it? __traits(compiles) is the best I could
> find, and that breaks down if you are friends (easy to
> happen with mixins, even if the code is in a separate file)
> and is kinda fragile in general since it will swallow unrelated
> errors too.

I did it by having all the inspection routines in a private template inside a struct in another module.

On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
> Le 02/04/2012 22:59, Simen Kjærås a écrit :
> > On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix <deadalnix@gmail.com> wrote:
> >>> Now, there are a number of people very unhappy about this state of
> >>> affairs and
> >>> want private to hide symbols as well (personally, I think that the
> >>> fact that
> >>> it makes private aliases effectively useless is reason enough to
> >>> seriously
> >>> reconsider the current behavior), but I don't know if there's any
> >>> real chance
> >>> of convincing Walter or not.
> >> 
> >> This would be a huge mistake. For instance, private method are sometime meant to be overridden in subclasses, which is impossible if symbol is inaccessible.
> >> 
> >> NVI for instance would be impossible in such a situation.
> > 
> > NVI is perfectly possible with protected.
> 
> You'll loose the ability to define a function, without being able to call it.

Except that that doesn't even actually work as discussed in this thread:

http://www.digitalmars.com/d/archives/digitalmars/D/Re_Module- level_accessibility_118209.html#N118329

The derived class overrode the function, so it can call it. It may not be able to call the base class version, but it can call its own.

Sure, NVI is great, but it works just as well with protected. private doesn't actually prevent you from calling the function in the derived class, and even if it did, it's _not_ worth the cost of making private virtual by default. And as D lets the compiler control virtuality, unlike C++, it doesn't make any sense to make it so that the programmer can specifically make a private function virtual to work with NVI. So, it just makes more sense to use protected to do NVI.

Now, it may be different with interfaces. TDPL specifically talks about using private for NVI with _interfaces_, not classes. Doing that sort of thing with interfaces requires special treatment already, and it doesn't affect efficiency like making private always virtual would, so that should be okay. In the general case though, it's just far better to use protected to do NVI with classes and let private be non-virtual and therefore efficient by default rather than inefficient by default.

- Jonathan M Davis

Le 04/04/2012 04:48, Jonathan M Davis a écrit :
> On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
>> Le 02/04/2012 22:59, Simen Kjærås a écrit :
>>> On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix<deadalnix@gmail.com>  wrote:
>>>>> Now, there are a number of people very unhappy about this state of
>>>>> affairs and
>>>>> want private to hide symbols as well (personally, I think that the
>>>>> fact that
>>>>> it makes private aliases effectively useless is reason enough to
>>>>> seriously
>>>>> reconsider the current behavior), but I don't know if there's any
>>>>> real chance
>>>>> of convincing Walter or not.
>>>>
>>>> This would be a huge mistake. For instance, private method are
>>>> sometime meant to be overridden in subclasses, which is impossible if
>>>> symbol is inaccessible.
>>>>
>>>> NVI for instance would be impossible in such a situation.
>>>
>>> NVI is perfectly possible with protected.
>>
>> You'll loose the ability to define a function, without being able to
>> call it.
>
> Except that that doesn't even actually work as discussed in this thread:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Re_Module-
> level_accessibility_118209.html#N118329
>
> The derived class overrode the function, so it can call it. It may not be able
> to call the base class version, but it can call its own.
>

It shouldn't be able to do so. This should be reserved for protected methods.

> Sure, NVI is great, but it works just as well with protected. private doesn't
> actually prevent you from calling the function in the derived class, and even
> if it did, it's _not_ worth the cost of making private virtual by default. And
> as D lets the compiler control virtuality, unlike C++, it doesn't make any
> sense to make it so that the programmer can specifically make a private
> function virtual to work with NVI. So, it just makes more sense to use
> protected to do NVI.
>

Visibility and virtuality are 2 completely orthogonal concerns. Mixing both is a bad design decision, what ever is the rational behind it. Separation of concerns is more important.

Plus, this isn't a real issue, because the final keyword exists.

At the end, for performance concerns, what we want is that the compiler or the linker were able to finalize methods that have no override, not some dirty trick that break larger more important conception principles.

> Now, it may be different with interfaces. TDPL specifically talks about using
> private for NVI with _interfaces_, not classes. Doing that sort of thing with
> interfaces requires special treatment already, and it doesn't affect efficiency
> like making private always virtual would, so that should be okay. In the
> general case though, it's just far better to use protected to do NVI with
> classes and let private be non-virtual and therefore efficient by default rather
> than inefficient by default.
>
> - Jonathan M Davis

It is not that simple. First, it introduce an inconsistency between interfaces and classes for no real reasons. The only difference between classes and interfaces should be that interface cannot have member data, and you can inherit from multiple interfaces. Interface have been created to solve the problems that exists for multiple inheritance, and that is enough to solve that problem. Everything else is, again, lack of separation of concerns.

Second, the same method can be declared in the base class and in an interface, and in this case, we cause compile error for nothing.

Le 04/04/2012 03:04, Robert Jacques a écrit :
> On Tue, 03 Apr 2012 08:30:25 -0500, Adam D. Ruppe
> <destructionator@gmail.com> wrote:
>
>> On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
>>> As someone who has implemented a runtime reflection library in
>>> D, it is entirely possible to detect whether a function is
>>> marked private/protected or not using __traits today.
>>
>> How did you do it? __traits(compiles) is the best I could
>> find, and that breaks down if you are friends (easy to
>> happen with mixins, even if the code is in a separate file)
>> and is kinda fragile in general since it will swallow unrelated
>> errors too.
>
> I did it by having all the inspection routines in a private template
> inside a struct in another module.

That is neat.

It should be provided as lib by std.traits . And no need for language changes.