On Thursday, 9 February 2023 at 23:05:35 UTC, Hipreme wrote:
> On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide wrote:
>> On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:
>>> On 2/8/23 04:07, zjh wrote:
>>>
>>> > Last time, someone proposed to add `private` like `C++'s`,
>>>
>>> We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems.
>>>
>>> Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem.
>>>
>>> Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient.
>>>
>>> In contrast, I use D every day and love its relaxed attitude towards private.
>>>
>>> > and then it
>>> > was the same,they are always unwilling to add facilities
>>> useful
>>>
>>> That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not.
>>>
>>> Ali
>>
>> You mentioned previously that D implements various things in unprincipled ways.
>>
>> I guess, if one wants to use D, one has to be comfortable with this.
>>
>> But using a relaxed attitude towards the implementation of such a common and important abstraction, that in turn allows me to so easily shoot myself in the foot, is not really an attractive feature .. to me ;-)
>>
>> btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off.
>
>
>
>
> Most of the time, when people use "private", they are actually shooting their users which can't even extend their class. I rarely see code which people use "protected" instead and I find that pretty lacking. One thing is hiding memory allocation details on your class, other thing is hiding a property which could and should be controlled when extended in a class.
>
> To be fair I'm more often than not against private variables. Most of the time it only caused me headaches because there was a lot of unimplemented features and I could not simply fork the project. This is not only in D. I got that in Java, Haxe, C#. Thankfully those languages has ways to simply ignore the private attribute, which can't be done in D.
>
> Anyway, I'm not against static classes and I don't think they would bring any inherent problems, they should not cause regression and they should be easy to implement as the compiler already has the tools for it

Glad to hear someone say they're not 'against' something ;-)

btw. The Swift programming language is superior to D with regards to the notion of type privacy.

That is, Swift has fileprivate (which provides **the exact** same flexibility of D's private), but Swift (unlike D), *does* allow the programmer to choose to have aspects of their type private to that type. To something similar to Swift private in D, the programmer is **required** to have that type - and nothing else, in a module. That then places an important design decision in the hands of the langauge, rather than the programmer.

It's unlikely this aspect of Swift is in any way 'unprincipled', but more likely, a very well thought out decision to give programmers control of their design.

So uising a term someone else mentioned in this thread, the programmer is 'free' to make their own choices around type privacy in Swift, but not in D :-(

On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote:
>
> Not everybody shares that view. So, there must be something deeper here: maybe some people are blind (including me), or others have expectations that they carry from other languages, or something else... But look at the contrast: Some people see the same thing as great and some people see it as really really bad.
>

Well, it's true, that we all have preconceived and limited notions, about this or that.

But honestly, dithyrambic praise of how D does things is not all that helpful.

You talk about being 'free' as a programmer, but that terms only seems to apply to your needs.

I'd like to be 'free' to decide on whether I want type privacy, or module privacy.

I don't understand the dithyrambic praise, from some D users, for D preventing you from doing so (in a way that is truly 'free' - as opposed to enforcing a design decision on to the programmer)

Anyway, the 'reality' is, that type privacy can be both convenient and inconvient.

Good luck on your path towards that enlightenment ;-)

"Before practicing Zen, mountains were mountains and rivers were rivers.
While practicing Zen, mountains are no longer mountains and rivers are no longer rivers.
After realization, mountains are mountains and rivers are rivers again."

On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:

> Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way.

That is how a Python aficionado would defend the absence of visibility attributes therein. "We don't have them, because _ is enough, and there are no bugs". And I would agree that D would be better off without visibility attributes entirely instead of having unending issues with them (private aliases, private + reflection, private + synchronized/invariant, etc).

> In contrast, I use D every day and love its relaxed attitude towards private.

Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance".

On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear wrote:
> It's not a freedom issue, it's a library-design issue. Some libraries want to incorporate a namespace-like design to force the user to be more 'explicit' with what they want.
>
> SFML has a `Keyboard` namespace which has a `Key` enum.
>
> The user is 'forced' (although I am not sure if this is the case since it's C++) to use the `Keyboard.` declaration before using the `Key` enum. Looking at code block 1 and 2, which makes more sense?

Pretty sure you can strip namespaces in any language that has namespaces, C# routinely does it and refers to all types with their nonqualified names. It even has Keys enum: https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which is referred to as Keys after stripping the System.Windows.Forms namespace.

On Friday, 10 February 2023 at 14:17:25 UTC, Kagamin wrote:
> Pretty sure you can strip namespaces in any language that has namespaces, C# routinely does it and refers to all types with their nonqualified names. It even has Keys enum: https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which is referred to as Keys after stripping the System.Windows.Forms namespace.

An example from KeePass: https://github.com/dlech/KeePass2.x/blob/VS2022/KeePass/Util/SendInputExt/SiCodes.cs#L86

On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:

> Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance".

This is a great example of the problem. In a discussion of any five programmers, you'll have five conflicting sets of rules that are the obvious and intuitive way to do it.