www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Preparing for the New DIP Process

reply Mike Parker <aldacron gmail.com> writes:
A few months back when I announced in one of our planning updates 
that we were freezing the DIP queue to focus on stabilization, I 
noted that the DIP process was going to get an overhaul. I've 
since learned that this message didn't stick, so I'll paste here 
what I said then.

---

The DIP process is getting a long-needed overhaul. Over time, 
I've had feedback from people who have authored DIPs and those 
who decided not to. There are a number of different opinions 
about how things can change, but there are some common themes 
among them.

I'll write in more detail about this later, but there are a few 
major goals I have with the overhaul:

* reduce the burden on the author
* reduce the amount of time a submitted DIP is in review
* establish support for fleshing out ideas before a DIP is even 
written
* establish support for developing initial DIP drafts before they 
are submitted

Previously, I'd always considered development of the DIP separate 
from the DIP "process", which I saw as beginning with the 
submission of a pull request. In reality, the process begins even 
before an author opens an editor to start typing. I hope that by 
recognizing that, and by providing support for discussing ideas 
and writing the DIP, we'll foster an environment that still 
maintains a relatively high bar for DIPs that get submitted, but 
also creates a filter such that potential DIP authors can be more 
confident that they aren't wasting their time once they get to 
the development stage. By the time they get there, they'll have 
no doubt if it's an idea worth pursuing.

---

I'm getting ready to open things up again. The new process is 
going to be much, much looser than before. I'll have all the 
details in the announcement when we reopen, and I should be able 
to give you a general timeframe after our planning session 
tomorrow.

I'm making this pre-announcement announcement now so that any 
authors with a DIP frozen in the PR queue can have a heads up. 
We'll need to treat these somewhat differently than new DIPs, but 
we'll be ready to get moving on them when the author is. It's 
entirely on the author's schedule, not ours.

And if any of you are thinking about submitting a new DIP, I ask 
you to start thinking about the details, but don't start writing 
it just yet. Once the new process is open, you won't have to sit 
and write it in isolation with no feedback from Walter or Atila. 
You'll be able to get feedback early from both them and the 
community, so you can know very early on if it's something you're 
willing to pursue, and you'll hopefully have a good bit of help 
to get it developed.

The process as it existed had a high bar with the intention of 
encouraging the production of quality DIPs and discouraging 
frivolous proposals. In practice, that high bar was a high 
barrier to entry and ended up discouraging even good proposals. 
I'm optimistic that the new process will lower the barrier to 
entry and still encourage quality proposals.

And by "quality" I'm not referring to the quality of the DIP's 
language. In the new process, the focus will be entirely on the 
details of the proposal and not on the language in which they're 
presented. I'm happy to clean that up myself once a proposal is 
accepted.

Just wanted to put out a heads up. More to come!
Jan 17
next sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

 Just wanted to put out a heads up. More to come!



I hope the new `'dip'` process is as simple as `writing plugins`.
Jan 17
prev sibling next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

 And by "quality" I'm not referring to the quality of the DIP's 
 language. In the new process, the focus will be entirely on the 
 details of the proposal and not on the language in which 
 they're presented. I'm happy to clean that up myself once a 
 proposal is accepted.



Very cool development!
Jan 18
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
This is going to be a great initiative. Thanks, Mike!
Jan 18
prev sibling parent reply privateWHAT <privateWHAT gmail.com> writes:
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

 * establish support for fleshing out ideas before a DIP is even 
 written


It's 2024. That should have been the principle a decade ago

Remember how the so called 'discussions' about the 'privateThis' 
concept always got heaped on. People just wanted to shut it down 
rather that discuss it. 'Go write a DIP' was the 
response...remember.


 ...
 Previously, I'd always considered development of the DIP 
 separate from the DIP "process", which I saw as beginning with 
 the submission of a pull request. In reality, the process 
 begins even before an author opens an editor to start typing. I 
 hope that by recognizing that, and by providing support for 
 discussing ideas and writing the DIP, we'll foster an 
 environment that still maintains a relatively high bar for DIPs 
 that get submitted, but also creates a filter such that 
 potential DIP authors can be more confident that they aren't 
 wasting their time once they get to the development stage. By 
 the time they get there, they'll have no doubt if it's an idea 
 worth pursuing.


Bring back the privateThis discussion, so we can put your newly 
discovered revelations to the test.

Maybe the folks over at openD can try discussing it too, and see 
what happens there ;-)
Jan 20
next sibling parent privateWHAT <privateWHAT gmail.com> writes:
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:

..


For those newcomers who don't know what that was all about..

https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242
Jan 20
prev sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:

 On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

 * establish support for fleshing out ideas before a DIP is 
 even written


 It's 2024. That should have been the principle a decade ago

 Remember how the so called 'discussions' about the 
 'privateThis' concept always got heaped on. People just wanted 
 to shut it down rather that discuss it. 'Go write a DIP' was 
 the response...remember.


The class vs module level of encapsulation was fleshed out a lot 
in the forums awhile back. I think it's fair to say most people 
where happy (or neutral) with the status quo, and were not 
convinced by the pro-class-level arguments.

I also suspect those that did prefer class level private (I 
believe this is what Atila prefers), it's not high on their list 
of priorities.

Jordan
Jan 20
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
  I think it's fair to say most

 people where happy (or neutral) with the status quo, and were 
 not convinced by the pro-class-level arguments.



So there are very few people in the D community. If you don't 
care about others, they don't care about you.
Jan 20
next sibling parent zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote:

 So there are very few people in the D community. If you don't 
 care about others, they don't care about you.



