On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:
> C++, C#, and Rust are private by default, and I thoroughly enjoy using them.

Did this help them to be protected from atackers?
Do you have this kind of information?

On Thursday, 2 May 2024 at 17:22:25 UTC, Bastiaan Veelo wrote:
> ...
> Believing that accessibility attributes have any significance regarding security is dangerous.
>
> -- Bastiaan.

People may need to know how something behaves, they don't necessarily need to know how it works. Of course, if you want to know how it works, there is always a way...

As for accessibility attributes, their purpose is:

"Hiding is for the prevention of accidents, not the prevention of fraud" -  Stroustrup, B. 1991. 7be C+ Programming Language, Second Edition. Reading, Massachusetts: Addison-Wesley, p. 377

Actually, I read that decades ago. That was justification enough for me then, and remains so today.

There is zero reason, that I can surmise, as for why my implementation has to be public by default. Having to make it private yourself ALL the time, requires discipline. Making it private by default requires no effort (well in D it does, since you have to remember to add 'private:' to the top of your module).

Hiding implementation and preventing access. That is the advantage of private.

The advantage of private-by-default is that you get that advantage without any effort on your part (well, except in D of course).

Any effort should be going into making something public, not making something private.

At least, that is my position. Always has been, almost certainly always will be.

On Thursday, 2 May 2024 at 23:02:49 UTC, NotYouAgain wrote:
> ...
> Hiding implementation and preventing access. That is the advantage of private.


oops ;-)

that should read preventing 'accidents'.

On Thursday, 2 May 2024 at 19:49:40 UTC, Sergey wrote:
> On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:
>> C++, C#, and Rust are private by default, and I thoroughly enjoy using them.
>
> Did this help them to be protected from atackers?
> Do you have this kind of information?

I doubt private-by-default would prevent a plane from executing a sharp dive because a passenger turned on the overhead light. But it might well prevent passengers from being able to directly instruct a plane to execute sharp dive.

There are no hidden surprises when something not meant to be public, is private.

I'm not talking about a few D modules here and there - you could argue that is just a matter of being a good programmer. But when discussing defaults in the context of large, complex, industrial strength software, where you have teams of developers, you really do not want to be inviting total breakdown .. by default.

On Thursday, 2 May 2024 at 19:49:40 UTC, Sergey wrote:
> On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:
>> C++, C#, and Rust are private by default, and I thoroughly enjoy using them.
>
> Did this help them to be protected from atackers?
> Do you have this kind of information?

a private attribute provides a mechanism for a type to be type-safe. Static assumptions can then be made and enforced by the compiler.

private is clearly a good thing in that context. I don't think one can argue it is a bad thing, in that context.

private by default is a good thing also. Your already developing your type in a type-safe manner from the get-go. Again, I don't think one can argue that is a bad thing, in this context.

unless of course, type-safety is not your thing ...it certainly is not in C (a language that D so strongly aligns itself to).

But in large, industrial-strength applications being worked on by multiple teams, I guarantee that enforcment of a type-safe language becomes a strategic decision (i.e. it's not decided on whether programmers like type safe programming, or not).

So yes, private and private-by-default are matters related to type-safety, and type-safety are matters to safe use of software.

So is public by default an unsafe default? Well in the context of the above, of course it is.

On Thursday, 2 May 2024 at 23:56:19 UTC, NotYouAgain wrote:
> So is public by default an unsafe default? Well in the context of the above, of course it is.

But isn’t it more about library/framework decisions, rather than the language itself?

PHP has public by default, but frameworks are choosing their own strategy:

http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html

On Friday, 3 May 2024 at 11:10:08 UTC, Serg Gini wrote:
> On Thursday, 2 May 2024 at 23:56:19 UTC, NotYouAgain wrote:
>> So is public by default an unsafe default? Well in the context of the above, of course it is.
>
> But isn’t it more about library/framework decisions, rather than the language itself?
>
> PHP has public by default, but frameworks are choosing their own strategy:
>
> http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html

https://ocramius.github.io/extremely-defensive-php/#/

On Wednesday, 1 May 2024 at 11:52:30 UTC, NotYouAgain wrote:
> No doubt this will create controversy too.. why.. I don't know... but anyway....
>
> Declarations within a D module (other than import declarations) are public by default.
> This includes public by default in a class too btw.
>
> Programmers from many of the other major languages will have to deal with this surprise (in addition to the surprise of how private has taken on a completely new meaning in D).
>
> Not discussing private here! We all know what will happen if we do. So don't!
>
> Question 1 - is 'public by default' a sensible default for a language that is aiming to be safe by default?
>
> Here's an interesting article relating to Kotlin, where I believe public is also the default. It kinda sets the stage....
>
> https://discuss.kotlinlang.org/t/kotlins-default-visibility-should-be-internal/1400
>
> Question 2 - if public is not a sensible default for a language that is aiming to be safe by default, is it too late to change it?
>
> Question 3 - if a change was made, what would become the new default?
>
> Please be respectful in your comments, if you have anything to say.

I don't think it public by default has anything to do with memory safety. Having said that, I've lost count of how many times my life would have been made easier if private were the default instead. Defaults matter, and since most people take the path of least resistance that means most D functions out there are public. Which means people start depending on them. Which means refactoring is a pain.

Being public or private has nothing to do with memory safety.

Private is of interest only when complexity exceeds a certain threshold.

On Wednesday, 8 May 2024 at 00:22:59 UTC, Walter Bright wrote:
> Being public or private has nothing to do with memory safety.

I don't think he even talks about memory safety in first place, but rather general safety. It seems a lot of people hearing safety think memory safety in this discussion.

> Private is of interest only when complexity exceeds a certain threshold.
That is, if developers improving the module are pedantic developers.

Developers just doing their work at an job may not hassle to put private at all, spilling most of internals into exterior, which could easily be used without awareness by other team members.