On Sunday, 12 June 2022 at 23:09:22 UTC, forkit wrote:
> On Sunday, 12 June 2022 at 12:26:33 UTC, Chris Katko wrote:
>>
>> If I could have private (or any keyword that mimics C++ private) as a optional compiler flag, I would turn that on in a heartbeat.
>
> That is actually a decent alternative (i.e. an 'optional' compiler switch).
>
> But even with the support of the D community, this would likely end up being something that Walter would have to implement (in that messy thing known as the frontend).
>
> I'm sure he would give it is foremost attention ;-)
>
> To be honest, the more I look into Swift (I only started a few days ago), the less impressed I am with D.
>
> I think Swift has a really bright future actually.
>
> https://docs.swift.org/swift-book/GuidedTour/GuidedTour.html

Swift has definitly a bright future no matter what, because it has one of the most powerful companies that asserts that is the only way to play on their turf going forward, besides Objective-C and C++.

Unfortunely the time for such kind of big industry players to pick D has moved on, they are now busy with Go, Rust, or adding to Java, .NET and C++ the missing pieces that made D a better option, while having a much bigger ecosystem in tooling and libraries.

On Monday, 13 June 2022 at 05:11:31 UTC, forkit wrote:

> oh. I misread the question.
>

Yeah, I misread the suggestion.

On Sunday, 12 June 2022 at 17:42:32 UTC, Adam D Ruppe wrote:
> On Sunday, 12 June 2022 at 14:05:00 UTC, Max Samukha wrote:
>> (You were actually surprised for a moment, weren't you?)
>
> Actually, when I used PHP's classes the first time, I as so perplexed at why this private thing was giving an error when the code was right next to it.
>
> It just seems so unnatural.

But then 'private' on modules should not seem more natural to you as well.

On Monday, 13 June 2022 at 04:39:23 UTC, Mike Parker wrote:
>
> Right now, you can split your module into two files and present them to the world as a single module with package.d. What does your suggestion buy us that this doesn't aside from a single module name trait?

Let's see.

a.d
```
module a;

class Foo
{
	private:
	int _c;
}

import b;
void handle(Bar child)
{
  child._c += child.c;
}
```
b.d
```
module b;

import a;

class Bar : Foo
{
	public:
	int c;

	this(int c)
	{
		this.c = c;
	}
}
```

main.d
```
module main;

import a;
import b;

void main()
{
	auto bar = new Bar(30);
	handle(bar);
}
```

If D is truly "module private" then the above should be able to compile, if it's "class private" then it shouldn't be able to compile.

Since the above doesn't compile then D isn't really "module private" and thus the conclusion is that one of the most fundamental features of D is also an unfinished feature.

D states it is "module private" but really it is neither "module private" or "class private" it's a mix between the two... and I'm not sure whether that's good or not.

On Monday, 13 June 2022 at 07:59:24 UTC, bauss wrote:
> <snip>

It does what I would expect it to do. What exactly is the issue with this?

On Monday, 13 June 2022 at 07:59:24 UTC, bauss wrote:

>
> If D is truly "module private" then the above should be able to compile, if it's "class private" then it shouldn't be able to compile.
>
> Since the above doesn't compile then D isn't really "module private" and thus the conclusion is that one of the most fundamental features of D is also an unfinished feature.

But why should that compile? You're trying to manipulate `_c` through an instance of `Bar`. It's not visible in any `Bar`, ever, so why should it be visible here? It has to be gotten at through the interface of `Foo`.