[here](https://github.com/opendlang/opend/pull/30)

A small feature that has no side effects at all.
They are just not merging it.
Jan 20
prev sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote:

 On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
  I think it's fair to say most

 people where happy (or neutral) with the status quo, and were 
 not convinced by the pro-class-level arguments.



 So there are very few people in the D community. If you don't 
 care about others, they don't care about you.


What? I'm sorry, but being happy with module level != not caring 
about others.

Jordan
Jan 20
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 07:46:07 UTC, Jordan Wilson wrote:


 What? I'm sorry, but being happy with module level != not 
 caring about others.

 Jordan




You don't know the `pain `of not having a certain feature,
Jan 20
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 07:51:00 UTC, zjh wrote:


 You don't know the `pain `of not having a certain feature,


And this feature has already been `implemented`, even without 
`any side effects`!
They just ignore you!
Jan 20
parent reply Dom DiSc <dominikus scherkl.de> writes:
On Sunday, 21 January 2024 at 07:52:59 UTC, zjh wrote:

 On Sunday, 21 January 2024 at 07:51:00 UTC, zjh wrote:


 You don't know the `pain `of not having a certain feature,


 And this feature has already been `implemented`, even without 
 `any side effects`!


`class-private` is superfluous cruft. You can very easy live 
without it.
And it has only no side effects, if it is implemented without 
`friend`s. But without this misfeature it is incomplete.
Therefor it was decided not to implement it.

It would be ok for me to add `class-private` as is, but only with 
the guarantee that `friend`s will never be added, no matter how 
much the  people using it cry, because it is sometimes unusable 
without them.
Jan 21
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 11:46:42 UTC, Dom DiSc wrote:

 It would be ok for me to add `class-private` as is, but only 
 with the guarantee that `friend`s will never be added, no 
 matter how much the  people using it cry, because it is 
 sometimes unusable without them.



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.
Jan 21
next sibling parent reply Dom DiSc <dominikus scherkl.de> writes:
On Sunday, 21 January 2024 at 11:51:59 UTC, zjh wrote:

 When you need `friend`, You can put them all in one module.


Jup. But putting things in one module won't do anymore if you use 
class-private. That's why people using it will soon realize they 
need friends. But friends are a security hole, rendering private 
completely useless at all.

So adding class-private without friends is an incomplete feature, 
that will make nobody happy. But class-private with friends is a 
misfeature.
Ergo: do not add class-private at all!
All that's possible with class-private is also possible with 
module-private. But module-private don't has the friends-issue. 
Everything is good - you only need to realize that.
Jan 21
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 12:17:28 UTC, Dom DiSc wrote:


 All that's possible with class-private is also possible with 
 module-private. But module-private don't has the friends-issue. 
 Everything is good - you only need to realize that.



A file, just `one class`, sometimes I hope so, but sometimes I 
don't want so. I want several `classes` to be closely related but 
`independent` together!

This is `harmless`, you only need to add a keyword, but you meet 
the `user's` needs.
`Class level private`, increasing one's own selectivity.
Adding `redundancy` has always been what Walter hopes for, 
`hasn't` it?
Jan 21
next sibling parent zjh <fqbqrr 163.com> writes:
On Sunday, 21 January 2024 at 12:53:22 UTC, zjh wrote:

 `Class level private`, increasing one's own selectivity.
 Adding `redundancy` has always been what Walter hopes for, 
 `hasn't` it?


Moreover, `modules, classes, and variables` private are 
considered complete.
I don't understand why just drop out `class level private` ? Just 
because this is a C++approach, it appears to be the same as C++ 
`without any style`?
Jan 21
prev sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Sunday, 21 January 2024 at 12:53:22 UTC, zjh wrote:

 This is `harmless`, you only need to add a keyword, but you 
 meet the `user's` needs.


Nope, not harmless. It will have maintenance cost.
Jan 21
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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."
Jan 22
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, January 22, 2024 4:01:54 PM MST Walter Bright via Digitalmars-d-
announce 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."


It also greatly simplifies having to deal with visibility attributes. I can
understand folks being concerned about it at first, but in practice, it
really isn't a problem.

If it really is a problem for a piece of code to have access to something
private that's in the same module, then you can simply put them in separate
modules, and if your module is large enough that you can't keep track of
that sort of thing like you need to, then it should probably be split up.

And for those cases where you need cross-module access without it being
public, there's always the package attribute.

The end result is that visibility attributes are very easy to reason about,
and you don't have to worry about them much. I really think that the folks
who insist on having private be private to the class/struct (or who insist
on a new attribute which does that) are just too tied to how other languages
work and haven't given D's approach a chance. I don't think that I have
_ever_ seen a problem stem from the fact that D's private is private to the
module. And in fact, it causes so few issues that way that plenty of folks
end up being surprised to find out that it works that way, because they've
never run into a situation where it actually mattered that it wasn't private
to the class/struct.

Of course, ultimately, different programmers have different preferences, and
none of us are going to be happy about everything in any language. So, of
course, there are going to be some folks who are unhappy with how D defines
private, 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
Jan 22
next sibling parent reply Danilo <codedan aol.com> writes:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
wrote:

 Of course, ultimately, different programmers have different 
 preferences, and none of us are going to be happy about 
 everything in any language. So, of course, there are going to 
 be some folks who are unhappy with how D defines private, 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.


The people who still put 50,000 LOC into a single file
will not be happy with this. ;)
Jan 22
parent Dom DiSc <dominikus scherkl.de> writes:
On Tuesday, 23 January 2024 at 07:29:33 UTC, Danilo wrote:

 The people who still put 50,000 LOC into a single file
 will not be happy with this. ;)


Fair enough. I'm also not happy with their code.
Jan 23
prev sibling next sibling parent reply FairEnough <FairEnough gmail.com> writes:
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.
Jan 24
next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
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
Jan 24
next sibling parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:

 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.


String mixins are one the D’s killer features but the lack of 
string interpolation make them look like a mess.
Jan 24
parent reply Danilo <codedan aol.com> writes:
On Thursday, 25 January 2024 at 07:56:50 UTC, Ogi wrote:

 String mixins are one the D’s killer features but the lack of 
 string interpolation make them look like a mess.


You can use `q{}`

