On Mon, Oct 4, 2010 at 1:24 PM, Sergey <sms...@gmail.com> wrote: > Hi Daniel, > > I didn't by no means want to say that D is unusable or unenjoyable because > of this still-persisting defect. I would say, D2 is too young to be good > rather than bad. Just.. I considered D to be more mature than it currently > is. Well, at any rate we need to wait some time. > > You say: > "What's the big deal, just don't access private members (it's not like you > have to) and your code will still work when the bug is fixed.". Ok, it's > clear. But thinking in this way it's also fine to make all private class > members public (in C++ for example) and just not to call them from outside > the class. Nothing will be broken.
No, it's not the same. 1. making them private indicates that you don't want them to be used outside of the module. Even if this is not currently enforced, your intention is clear. 2. As mentioned before, this *is* clearly a bug that should be fixed and I guess it will be fixed (shouldn't be that hard). And when it's fixed, code that "uses" this bug will break - so it's not the same as just making it public and rely on it not being used anyway. I'm just saying that this bug doesn't make D less usable. When writing code you usually don't try accessing private members from the outside anyway, because you don't expect that to work. And it seems like you're the first one to discover the bug so apparently nobody tried that before (or, if he did, didn't file a bug report). IMHO there are two kinds of bugs: 1. Something you expect to work (and that should, by specification, work) doesn't work. That's the bad kind and should be fixed as soon as possible. 2. Something you don't expected to work (and shouldn't, by specification) *does* work. That's the kind we're having here and IMHO it's not as bad, because it doesn't impair the usefulness of the tool (in this case the D compiler). Of course it should be fixed anyway before people consider it a feature and use it, but is probably has a lower priority.
