https://issues.dlang.org/show_bug.cgi?id=4542

Xiao Di Guan <xdg@puxlit.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdg@puxlit.net

--

https://issues.dlang.org/show_bug.cgi?id=4542

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |bootcamp

--

https://issues.dlang.org/show_bug.cgi?id=4542

Simon Na. <eiderdaus@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |link-failure
                 CC|                            |eiderdaus@gmail.com

--- Comment #16 from Simon Na. <eiderdaus@gmail.com> ---
This bug is still in dmd 2.071.2 and 2.072.

I ran into this today, here's my reduced case:

    interface IA {
        package void f();
    }
    void main() {
        IA a;
        a.f();
    }

Nothing new, but I'd like to nudge for resolution. :-) I dustmited my project due to this bug. The linker error didn't help me.

If this is hard to fix, then maybe error out at compile-time as a hack?

-- Simon

--

https://issues.dlang.org/show_bug.cgi?id=4542

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #17 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Simon Naarmann from comment #16)
> This bug is still in dmd 2.071.2 and 2.072.
> 
> I ran into this today, here's my reduced case:
> 
>     interface IA {
>         package void f();
>     }
>     void main() {
>         IA a;
>         a.f();
>     }
> 
> Nothing new, but I'd like to nudge for resolution. :-) I dustmited my project due to this bug. The linker error didn't help me.
> 
> If this is hard to fix, then maybe error out at compile-time as a hack?
> 
> -- Simon

I don't understand what you expect to happen in this case. You are calling f which does not have a body.

--

https://issues.dlang.org/show_bug.cgi?id=4542

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #18 from RazvanN <razvan.nitu1305@gmail.com> ---
The spec seems to be clear about this [1]:

"""
The following are not virtual:

- Struct and union member functions
- final member functions
- static member functions
- Member functions which are private or package
- Member template functions
"""

So it seems that TDPL is wrong in this aspect.

I'm going to close this as per the arguments of Jonathan.

[1] https://dlang.org/spec/function.html#virtual-functions

--

https://issues.dlang.org/show_bug.cgi?id=4542

--- Comment #19 from Simon Naarmann <eiderdaus@gmail.com> ---
(In reply to RazvanN from comment #17)
> (In reply to Simon Naarmann from comment #16)
> >     interface IA {
> >         package void f();
> >     }
> >     void main() {
> >         IA a;
> >         a.f();
> >     }
> 
> I don't understand what you expect to happen in this case. You are calling f which does not have a body.

Indeed, if I don't inherit from IA, getting a linker error here is correct in this small example.

My best guess of why I posted that reply 6 years ago: It was a faulty reduction of the original bug, but I mistook it for a correct reduction. I dustmited for the linker error and didn't pay attention to whether the reduced linker error arose with or without a class that tried to implement the private/package virtual function.

I agree to treat this as a mistake in TDPL and to forbid overriding private/package methods, as the spec says. Nowadays, OP's example also produces a proper compiler error, much better than the original linker error:

    tdpl_private_virtual.d(18): Error: function
`tdpl_private_virtual.CardBoardBox.transmogrify` `private` method is not
virtual and cannot override
    tdpl_private_virtual.d(23): Error: function
`tdpl_private_virtual.CardBoardBox.untransmogrify` `private` method is not
virtual and cannot override

With this good error already in place, I'm happy with the resolution as wontfix.

--