```d
mixin(q{
     static foreach(p; __traits(parameters))
     {{
         enum pname = __traits(identifier, p);
         static if(__traits(hasMember, this, pname)) {
             __traits(getMember, this, pname) = p;
             pragma(msg, "found member: " ~ pname);
             pragma(msg, __traits(getAttributes, p));
             pragma(msg, __traits(getAttributes, typeof(pname)));
             //pragma(msg, p);
         }
     }}
});
```
Jan 25
parent Ogi <ogion.art gmail.com> writes:
On Thursday, 25 January 2024 at 08:58:29 UTC, Danilo wrote:

 You can use `q{}`


```D
string wrap(string f) {
     return "void wrap_"~f~"() { "~f~"(); }";
}
void fun() {}
mixin(wrap("fun"));
```
Not only `q{}` will make this even less readable—it won’t even 
work.
Jan 26
prev sibling parent reply FairEnough <FairEnough gmail.com> writes:
On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:

 ...
 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.


Allowing mutable state to escape - the confines of the type in 
which it has been declared - into the whole of the module, will 
inevitably lead to a problem.

My first use of the D language demonstrated that this statement 
is factual.

The more 'widespread' D is used, will 'likely' also demonstrate 
the same.

Having a means to control what state can or can't escape into the 
rest of the module seems like a pretty sensible option to have - 
at least to me.

Again, the only argument that has been put forward against this, 
is that in D you can put your type into its own module. That is, 
one module for every class, and for every unittest.

That can end up to be a lot of files needing to be managed, 
simply to control the escape of state into a module.
Jan 26
next sibling parent reply Elias (0xEAB) <desisma heidel.beer> writes:
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:

 That can end up to be a lot of files needing to be managed, 
 simply to control the escape of state into a module.


In case you’re worried about the clarity in your editor’s file 
list (or in similar tools), try packagizing your modules; that 
should lead to folders that are easily collapsible.

In case you’re worried about running out of inodes on ext4 
filesystems, maybe give XFS a try.
Jan 26
parent FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 01:57:01 UTC, Elias (0xEAB) wrote:

 On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:

 That can end up to be a lot of files needing to be managed, 
 simply to control the escape of state into a module.


 In case you’re worried about the clarity in your editor’s file 
 list (or in similar tools), try packagizing your modules; that 
 should lead to folders that are easily collapsible.

 In case you’re worried about running out of inodes on ext4 
 filesystems, maybe give XFS a try.


No, not really worried about running out of inodes ;-)

My interests are in types that are correct (in both design and 
use) and enforcable (at least to a reasonable extent).

Without private(this) you cannot determine the intent of that 
types use by other code in the module. And you certainly cannot 
enforce it. This is true for all other code, including code for 
unitttests.

Without private(this), you *always* leak *all* of the types state 
into the rest of the module. Hence the workaround of putting 
every type in its own module, and every unittest making use of 
that type in a separate module to that type.

Otherwise, leaky state will inevitably bite you (unless you're 
one of those programmers that never make mistakes).
Jan 26
prev sibling next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:

 On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson 
 wrote:

 ...
 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.


 Allowing mutable state to escape - the confines of the type in 
 which it has been declared - into the whole of the module, will 
 inevitably lead to a problem.

 My first use of the D language demonstrated that this statement 
 is factual.


When I first used a dynamically typed language, I was inevitably 
caught out by type errors. I understood this to be part of the 
many trade offs all languages make.


 The more 'widespread' D is used, will 'likely' also demonstrate 
 the same.


I suspect the proportion of users that really care about explicit 
class privacy and find the workaround of putting a class that 
needs such privacy into a separate file untenable, will remain 
the same.

Jordan
Jan 27
next sibling parent reply FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:

 ...
 I suspect the proportion of users that really care about 
 explicit class privacy and find the workaround of putting a 
 class that needs such privacy into a separate file untenable, 
 will remain the same.

 Jordan


Well D already has class privacy. Would be absurd if it didn't.

So this is not about class privacy per se, nor is it about OOP.

It's about whether D should provide an *option* for class privacy 
within a module, so that the programmer can use it when it is 
appropriate (e.g. there is other code in the module as well, 
perhaps even just a unittest, and the programmer wants the 
compiler to enforce type safe use of that type within that 
unittest).

But still none of what you said addresses the questions I put 
forward. Answers to those questions will form the basis for a 
need (or not), for private(this).

(Q1) Are there any circumstances where a class type might need to 
retain control over its state from other code within the same 
module (including unittest code)?

(Q2) What problems could potentially occur when a class types 
state is always leaked into the module.

If your answer to Q1 is no, then there is nothing more to say.

If your answer to Q1 is yes, but in this case just put the type 
in its own module, then you've not really answered the question, 
since there would be no other code in the module.

If your answer to Q2 is none, then there is nothing more to say.

If your answer to Q2 identifies one or potential problems, you 
have an immediate type safety concern that needs to be addressed, 
somehow. There is no language feature to help you deal with that 
problem (i.e have the compiler enforce your design). You simply 
have to avoid putting any other code in the same module (this 
includes your unittest code).

So D's approach to answering these two questions, is you should 
prevent the circumstance from ever arising by constraining your 
design to one type per module, and the unittest for that type in 
its own separate module as well. That will be acceptable to some, 
and not others.

It also raises a final question of whether that is all the D 
programming language should ever provide to the programmer - a 
way to avoid these situations by constraining your design.

If you answer yes, there is obviously nothing more to discuss.

If you answer no, then what can be done about it?

As I've mentioned, I think Swift got the balance right.
Jan 27
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote:

 On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson 
 wrote:

 ...
 I suspect the proportion of users that really care about 
 explicit class privacy and find the workaround of putting a 
 class that needs such privacy into a separate file untenable, 
 will remain the same.

 Jordan


 Well D already has class privacy. Would be absurd if it didn't.


