Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: But the argument that it cannot cause a problem, is already shown to be wrong. So it is good, that unit tests helped you to find how language is designed! Good feature
Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: But the argument that it cannot cause a problem, is already shown to be wrong. D official is unwilling to `solve` the problem, `stubbornness` has been seen!
Re: Dlang mtg at Red Robin in Overlake 7pm tonight
On Wednesday, 24 January 2024 at 20:49:51 UTC, Walter Bright wrote: be there or be square! PhobosV3 is on the menu!
Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: ... but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. But the argument that it cannot cause a problem, is already shown to be wrong. That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people. Let me put it another way. I'm not against class private. I'm not against string interpolation. I don't care about class private. I don't care about string interpolation. One will soon be in the language, and one will not. I can only assume lack of string interpolation was causing pain to more users, than a lack of class private, therefore it got implemented first. Jordan
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: ... but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. - Jonathan M Davis I don't agree. The first time I used the D language, I discovered a 'problem'. That is, my unittest inadvertently accessed a private member of a class, instead of using the public interface of the class. Now the problem of course was me, the programmer (at least one could argue that). But to me, the problem was the language, for not having a feature that could have avoided this problem in the first place. Now, if I want to use D to program, I have to ensure I don't make the same mistake again, by putting my unittest into there own source files (since the compiler cannot warn me, since the language has no feature to make my intent explicit to it). That problem has not gone away, and nor can it, without splitting up everything it own source file. Whether it makes sense to change it now, is a separate argument (and not really one I want to get into, since the arguments against it are always just fluff, and not worthy of my attention). But the argument that it cannot cause a problem, is already shown to be wrong.
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 22:59:17 UTC, Walter Bright wrote: C++ private isn't private, const isn't constant, and one can throw from nothrow functions. TIL C++ is worse than anticipated.
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:01:54 UTC, Walter Bright wrote: On 1/21/2024 3:51 AM, zjh wrote: When you need `friend`, You can put them all in one module. Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home. D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class. This encourages a different use of modules than C++ "toss code randomly into different source files." These are redherring arguments against a robust principle of OOP. A private attribute within a class (visible only to that class) does not mean people can now go and 'toss code randomly into source files. Nor should it be compared to people wanting 'non-constant const, impure pure, and GC allocating @nogc.' Nor would it require D adopting the C++ notion of friends. (all source in a D module is already the D like friend feature anyway, it just implicit). Nor should it be classified as a 'bad' feature because of maintenance costs. Nor is it an argument that D move away from module level privacy. These are all redherring arguments. There doesn't seem to be any real technical reason as to why D should not allow that option. Swift has done this successfully (for example). There are only ever redherring arguments put forward, along with the usual 'we don't do it that way in D' argument. I'm not here to argue for the feature anyway. But given the importance of class-private in OOP, I'd just like to see much better thoughtout arguments against it. (i.e technical/engineering arguments, not the fluff that always accompanies this topic. Putting everything into there own source files, and this includes unittests of course (since they too can end up inadvertingly testing the wrong part of a class), is a solution - but a solution for some, but not others. Anyway, this topic really belongs elsewhere now. But if/when it does popup again, can we please hear better arguments against it, rather than the fluff above, which is not at all convincing.
Dlang mtg at Red Robin in Overlake 7pm tonight
be there or be square!
Re: Would this be a useful construct to add to D? auto for constructor call.
On 1/23/2024 8:01 AM, Steven Schveighoffer wrote: zero proposals that infer type from how they are used have been accepted by Walter, this one probably will be no different. Types are inferred in D from the bottom up. Mixing in special cases of it being top down leads to confusion over how the type is determined.
