On Friday, December 21, 2012 17:44:43 Walter Bright wrote: > On 12/21/2012 12:44 AM, Timon Gehr wrote: > > ... modulo the private symbol clash issue. For all I know it is > > deliberate, > > which is embarrassing. Other than obviously breaking modularity, it > > severely restricts the usefulness of symbol disambiguation (which it > > makes necessary when it should not be), because the disambiguating alias > > may introduce more conflicts even if it is private, all over the code > > base. > > The reason it is that way is to avoid having it behave gratuitously > differently than how visibility works within classes and structs.
??? I don't see anything here that would become different between user-defined types and modules. All we're really asking for here is that inaccessible symbols not be put in overload sets. That way, you don't have problems where adding a private function to a module breaks existing code, because it clashes with a public symbol in another module when a third module imports both modules. For instance, right now, private aliases are useless, because they're pretty much exactly the same as public aliases, because they introduce name clashes. There is _zero_ value as far as I can see in having private symbols in one module affect the symbols in another. private symbols should be implementation details and not affect the compilation of other modules. I would expect it to be exactly the same with private member functions and UFCS. So, if a new private member function is added to a class or struct, and code was using a free function with UFCS with that type, the code wouldn't change behavior or otherwise break because of the conflicting function which was added. The private function _wouldn't_ conflict, because it's private. So, I don't see anything different here about how private would be handled between free functions and structs/classes. It seems to me like it would be exactly the same rather than gratuitously different. And even if it _were_ somehow different, the current behavior makes it frustratingly easy to break code when simply changing the names of the private functions of a module - functions which are supposed to be implementation detalis, and I would think that the difference would be well worth it. Given how much you abhor breaking users' code, putting inaccessible symbols in overload sets seems like a rather odd choice to me. I understand how it stems from C++, but C++ doesn't have module-level access modifiers, and it doesn't have UFCS. The result in D is far more fragile. It makes it way too easy to break other people's code. - Jonathan M Davis