On Tuesday, 28 October 2025 at 04:02:24 UTC, monkyyy 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.
>
> go the extra mile and delete private and immutable

Based monkey take!!! Let's go!!

On 10/28/2025 12:21 AM, Peter C wrote:
> Without appropriate scope rules, you can't enforce that boundary, and you lose encapsulation - and encapsulation is the foundation of abstract data types.
> 
> Then, the distinction between interface and implementation collapses.
> 
> Then, the type's internal rules are meaningless - the abstraction collapses, the type becomes harder to reason about, everything becomes global, its internal state leaks into the rest of the module, breaking any guarantees that the type is supposed to enforce.
> 
> Without scope, your type just becomes a bags, that anyone can poke into, undermining abstraction, modularity, and reliability.

Sure, it does mean a change in layout from other languages. But the capability is there.

The boundary is at the module level. The "friends" are the other functions in the module. If they are not actually friends, they shouldn't be in that module.

It's entirely under the programmer's control.

As for the distinction between interface and implementation, that can also be done with .di files. The 'i' in .di stands for "interface".

On Tuesday, 28 October 2025 at 06:47:14 UTC, Peter C wrote:
> Even after more that two decades of devlopment, the D Programming Language didn't even get a single mention. It's not that it was mentioned and then discarded as not being a suitable succesor for this or that reason, it just wasn't mentioned. Not even a mention from the audience at question time. This was just last year! I was pretty suprised by this actually.
>
> I'd love to ask Helge Penne why he never mentioned the D Programming Language.

Please don't make it a popularity discussion because it will turn this forum post into a mess of random words.

I think a good way of thinking about this is that some languages just do things in a specific way. Nothing wrong with that. You can't take Rust and use it like C# and you can't take D and use it like C++. All of these languages have OOP ideas, but they implement them in different ways.

On 10/27/2025 11:47 PM, Peter C wrote:
> Even after more that two decades of devlopment, the D Programming Language didn't even get a single mention. It's not that it was mentioned and then discarded as not being a suitable succesor for this or that reason, it just wasn't mentioned. Not even a mention from the audience at question time. This was just last year! I was pretty suprised by this actually.
> 
> I'd love to ask Helge Penne why he never mentioned the D Programming Language.

D has terrible marketing.

Adding more features won't change that.

What matters are people doing things with D, and then writing articles about it and posting them online. Lots of people are doing great things with D, but nobody writes articles about it.

I've seen plenty of pretty lame articles about other languages posted online. There's no reason we cannot do better with this.

People are willing to make presentations for Dconf. But none will take the next step and write an article about the contents of their presentation. I don't really understand that. Besides, writing programming articles is a great way for engineers to become known in the programming world, which means better opportunities and more pay!

On 10/27/2025 11:47 PM, Peter C wrote:
> The internal state of this type, in D, 'automatically' leaks into the rest of the module.

Yes. If you want to hide the internals of a class, put it in its own module. The "friends" then can no longer access the internals.


> So what's the problem then?

Every feature adds complexity. At some point, the language becomes unwieldy, where nobody knows the entire language, and people use only islands of it (see C++). Maintaining a language is always a battle with complexity. Having too many ways to accomplish the same goal is not very desirable.

Your proposal does indeed have merit. But is it a big enough to justify a new keyword, and more documentation? The more pages a language spec has, the fewer people will read it. People love languages that can do a lot with very few pages. You could learn C in an hour reading K+R. I remember when Go was introduced and people loved that they could learn Go in just one lecture.

It needs more to justify it.

P.S. The major driver of the new "editions" feature is to enable us to remove features that do not carry their weight, and that have easy alternatives. It's not that they are useless features. It's just that features should have a big impact. For example, Manu and Timon convinced me that placement new would have a substantial impact on what could be done with D.

P.P.S. I do appreciate the time you took to present your proposal. You've thought it out well. Thank you!

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.

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

On Tuesday, 28 October 2025 at 08:37:46 UTC, Walter Bright wrote:
> On 10/27/2025 11:47 PM, Peter C wrote:
>> The internal state of this type, in D, 'automatically' leaks into the rest of the module.
>
> Yes. If you want to hide the internals of a class, put it in its own module. The "friends" then can no longer access the internals.
>
>
> > So what's the problem then?
>
> Every feature adds complexity. At some point, the language becomes unwieldy, where nobody knows the entire language, and people use only islands of it (see C++). Maintaining a language is always a battle with complexity. Having too many ways to accomplish the same goal is not very desirable.
>
> Your proposal does indeed have merit. But is it a big enough to justify a new keyword, and more documentation? The more pages a language spec has, the fewer people will read it. People love languages that can do a lot with very few pages. You could learn C in an hour reading K+R. I remember when Go was introduced and people loved that they could learn Go in just one lecture.
>
> It needs more to justify it.
>
> P.S. The major driver of the new "editions" feature is to enable us to remove features that do not carry their weight, and that have easy alternatives. It's not that they are useless features. It's just that features should have a big impact. For example, Manu and Timon convinced me that placement new would have a substantial impact on what could be done with D.
>
> P.P.S. I do appreciate the time you took to present your proposal. You've thought it out well. Thank you!

Your position is clear, and I won't push it further.

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.

Taking away a tool that millions of programmers use, it not going to get D the audience it 'supposedly' desires.

I can't even do this in D!

// Compile-time visibility tests
unittest
{
   auto acc = new Account(5, "Eve", 400.0, "tok5");

   // Allowed:
   static assert(__traits(compiles, acc.getBalance()));

   // Forbidden (scopeprivate):
   static assert(!__traits(compiles, acc.balance));
   static assert(!__traits(compiles, acc.authToken));
}

I am very fortunate being a C# programmer, as I do not need to seek a successor language ;-)

Good luck with the future of your language.