I said "explicit class privacy", I was meaning the concept you 
are talking about (it probably wasn't the most accurate phrase).


 But still none of what you said addresses the questions I put 
 forward. Answers to those questions will form the basis for a 
 need (or not), for private(this).


By offering counter questions, I was trying to make a point about 
the line of questioning itself. But I'll answer anyway.


 (Q1) Are there any circumstances where a class type might need 
 to retain control over its state from other code within the 
 same module (including unittest code)?


I have not come across such a circumstance personally, during my 
time with languages using higher level encapsulation (D module / 
Go packages). I can certainly imagine that some would have that 
need for a particular situation, but I can't think of it.

I believe we are now in the "there is nothing more to be said" 
territory (just for the record, I think we both agree the feature 
is good, I just don't think the feature is necessary at 
all...nice-to-have at best. I suspect we'll agree to disagree).

Jordan
Jan 27
next sibling parent John Thomas <jthomas thezone.com> writes:
On Saturday, 27 January 2024 at 19:58:55 UTC, Jordan Wilson wrote:

 On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote:

 On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson


 I believe we are now in the "there is nothing more to be said" 
 territory (just for the record, I think we both agree the 
 feature is good, I just don't think the feature is necessary at 
 all...nice-to-have at best. I suspect we'll agree to disagree).


Its probably more useful if you manage a team of barely competent 
idiot programmers.
Jan 27
prev sibling parent FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 19:58:55 UTC, Jordan Wilson wrote:

 ..
 I believe we are now in the "there is nothing more to be said" 
 territory (just for the record, I think we both agree the 
 feature is good, I just don't think the feature is necessary at 
 all...nice-to-have at best. I suspect we'll agree to disagree).

 Jordan


It *is* necessary, if you are like me and want to design types 
upfront so you don't have to read all the code in the module to 
see which parts of that type are touched outside of the type, and 
which are not.

class C
{
     private int x;

     private(this):
         int y = 1;
         int w, z;

     public void test()
     {
       y = y + 4;
     }

     public int getY()
     {
         return y;
     }
}

unittest
{
     auto c = new C();

     import std;

     writeln(__traits(getVisibility, C.y));
     static assert(__traits(getVisibility, C.y) == 
"private(this)");

     c.x++; // allowed
     //c.y++; // not allowed
     //c.w++; // not allowed
     //c.z++; // not allowed

     c.test;
     writeln(c.getY);
}
Jan 27
prev sibling next sibling parent FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:

 ..
 When I first used a dynamically typed language, I was 
 inevitably caught out by type errors. I understood this to be 
 part of the many trade offs all languages make.


Yes, but a big bank would not write its financial applications in 
a dynamically typed language, now would it.

In any large complex application, type safety is paramount.

D came about as a reaction to C/C++

Same for Swift.

Same for Go.

But since Go doesn't have a class type, its pointless comparing 
implementation between Go and D.

Much better to compare D and Swift in this regards.

There will be some who say 'D did it right', and others who say 
'but Swift did it better'.

It may depend on the priority a programmer gives to type safety, 
as to which side they are on.

Personally, I don't like being 'caught out by type errors' ;-)
Jan 27
prev sibling parent reply FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:

 ..
 I suspect the proportion of users that really care about 
 explicit class privacy and find the workaround of putting a 
 class that needs such privacy into a separate file untenable, 
 will remain the same.

 Jordan


Or ...they might just add it to a fork of D.


"[PR ready] Class-level private (in addition to the current 
module-level private)"

https://dpldocs.info/opend/roadmap.html
Jan 27
parent reply Sergey <kornburn yandex.ru> writes:
On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote:

 On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson 
 wrote:

 ..
 I suspect the proportion of users that really care about 
 explicit class privacy and find the workaround of putting a 
 class that needs such privacy into a separate file untenable, 
 will remain the same.

 Jordan


 Or ...they might just add it to a fork of D.


 "[PR ready] Class-level private (in addition to the current 
 module-level private)"

 https://dpldocs.info/opend/roadmap.html


I thought you already has fork with this feature enabled.
Jan 27
parent FairEnough <FairEnough gmail.com> writes:
On Saturday, 27 January 2024 at 11:42:59 UTC, Sergey wrote:

 On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote:

 On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson 
 wrote:

 ..
 I suspect the proportion of users that really care about 
 explicit class privacy and find the workaround of putting a 
 class that needs such privacy into a separate file untenable, 
 will remain the same.

 Jordan


 Or ...they might just add it to a fork of D.


 "[PR ready] Class-level private (in addition to the current 
 module-level private)"

 https://dpldocs.info/opend/roadmap.html


 I thought you already has fork with this feature enabled.


I integrated these changes into my own fork a long time ago: 
https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

I've never looked back, and never had any issue with this 
feature. It's just works.

I prefer to design my class upfront so that it doesn't leak 
private mutable state. Not outside of the module, and not inside 
of the module.

But should I ever need to leak mutable state into the module, I 
can do that as well.

So I have the best of both worlds. Others don't have that, but I 
do ;-)
Jan 27
prev sibling parent John Thomas <jthomas thezone.com> writes:
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:

 On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson 
 wrote:

 ...
 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.


 Allowing mutable state to escape - the confines of the type in 
 which it has been declared - into the whole of the module, will 
 inevitably lead to a problem.

 My first use of the D language demonstrated that this statement 
 is factual.

 The more 'widespread' D is used, will 'likely' also demonstrate 
 the same.


What we need to do is find a way to make the computer explode 
when somebody does that. Weed out the stupid programmers. ;-)
Jan 27
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
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!
Jan 24
prev sibling parent Sergey <kornburn yandex.ru> writes:
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
Jan 24
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
wrote:


 Of course, ultimately, different programmers have different 
 preferences, and none of us are going to be happy about 
 everything in any language.


It's not only about preferences. The feature is inconsistent with 
how 'invariant' and 'synchronized' are specified. They imply 
class-instance-level private, while the language dictates 
module-level. Consider:

```
synchronized class C
{
     private int x;
     private int y;

     invariant () { assert (x == y); }
}

void foo(C c)
{
     // mutate c
}
```

