On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:
My opinion is that it's not worth a new keyword and time for
implementing. In the same manner you could ask for removing
friend concept from C++ as a bad concept. I don't answer the
question whether this concept is good or bad - just give an
example. The difference is that you can just go without friend
at all, and module-level private is forced.
Try telling Bjarne Stroustrup that ;-)
I still believe (like Bjarne) that friend in c++ is the right
way, for those of us that believe that the defined interface is
how you obtain your interface. Friend is a part of the defined
interface.
Within implict friends, the interface is pretty blurry - but
that's another story, and as I said, my change would not affect
those who thing facebook like friendship in modules is a good
approach - I think we can have it both ways really.
Although I don't suggest adding friend to D, I do like option of
having static enforcement of the defined interface, as a
possibilty the programmer can opt-in to.
At the moment, that can only be done by the one-class-per-module
hack.
Which means, for OOP programmers, the module in D(i.e. the file),
becomes nothing more than a pseudo class. This will make some
(perhaps many) OOP programmers wonder why they should bother
coming to D at all. It certainly is a question I keep asking
myself, over and over - at some point I make a conclusion.
The capacity to have more than one class in a module, and be able
to obtain static enforcement of the use of the defined interface
(by restoring private to its rightful status - as an option -
perhaps by the using the sealed attribute on a class), can only
have a positive effect, in my view. I cannot see how it would
negatively affect anyone. It's purely opt-in, not opt-out.
And yes, it's a small change, but has potential for great impact
(presumably, only positive impact) - although that's why I want
to have this discussion - to see how others think too.
