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.

Reply via email to