With module-level private, 'foo' is part of C's public interface, 
but it neither locks on c, nor runs the invariant checks. I 
personally have no idea how to fix that sensibly except by 
ditching class invariant/synchronized entirely.
Jan 25
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:

 module-level. Consider:

 ```
 synchronized class C
 {
     private int x;
     private int y;

     invariant () { assert (x == y); }
 }

 void foo(C c)
 {
     // mutate c
 }
 ```

 With module-level private, 'foo' is part of C's public 
 interface, but it neither locks on c, nor runs the invariant 
 checks. I personally have no idea how to fix that sensibly 
 except by ditching class invariant/synchronized entirely.




`private to module `, goes against `consistency, completeness, 
and redundancy` pursued by D, just to maintain the `uniqueness` 
between `D and C++`!
Jan 25
parent zjh <fqbqrr 163.com> writes:
On Thursday, 25 January 2024 at 15:14:30 UTC, zjh wrote:

 `private to module `, goes against `consistency, completeness, 
 and redundancy` pursued by D, just to maintain the `uniqueness` 
 between `D and C++`!



It is just very funny!
Jan 25
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:

 On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
 wrote:


 Of course, ultimately, different programmers have different 
 preferences, and none of us are going to be happy about 
 everything in any language.


 It's not only about preferences. The feature is inconsistent 
 with how 'invariant' and 'synchronized' are specified. They 
 imply class-instance-level private, while the language dictates 
 module-level. Consider:

 ```
 synchronized class C
 {
     private int x;
     private int y;

     invariant () { assert (x == y); }
 }

 void foo(C c)
 {
     // mutate c
 }
 ```

 With module-level private, 'foo' is part of C's public 
 interface, but it neither locks on c, nor runs the invariant 
 checks. I personally have no idea how to fix that sensibly 
 except by ditching class invariant/synchronized entirely.


Is there issue with module-private, invariant, and synchronized 
solely the result of the interaction between all three? Or is 
there an issue with module-private and invariant by themselves 
(i.e. if C is not synchronized)?
Jan 25
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, January 25, 2024 8:03:41 AM MST Max Samukha via Digitalmars-d-
announce wrote:

 On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis

 wrote:

 Of course, ultimately, different programmers have different
 preferences, and none of us are going to be happy about
 everything in any language.


 It's not only about preferences. The feature is inconsistent with
 how 'invariant' and 'synchronized' are specified. They imply
 class-instance-level private, while the language dictates
 module-level. Consider:

 ```
 synchronized class C
 {
      private int x;
      private int y;

      invariant () { assert (x == y); }
 }

 void foo(C c)
 {
      // mutate c
 }
 ```

 With module-level private, 'foo' is part of C's public interface,
 but it neither locks on c, nor runs the invariant checks. I
 personally have no idea how to fix that sensibly except by
 ditching class invariant/synchronized entirely.


Well, sychronized is actually a function attribute, not a class attribute
(TDPL talks about synchronized classes, but they've never actually been a
thing; it was just a planned idea that was never implemented). You can stick
synchronized on the class itself, but it still only affects the member
functions. So, mutating the class object via non-member functions in the
module really isn't any different from mutating the object with member
functions which aren't marked with synchronized. So, if anything here, I
would argue that the confusion comes from being allowed to stick attributes
on a class and then have them affect the member functions. It does allow you
to stick the attribute in one place and then affect the entire class, but
I'm inclined to think that it probably shouldn't have been allowed in cases
where the attribute isn't actually for the class itself.

Of course, the change that I'd really like to see here is synchronized
removed from the language, since I think that it was definitely a misfeature
(along with having a monitor inside of every class instance to allow
synchronized to work, whether the type is shared or not or has an
synchronized methods or not).

Regardless, because synchronized is not at all a class attribute, I don't
agree that it implies anything related to class-level private, much as I can
see how being allowed to put it directly on a class could cause confusion.

As for invariants, all that the spec promises is that they're called when
public member functions are called. So, again, having a module-level
function directly mutate the members doesn't really violate anything.
However, the part there that I do agree is questionable is that because the
module-level function could be public, it makes it so that it's pretty easy
to end up in a situation where an invariant is skipped when the object is
mutated by calling public functions from the module. But there are also
likely to be cases where it's useful to be able to bypass the invariant like
that (though obviously, it then requires that the code maintain the
invariant, just like  trusted code needs to maintain the promises of  safe).
So, I don't think that it's necessarily a problem that the language works
this way, but it's certainly true that it's something to be mindful of. And
if you want to explictly run the invariant in such sitations, then you can
just assert the class reference. But as with anything related to private, if
you want to guarantee that something only accesses an object via its public
API, you can always just put it in another module.

- Jonathan M Davis
Jan 25
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:

 On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
 wrote:


 Of course, ultimately, different programmers have different 
 preferences, and none of us are going to be happy about 
 everything in any language.


 It's not only about preferences. The feature is inconsistent 
 with how 'invariant' and 'synchronized' are specified. They 
 imply class-instance-level private, while the language dictates 
 module-level. Consider:

 ```
 synchronized class C
 {
     private int x;
     private int y;

     invariant () { assert (x == y); }
 }

 void foo(C c)
 {
     // mutate c
 }
 ```

 With module-level private, 'foo' is part of C's public 
 interface, but it neither locks on c, nor runs the invariant 
 checks. I personally have no idea how to fix that sensibly 
 except by ditching class invariant/synchronized entirely.


This is the only valid reason for introducing class-private 
that's ever been put forth in this forum. I saw someone else post 
a similar argument around class invariants awhile back as well 
and it completely changed my mind on the issue.
Jan 26
parent FairEnough <FairEnough gmail.com> writes:
On Friday, 26 January 2024 at 22:21:22 UTC, Meta wrote:

 This is the only valid reason for introducing class-private 
 that's ever been put forth in this forum. I saw someone else 
 post a similar argument around class invariants awhile back as 
 well and it completely changed my mind on the issue.


This has been argued before, but in a slightly different manner.

Objects have type (i.e. the object is of type class).

As a type, it must be able to present its interface to other code 
in a way that maintains its invariants.

