We need an internal keyword.

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sun Oct 21 19:53:35 UTC 2018


On Saturday, October 20, 2018 9:17:23 PM MDT 12345swordy via Digitalmars-d 
wrote:
> So that classes can share some of their variables but not others
> in a module.
>
> IE.
>
> class A
> {
> internal int A; //This is shared in the module
> private int B; // But not this.
> }
>
> No need to reintroduce the "Friend" feature from cpp.

Well, if you feel strongly enough about it, you can always create a DIP to
try to change things, but I think that I can quite safely say that you have
pretty much no chance of it getting accepted. Walter has been quite clear on
this topic when it has been discussed previously (and there was a major
discussion on it not very long ago). It is very much on purpose that access
is controlled at the module level, and if your module is large enough that
it is actually causing problems for a class or struct to not be able to
disallow access of its members to other symbols in the module, then the
module is too large, and the class should be put in a separate module. We
already have full control of who can access the members of a class or struct
by controlling which module or package its in and what else is in that
module or package with it. If you want greater control without splitting up
your modules more (at least as far as importing goes), you can always take
advantage of public imports to split the code itself into more modules while
making it possible to get all of the symbols with a single import statement.

Certainly, if we had internal or friend or other mechanisms for more
fine-grained control without doing it at the module-level, it would
eliminate the need to put code into separate modules in some cases, but it
would also complicate the language, and what we have works quite well in
general.

If you don't like the fact that member access is done at the module level,
then I'm sorry, but overall, this really seems to be a philosphical
complaint and not a practical one, and Walter has made his stance on it very
clear. Based on what he's said previously, you would need very strong,
practical arguments for why it's causing actual bugs in programs and why the
current approach is not cutting it to stand any chance of convincing Walter.
And honestly, I have never seen anyone come up with an argument that was
particularly good in that regard. It mostly seems to come down to folks
simply objecting to the idea that anything inside a module would have access
to a class' private members rather than that it's actually caused bugs. In
practice, it's usually either actually useful, or it doesn't matter.

Either way, simply making post stating that you think that we should have
the feature isn't going to get you anywhere. If you want it, you'll need to
find a way to convince Walter.

- Jonathan M Davis





More information about the Digitalmars-d mailing list