On Tuesday, 28 October 2025 at 08:01:40 UTC, Walter Bright wrote:
>
> ...
> Sure, it does mean a change in layout from other languages. But the capability is there.
>
> 

I need to push back just one more time.

That capability is not there. That is my whole point and reason for this thread.

You cannot say this in D code: "this particular part of my class is mine alone, not even my friendly module neighbors can touch it."

People can debate as to whether I should have the right (or need) to say that "this part of my class is mine alone, not even my friendly module neighbors can touch it.", but they cannot argue that I can already do this.

D's position is very clear though. That is, "You simply cannot say this in D - and that's they way we want it to remain."

On Tuesday, 28 October 2025 at 16:26:57 UTC, Max Samukha wrote:
> On Tuesday, 28 October 2025 at 13:25:42 UTC, jmh530 wrote:
>> On Tuesday, 28 October 2025 at 02:28:41 UTC, Walter Bright wrote:
>>> I know you didn't propose this, but I had quite enough of C++'s "friend" classes. I've never missed that misfeature in D.
>>
>> You are correct on this.
>
> He's been attacking a strawman. Nobody asked for friend classes. People have been asking for the ability to restrict access to non-friend class members inside a module. Even Rust gives you that by allowing struct implementations in in-file submodules.
>
> (Dislaimer: I don't care about "class-private".)

I think that 'Disclaimer' misses the point of this thread.

In my view, the [internal aspect of a] module should represent a 'collaboration boundary', not an 'ownership boundary'.

That is the real distinction I'm trying to make.

This is where different perspectives should take their positions.

It just so happens that I'm using a class type here, but it could be any type.

One side of the argument is: If you put related types in the same module, they should own each other.

I say no - actually, I put them in the same module because they needed to collaborate much more closely than they would be able to if they were not in the same module. But they certainly do not need to own each other.

I have not seen any valid argument, for why 'they should own each other'.

On Tuesday, 28 October 2025 at 22:16:19 UTC, Peter C wrote:
> One side of the argument is: If you put related types in the same module, they should own each other.
>
> I say no - actually, I put them in the same module because they needed to collaborate much more closely than they would be able to if they were not in the same module. But they certainly do not need to own each other.
>
> I have not seen any valid argument, for why 'they should own each other'.

Then use packages, not modules, and you'll get the properties you want. Have modules encapsulate a single type with friends instead, or a set of overly friendly types not privy to messing with each one around behind the back of other colleagues (types) in the code.

You can then have package act as a module when imported somewhere else.

Over-fixating on why you cant have it all in a single module will only lead to unnecessary frustration (seen it here before).

Best regards.

On Tuesday, 28 October 2025 at 22:36:58 UTC, Lance Bachmeier wrote:
>
> ..
> Over the years this has come up many times. Can you provide an example showing the value of doing that? I understand that maybe that's your preference for whatever valid reason, but I've never seen anyone give an example where it's actually a constraint.
>
> If you want to push on this, that's where you should start. Because every previous such proposal I've seen has died, as the people requesting it keep arguing from authority that it's the correct way to do things, rather than demonstrating the benefit of a major change to the language.

Example after example will get nowhere, fast.

It's a matter or principle, not examples.

The principal behind one perspective is: Modules are collaboration units, types are sovereign owners.

The principle behind the other perspective says: Modules disolve ownership, and they are all or nothing.

I am a firm believer, that each type should be able to guard its invariants, even in a collaborative module.

It just so happens that I primarily use class types, so the principle itself often gets overlooked in the discussion, and (some) people focus their attention on their dislike of OOP instead ;-)

I firmly believe that types should retain their sovereignty, even in within a module, and scopeprivate would accomplish this.

Collaboration, should not erase ownership.

Can you give me an example where it should ;-)

On Tuesday, 28 October 2025 at 22:51:35 UTC, Alexandru Ermicioi wrote:
>
> ..
> Over-fixating on why you cant have it all in a single module will only lead to unnecessary frustration (seen it here before).
>
> Best regards.

yet another strawman argument.

I believe Walter touched on this strawman argument also - https://forum.dlang.org/post/10dpahf$1dgm$1@digitalmars.com

You can have a 10,000 line module with or without scopeprivate.

And I believe some already exist - or close to it.

See my previous response just now, as to what the discussion should really be about:

https://forum.dlang.org/post/vdigkqqodpqvakmytcbr@forum.dlang.org

On Tuesday, 28 October 2025 at 20:59:06 UTC, Peter C wrote:
> When a programming language actively and intentionally prevents me from being explicit about how the members of my class can be accessed, the programming language becomes irrelevant to me.

Does that mean you're going to stop posting about it?

On Tuesday, 28 October 2025 at 23:15:36 UTC, Peter C wrote:
>
> Can you give me an example where it should ;-)

Everywhere: all the time. Kaps lib had one use of the private keyword he added on a whim for a week, I needed to go edit it out within 2 hours of downloading the new copy.

"Stop working" keywords can only make (overall) less code compile; I like to think compilers should try to compile code, by the little known philosophy of "you have ONE JOB" and "clankers lack an immortal soul and have no right to question me a divine being"

If a problem is naturally imperative; and thats all of io; you may mathematically be able to convert it to a something "pure" but the further you push the more it will look like Haskell telling you need to learn about monads to print hello world; you should just skip ahead on the path of "safety enlightenment" to full Haskell, look at a monad implementing the same bug you could've done in c-89 in less time, and return to embrace the chaos.