In this view, a class is no different to other types in the 
language, which also maintain their invariants.

The key here, is to think of a class as a type. If you don't 
think that way about classes, then class(private) would seem a 
pretty useless addition to the langauge.

But without a class(private) option, there is simply no way for a 
class 'type' to maintain its invariants in D, when other code is 
in the same module as the class. This includes code for unittests.

The only workaround in D, is to ensure a module (file) contains 
no other code other than that single class.

While module level visibility is very useful, the usefulness of 
class level visibility is not really something that anyone should 
have to justify. A class is a type, and therefore should have the 
ability to maintains its invariants, even from other code in the 
same module.

That, I would argue, is the primary reason for introducing an 
option in D for class(private).

It's not an argument for OOP. It's an arguement to allow a class 
type in D, to be able to present itself 'as type that can 
maintain its own invariants' to other code in the same module. 
The key part there is 'to other code in the same module'. This 
cannot occur without a class level visibility attribute.

The only argument that be put forward against this arguement, is 
that in D, you shouldn't ever need to present a class as 'a type 
that can maintain its own invariants' to other in the same module.

But when a programmer has that need, D cannot provide a solution.

class(private) would immediately solve that problem, for that 
programmer.
Jan 26
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:

 On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
 wrote:


 Of course, ultimately, different programmers have different 
 preferences, and none of us are going to be happy about 
 everything in any language.


 It's not only about preferences. The feature is inconsistent 
 with how 'invariant' and 'synchronized' are specified. They 
 imply class-instance-level private, while the language dictates 
 module-level. Consider:


```d
synchronized class C
{
     private int x;
     private int y;

     invariant () { assert (x == y); }

     static void foo(C c)
     {
         // mutate c
     }
}
```

Same thing. Yet would still break with some sort of "class-only 
private"

the unittest case is also similar -- what happens if you put the 
unittest next to the function being tested? It's now in the 
class, so it can access "true" private data. Same problems, this 
even can happen in Java. I don't see what the difference is. Same 
code, same file, just in a different spot? Seems more like you 
just need to... not do that.

-Steve
Jan 27
parent reply FairEnough <FairEnough gmail.com> writes:
On Sunday, 28 January 2024 at 04:23:06 UTC, Steven Schveighoffer 
wrote:

 ..
 the unittest case is also similar -- what happens if you put 
 the unittest next to the function being tested? It's now in the 
 class, so it can access "true" private data. Same problems, 
 this even can happen in Java. I don't see what the difference 
 is. Same code, same file, just in a different spot? Seems more 
 like you just need to... not do that.

 -Steve


There certainly are things you should not do.

There are also things you want the compiler to stop you doing.

And when you use a programming language, where mutable state 
automatically, by default, and at all times, leaks out of the 
type into the rest of the module, you may really appreciate the 
compilers help sometimes.

That's where private(this) comes in handy.

Now this example is pretty small, but imagine debugging this when 
foo() is all the way down on line 3546!

The intent should be right there in the design of the type. 
Intent should not be subject to analysis of all the code in the 
module.

No need to debug this program below, since it will not even 
compile.


module test;
 safe:

import std;

         class C
         {
             private(this) int x; // intent: other code in this 
module cannnot mutate this.
             private(this) int y; // intent: other code in this 
module cannnot mutate this.

             invariant () { assert (x == y); }

             void modifyX() {...}
             void modifyY() {...}
         }


         void foo(C c)
         {
             c.x = 10; // compiler will not compile this code.
             c.modifyX();
         }
Jan 27
next sibling parent John Thomas <jt whereuat.com> writes:
On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

 module test;
  safe:

 import std;

         class C
         {
             private(this) int x; // intent: other code in this 
 module cannnot mutate this.
             private(this) int y; // intent: other code in this 
 module cannnot mutate this.

             invariant () { assert (x == y); }

             void modifyX() {...}
             void modifyY() {...}
         }


         void foo(C c)
         {
             c.x = 10; // compiler will not compile this code.
             c.modifyX();
         }


Thank you for posting a very informative example, i think not 
just myself but everyone else on this forum had completely forgot 
how class private is supposed to work. In spite of the 1000 or so 
posts you've made about it.

Keep up the good work!
Jan 28
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

So 60 some odd posts later...

If you want to beat this pile of mush further, please do it in a 
new thread. Going forward, any posts I see about 
private-to-the-module which are off topic in any given thread 
will be happily deleted. You've hijacked enough of them.

Thanks!
Jan 28
next sibling parent FairEnough <FairEnough gmail.com> writes:
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

 On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

 So 60 some odd posts later...

 If you want to beat this pile of mush further, please do it in 
 a new thread. Going forward, any posts I see about 
 private-to-the-module which are off topic in any given thread 
 will be happily deleted. You've hijacked enough of them.

 Thanks!


Well I did specifcally say 55+ posts ago that this topic really 
should be discussed elsewhere.

But people continued to discuss it anyway - but only my responses 
raised your annoyance?

Do you mean you would actually allow a thread to discuss this 
topic, if that were the topic of that thread?

Such threads always get hijacked by irritant people completely 
opposed to this idea, and you end up killing those threads too.
Jan 28
prev sibling next sibling parent FairEnough <FairEnough gmail.com> writes:
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

 On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

 So 60 some odd posts later...

 If you want to beat this pile of mush further, please do it in 
 a new thread. Going forward, any posts I see about 
 private-to-the-module which are off topic in any given thread 
 will be happily deleted. You've hijacked enough of them.

 Thanks!


Off topic certainly, but a 'pile of mush'?
Jan 28
prev sibling parent reply FairEnough <FairEnough gmail.com> writes:
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

 On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

 So 60 some odd posts later...

 If you want to beat this pile of mush further, please do it in 
 a new thread. Going forward, any posts I see about 
 private-to-the-module which are off topic in any given thread 
 will be happily deleted. You've hijacked enough of them.

 Thanks!


No more comments about this in this thread. I promise.

