On Tuesday, 7 June 2022 at 19:42:00 UTC, Ola Fosheim Grøstad wrote:
>
> It is very difficult to get good usability as long as most users coming from other languages have a rather firm interpretation of what `private` means.

No, they (we) come with a firm interpretation of what encapsulation means, because they (we) can actually make things private, and that contract can be enforced at compile time - they (we) don't have to 'remember' not to make mistakes.

C++ friend is not something you should be using all the time. It breaks encapsulation. It does not enhance it, in any way, whatsoever. But there are situations where it makes things a lot easier, that's for sure. But it comes at the expense of encapsulation (just as inheritance does). But at least I can choose to inherit, or not. In D, encapsulation is non-existent (from other code within a module). There is no option to encapsulate it either. You're forced to do silly work arounds to just get a pseudo encapsulation.

But more importantly, the language they're 'most likely' coming from, if they do object-based, or object-oriented programming, will be C++,C#, Java. And all these languages sought to enhance the options available to the progrommer to obtain, to obtain greater encapsulation, to various degrees - but D sought to weaken it, intentionally, by making *everything* your friend. You got no choice in D. D's approach (without an option like @private), encourages less encapsulation, by design, because you 'by default' consider everything your friend. There is no need to think about encapsulating components within a module. Some argue this is the whole point. But just go look at some of the modules in phobos ;-)

Faced with the choice of using an object-based, or object-oriented approach to the design of a solution, without a @private option, D would NOT ever be my choice of language. Other langauges are already better suited for such a design.

On Tuesday, 7 June 2022 at 18:07:34 UTC, Andrey Zherikov wrote:
>
> Regarding implementation. I don't like `@private` as people will be confused a lot with `@private`<->`private`. IMHO the ideal solution would be having `module` to mark module privates and `private` for real privates but this is not backward compatible. So the better solution might be extending syntax for `private` having something like `private(symbol[, symbol ...])` where `symbol` is a symbol that has access to the member For example: `this` means current struct/class; `this.foo` or `<typeof(this)>.foo` means foo member in the current struct/class.

Yes. I agree. @private is not descriptive enough.

private(module) on the otherhand, states its purpose very clearly.

On Monday, 6 June 2022 at 11:45:31 UTC, Dom Disc wrote:
> On Monday, 6 June 2022 at 02:35:11 UTC, forkit wrote:
>> On Monday, 6 June 2022 at 01:23:41 UTC, forkit wrote:
>>>
>>
>> when your boss isn't really your friend:
>>
>> // ----
>>
>> module test;
>> @safe :
>>
>> class Employee
>> {
>> }
>>
>> class Boss
>> {
>> }
>>
> Now that is real nonsense! Why should those two classes ever be within the same file?!?
>

The two classes were clearly concocted for the example - actually, after a discussion with a friend about problems they were having with their boss - who pretended to be friend to them, until one day ....

But that aside, it is often that one object cannot exist, unless the other object already exists.

It's not unusual, to want to keep this code together - even, god forbid, in the same module!

> Not everything is a friend - only what is in the same file!

Precisely. That's my whole point. Everything in the same file is your friend. Although, that is not the actual problem, since friends are useful. The actual problem is there is 'no option to unfriend'.

There are no encapsulated components in a module. The D language doesn't provide the means to do that. It's all just one big... thing.

On Tuesday, 7 June 2022 at 23:59:42 UTC, forkit wrote:
>
> Yes. I agree. @private is not descriptive enough.
>
> private(module) on the otherhand, states its purpose very clearly.

On second thoughts - even private(module) is confusing. Does it mean private to the module? It's too confusing also.

Perhaps: private(this)  .. since 'this' is already traditionally associated with the abstraction it's referring to.

On Wednesday, 8 June 2022 at 03:52:05 UTC, Ola Fosheim Grøstad wrote:
>
> That is a weird take. The word can mean private to the file or module, whatever the language defines as the basic unit. Nothing wrong with that, just unusual in language design to use that word inside a class with that meaning.
>

What the language does, is what the language does. I accept that different languages take different decisions around these ideas.

But an ability to put up a barrier around some aspect of a class, using 'private' for example, is clearly a benefit. Where is the downside? I don't get it. If you can put up a barrier, you should also be able to take it down of course (hence 'friend').

It's what C++/Java/C# programmers can already do. Why would a language want to intentionally, take that away, and even go so far as bragging about it?

Even worse, refuse to even consider an option to put if back?

I just don't get it. It makes no sense to me, whatsoever. It's truly beyond what I'd expect for a language that wants to compete with the likes of C++/Java/C#.

I like D's module system cause its convenient and easy to use, and it lets you group logically related abstractions together, in one place. Yey! I really like this. I can even get used to everything being a friend. It doesn't take much cognitive effort to do that ;-)

But not even having the option to put up a barrier around my abstraction to ensure some parts are hidden from surrounding code in the module, is too much.

A module containing a large number of related, but potentially leaky abstractions, doesn't sound that great to me ;-)

As you mentioned in a previous post - no I have to go build a static analyser, cause the compiler is completely useless here.

D has really taken something away. Something I've always had. Something I need, and something I rely upon. Something I want.

>> C++ friend is not something you should be using all the time. It breaks encapsulation. It does not enhance it,
>
> Actually, it often does in my code. I use it to prevent creation of the class outside the factory.

Nonsense. When you break the barrier, you've broken the encapsulation. Full stop. No if and buts about it ;-)

I accept that by breaking the barrier, you might have made your job easier. That's fine also.

I'd like to make my job easier too, by being able to put that barrier back up.

On Wednesday, 8 June 2022 at 06:14:58 UTC, Ola Fosheim Grøstad wrote:
>
> There would be no downside if D was willing to take a breaking change, but that is unlikely.

Huh?

private(this) ..(for example) is not a 'breaking' change. It's completly opt-in.

It provides a choice; Including a choice to just keep doing what you've always been doing.

The only argument against it, that would be worthwhile considering, is the cognitive effort in adapting to such a change.

private int myInt;
private(this) int myInt;

Not much cognitive effort required here ;-)

>
>> A module containing a large number of related, but potentially leaky abstractions, doesn't sound that great to me ;-)
>
> Then write a linter that  does what you want.
>

That's my point. It's sad that you even have consider the need to do this.
My C# compiler already does this for me. Even my C++ and Java compilers do it for me.

But not the D compiler.

>
> If nobody cared enough about this to write and use a linter then that suggests that not enough people care about it enough to warrant a language change.
>

That's cause, perhaps, to those whom it matters, they end up deciding not to use D.

What is their alternative course of action? Spend a year tring to get a DIP through that nobody in the D admin (Walter specifically) even wants.


>
> Just write the linter, if it gains traction then that is proof that a language change should be considered.
>

The proof is already there - i.e. C++/Java/C# programmers, already use and rely upon this feature. Imagine if those lanaguages took it away.

"Sorry folks. We decided to take that feature that you've relied upon for so long, and dump it. Why don't you go write a linter instead."

I'm sure that would go over really well ;-)

On 6/7/2022 5:47 AM, forkit wrote:
> Instead, it deliberately, intentionally, proudly, leaves this important aspect in software development to the programmer(s).

Yeah, well, the alternative is "friend" classes, which are an abomination.

The unit of encapsulation in D is the module, not the class.