On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali Çehreli via Digitalmars-d-learn wrote: > On 7/11/25 11:36 PM, Bienlein wrote: > > > Unhappily class MessageBox is private and therefore cannot be reused. > > Ah! :) That's one more data point against 'private', that little feature > that helps with nothing. I don't know what language invented it but I > wouldn't be surprised if it came to D from C++. > > The only thing 'private' achieves is this: You don't want your users to > be disappointed when they go out of their way to use features that they > are advised not to use, and those features behave differently in the > future. Really? That never happens. Well, if it indeed happened ever, > the user went out of their way to be surprised, didn't they? > > Meanwhile, engineers like you suffer because of 'private'. I pick > engineering over 'private' any day.
Whereas I think that using private makes perfect sense when you want something to be an implementation detail. Exposing it means that you have to deal with someone using it, you have to design its API for public use, and you can't change it without breaking code. If anything, making something public when it doesn't need to be makes it harder to maintain and refactor that code. As far as public libraries go, any time that any symbol is public, someone is going to use it, and you're stuck with its design. And when the code is open source, if someone wants to use it, they can always just copy it into their own code and do whatever they want with it without creating any additional burden for the maintainers of the library that the code was taken from. The situation is somewhat different when you're dealing with proprietary code, because then you're not usually dealing with external users, and you can change things more freely. But when you make a symbol public in a library which is publicly available, you're essentially creating a contract with your users and limiting the changes that you can make to the those symbols. So, there's a real cost to making a symbol public, and I'm 100% in the camp that symbols should not be public if they don't need to be. Obviously, there are cases where designing an API from pieces that are public can be valuable, but IMHO, the mere fact that something is used to build something that is part of a public API is not in and of itself enough to merit that building block being public. Public symbols need to be purposefully designed as public symbols, whereas private symbols are implementation details which can be changed as necessary so long as those changes don't break the functionality provided by the public symbols. So, from the standpoint of code maintenance, there can be real value in keeping symbols private. - Jonathan M Davis