For those who don't consider it 'a pile of mush', here is where 
it 'can' be discussed (freely I hope):

https://github.com/orgs/opendlang/discussions/11
Jan 28
parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 28 January 2024 at 22:31:59 UTC, FairEnough wrote:

 No more comments about this in this thread. I promise.


Thank you.


 For those who don't consider it 'a pile of mush', here is where 
 it 'can' be discussed (freely I hope):


It can be freely discussed here, too. Just please stop hijacking 
threads to do it.

As for "pile of mush", it's what the dead horse has been beaten 
into at this point.
Jan 28
prev sibling parent FairEnough <FairEnough gmail.com> writes:
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.
Jan 24
prev sibling next sibling parent Dom DiSc <dominikus scherkl.de> writes:
If you have difficulties to see the logic of module-private, 
think of a module as a flat:
If you don't want someone to mess with your private stuff, don't 
live with him in the same flat! Be ensured, locks on every 
cupboard won't do. You cannot prevent someone within the same 
flat from messing with your private stuff. Most people realize 
that at some point in their life, so only few live together in 
the same flat.
I hope you will also realize at some point in your life, that two 
classes should not live in the same module - except they are 
close friends.
Jan 21
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2024 3:46 AM, Dom DiSc wrote:

 `class-private` is superfluous cruft. You can very easy live without it.
 And it has only no side effects, if it is implemented without `friend`s. But 
 without this misfeature it is incomplete.
 Therefor it was decided not to implement it.
 
 It would be ok for me to add `class-private` as is, but only with the
guarantee 
 that `friend`s will never be added, no matter how much the  people using it
cry, 
 because it is sometimes unusable without them.


The irony is that the presence of class private in C++ wound up motivating the 
friends feature, which violates private left and right. D did it right with 
module level privacy, which is enforced.

C++ private isn't private, const isn't constant, and one can throw from nothrow 
functions.

D users do ask for non-constant const, impure pure, and GC allocating  nogc.
You 
*can* do these things in D by using forcible casts in  system code. The salient 
difference between that and C++ is that the D compiler still assumes those 
invariants are in force, whereas C++ compilers cannot.
Jan 22
next sibling parent Elias (0xEAB) <desisma heidel.beer> writes:
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.
Jan 24
prev sibling parent reply FairEnough <FairEnough gmail.com> writes:
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.


But that, vI assume you mean that in C++ you can return 
pointers/references to private mutable class members, and 
therefore 'private isn't private'.

If that is what you're referring to, then that does not negate 
the value of class private members in C++.

Nor is it argument against an option for class private members 
*within* a module, in D.

There is only 1 valid argument against introducing an option for 
module level class private members in D. And that is, a 
programmer (as in all programmers who use D) should never need to 
control the visibility of a class types mutable state to other 
code in the same module (including unittests).

But is that true?

I mean either it is, or it isn't.

The option presented, i.e. to put the class type in a module by 
itself, does not answer this question (since there is no other 
code in the module).

Any answer to this question has to take into account the other 
code in the module.
Jan 26
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:



`module private and no class private` goes against the 
`consistency, integrity, encapsulation, and redundancy` pursued 
by D, just to maintain the uniqueness between `D and C++`. This 
is very `funny` and not what `serious language` should have!



 Jan 26



  parent reply Jordan Wilson <wilsonjord gmail.com>  writes:


On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote:

 On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:



 `module private and no class private` goes against the 
 `consistency, integrity, encapsulation, and redundancy` pursued 
 by D, just to maintain the uniqueness between `D and C++`. This 
 is very `funny` and not what `serious language` should have!


Does Go and Python qualify as serious languages?

Jordan



 Jan 26



 next sibling parent reply FairEnough <FairEnough gmail.com>  writes:


On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote:

 On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote:

 On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:



 `module private and no class private` goes against the 
 `consistency, integrity, encapsulation, and redundancy` 
 pursued by D, just to maintain the uniqueness between `D and 
 C++`. This is very `funny` and not what `serious language` 
 should have!


 Does Go and Python qualify as serious languages?

 Jordan


Go does not have a class type so it's of little value to compare 
Go to D in this respect.

Python does have a class type, but no explicit means to declare 
private members, other than the underscore 'convention'.

I don't use python so I don't really know whether and to what 
extent that convention is followed. But that fact that there is 
this convention would surely demonstrate some need for it??

The only questions for you to ponder are:

(Q1) Are there any circumstances where a class type might need to 
retain control over its state from other code within the same 
module (including unittest code)?

(Q2) What problems could potentially occur when a class types 
state is always leaked into the module.

If I posed these 2 questions to you during a job interview, how 
would you answer them?



 Jan 26



  parent  Jordan Wilson <wilsonjord gmail.com>  writes:


On Saturday, 27 January 2024 at 05:14:18 UTC, FairEnough wrote:

 On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson 
 wrote:

 On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote:

 On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough 
 wrote:



 `module private and no class private` goes against the 
 `consistency, integrity, encapsulation, and redundancy` 
 pursued by D, just to maintain the uniqueness between `D and 
 C++`. This is very `funny` and not what `serious language` 
 should have!


 Does Go and Python qualify as serious languages?

 Jordan


 Go does not have a class type so it's of little value to 
 compare Go to D in this respect.


I understood zjh's statement to be about `serious languages`, so 
it's fair to include Go.


 Python does have a class type, but no explicit means to declare 
 private members, other than the underscore 'convention'.

 I don't use python so I don't really know whether and to what 
 extent that convention is followed. But that fact that there is 
 this convention would surely demonstrate some need for it??


The fact that python doesn't _enforce_ this demonstrates there 
are languages which have accepted a weakening of the concept of 
pure OOP object encapsulation, in return for something else 
beneficial to the language (I assume).


 The only questions for you to ponder are:

 (Q1) Are there any circumstances where a class type might need 
 to retain control over its state from other code within the 
 same module (including unittest code)?

 (Q2) What problems could potentially occur when a class types 
 state is always leaked into the module.

 If I posed these 2 questions to you during a job interview, how 
 would you answer them?


