Package functions cannot be abstract?!

[Neia Neutuladh]

On Wed, 30 Jan 2019 17:21:31 +0000, Neia Neutuladh wrote:

> On Wed, 30 Jan 2019 12:28:42 +0000, Benjamin Schaaf wrote:
>> On Wednesday, 30 January 2019 at 04:05:15 UTC, Jonathan Levi wrote:
>>> Do you have a recommendation on how to do what I am trying to do?
>> 
>> So you want a public class that has private abstract methods that you
>> share across private implementations. Why not use an interface?
> 
> The reason you use package instead of protected is to expose the
> function to be called by other functions in different modules in the
> same package.
> 
> It feels to me like D took some design cues here from Java and C++
> without accounting for differences between D's `private` and Java's,
> then rolled those decisions forward into `package`. Virtual dispatch and
> protection should be orthogonal except insofar as the compiler can use
> protection to prove that there are no overrides of a function.

To clarify: it's not a great decision in Java either; you can access 
private members of other classes defined in a mutual scope. (Nested 
classes can access anything their parent classes can access, and a class 
can access anything its nested classes can access.) But Java discourages 
you from writing this kind of code in the first place, while D is much 
more keen on modules with multiple declarations, and those declarations 
expose their private members to each other.

So it would make perfect sense to write something like:

---
module foo;
class A
{
  /*virtual*/ private int stuff() { return 1; }
}
class B : A
{
  override private int stuff() { return 2; }
}
---

But because Java didn't make `private` and `virtual` orthogonal like they 
could and probably should be, D doesn't either. And because of D's module 
system, the problem is much more visible in D.

I didn't realize that C++ allows private virtual functions. With C++, a 
private virtual function is overridable by derived classes, even if they 
aren't friends. This prevents the child classes from calling the function 
despite having defined it. Which is weird.