(Q1) Are there any circumstances where a programmer might need 
the guarantees of a safe language?

(Q2) What problems could potentially occur when an unsafe 
language is used?

(Q3) Are C/C++ serious languages?



 Jan 26



prev sibling  parent  zjh <fqbqrr 163.com>  writes:


On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote:

 Does Go and Python qualify as serious languages?



Of course not!



 Jan 26



prev sibling  parent  FairEnough <FairEnough gmail.com>  writes:


On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:

 ..
 Any answer to this question has to take into account the other 
 code in the module.


Of course, I can answer this question.

The code below demonstrates how D made it possible for me to make 
a mistake when I first used D (i.e. I had the unittest in the 
same module as the class).

Of course now I know, silly me, just put the unittest in its own 
file god-damitt!

But here is how that mistake could have been avoided without 
having to put that unittest in its very own module:

module someClass;

class C
{
     void increment() {++x;}
     private(this) int x;
}

unittest
{
     auto c = new C;
     c.x++; // it seems to me, that this is not what that 'type' 
expects.
     c.increment(); // Thanks private(this) for helping me not 
make that mistake.
}



 Jan 26



prev sibling next sibling parent  claptrap <clap trap.com>  writes:


On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:

 On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:


 I also suspect those that did prefer class level private (I 
 believe this is what Atila prefers), it's not high on their 
 list of priorities.


I wouldn't pay too much attention to him, it's the same guy who 
bows a gasket every time it comes up. Like he is literally unable 
to use D without it. I think he's like 12 yo or something.



 Jan 21



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:

 On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:

 On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker 
 wrote:

 * establish support for fleshing out ideas before a DIP is 
 even written


 It's 2024. That should have been the principle a decade ago

 Remember how the so called 'discussions' about the 
 'privateThis' concept always got heaped on. People just wanted 
 to shut it down rather that discuss it. 'Go write a DIP' was 
 the response...remember.


 The class vs module level of encapsulation was fleshed out a 
 lot in the forums awhile back. I think it's fair to say most 
 people where happy (or neutral) with the status quo, and were 
 not convinced by the pro-class-level arguments.

 I also suspect those that did prefer class level private (I 
 believe this is what Atila prefers), it's not high on their 
 list of priorities.


I like private as it is now. Especially because if anyone wants 
it to be "class-private", they can do that anyway: write a class 
per module like one has to in Java.

My 2 centimes (cos I live in Switzerland) is that if you're 
worried about too much code having access to your private 
functions, your module is probably too large.



 Jan 29



 next sibling parent  FairEnough <FairEnough gmail.com>  writes:


On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:

 On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:

 On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT 
 wrote:

 On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker 
 wrote:

 * establish support for fleshing out ideas before a DIP is 
 even written


 It's 2024. That should have been the principle a decade ago

 Remember how the so called 'discussions' about the 
 'privateThis' concept always got heaped on. People just 
 wanted to shut it down rather that discuss it. 'Go write a 
 DIP' was the response...remember.


 The class vs module level of encapsulation was fleshed out a 
 lot in the forums awhile back. I think it's fair to say most 
 people where happy (or neutral) with the status quo, and were 
 not convinced by the pro-class-level arguments.

 I also suspect those that did prefer class level private (I 
 believe this is what Atila prefers), it's not high on their 
 list of priorities.


 I like private as it is now. Especially because if anyone wants 
 it to be "class-private", they can do that anyway: write a 
 class per module like one has to in Java.

 My 2 centimes (cos I live in Switzerland) is that if you're 
 worried about too much code having access to your private 
 functions, your module is probably too large.


OpenD has already merged this into master anyway. So people can 
finally decided for themselves, rather than being told they don't 
need it and here's a workaround in case you do.

Btw. no DIP was required.

So if anyone wants an 'option' for "class-private", they can now 
do it in OpenD, and the this topic/debate is should be well and 
truly over. Just like const,  safe, ....etc... private(this) is 
there to use when your usecase requires as such. No effect on 
existing D code whatsoever.



 Jan 29



prev sibling next sibling parent  FairEnough <FairEnough gmail.com>  writes:


On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:

 ..
 My 2 centimes (cos I live in Switzerland) is that if you're 
 worried about too much code having access to your private 
 functions, your module is probably too large.


I'd argue:
  (1) this module is not too large. (sure its just for demo the 
concept though)
  (2) private(this) make complete sense here. There is zero need 
for the unittest of have access to count. So why not make that 
part of the Widget class design. I don't see any downside 
whatsoever. Is it absolutely necessary, well, no. But I like the 
design clarity it offers.

module test;

class Widget
{
   public:
     this() { ++count; }
     ~this() { --count; }

     int numWidgets(){ return count; }

   private(this):
     static int count;
};

unittest
{
     Widget w = new Widget, x = new Widget;
     assert(w.numWidgets() == 2);
}



 Jan 29



prev sibling  parent reply mate <aiueo aiueo.aiueo>  writes:


On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:

 I like private as it is now. Especially because if anyone wants 
 it to be "class-private", they can do that anyway: write a 
 class per module like one has to in Java.

 My 2 centimes (cos I live in Switzerland) is that if you're 
 worried about too much code having access to your private 
 functions, your module is probably too large.


To get peace from the forum troll, it might be worth it to add a 
compiler switch `-privateToTheClass` which errors out when it 
finds more than one class per file.



 Jan 29



  parent  Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 30 January 2024 at 00:06:26 UTC, mate wrote:

 On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:

 I like private as it is now. Especially because if anyone 
 wants it to be "class-private", they can do that anyway: write 
 a class per module like one has to in Java.

 My 2 centimes (cos I live in Switzerland) is that if you're 
 worried about too much code having access to your private 
 functions, your module is probably too large.


 To get peace from the forum troll, it might be worth it to add 
 a compiler switch `-privateToTheClass` which errors out when it 
 finds more than one class per file.


Let's shut this down please. Thanks.



 Jan 29