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.

On Wednesday, 1 May 2024 at 11:52:30 UTC, NotYouAgain wrote:
> ...
> Question 1 - is 'public by default' a sensible default for a language that is aiming to be safe by default?
>

I am not sure how is "public by default" connected to "safe by default" (or "safe enough", to allow a more broader interpretation).

In principle, putting declarations of module B that are not meant to be public to module A into separate module C and importing that module C in module B will make everything from module C private in module A.

So, on a high level, generally speaking, I don't really see what the problem with "public by default" could be? You surely have a concrete, non-general piece of code in mind?

On Wednesday, 1 May 2024 at 11:52:30 UTC, NotYouAgain wrote:
> Please be respectful in your comments, if you have anything to say.

Could you be so kind to prepare your post in a more structured way?
In case this feature you are interested in, check several languages(not only Kotlin. Let’s say Java, Rust, C++, C#, Go, Swift, Julia, Python), provide outcome of their analysis, prepare some code examples which are showing shortcomings of current/proposed behaviour.

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

It was neither a surprise nor anything to deal with for me. My previous "major" languages, one had a separate interface section, and the other used namespaces.


> Question 1 - is 'public by default' a sensible default for a language that is aiming to be safe by default?

visibility has nothing to do with memory safety


> 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?

Yes.


> Question 3 - if a change was made, what would become the new default?

This wont change, it would break existing code, and has zero benefit.


> Please be respectful in your comments, if you have anything to say.

"If you have to ask for respect then you do not deserve it" - Abraham Lincoln

On Wednesday, 1 May 2024 at 14:33:42 UTC, Steven Schveighoffer wrote:
> ..
> ...
> I don't see how public by default affects memory safety.
>
> -Steve

I don't recall claiming it was related to memory safety. It is cleary not.

The word safe surely does not only apply to memory safety, now does it.

Most breaches that have affected me, personally, have been API breaches.

https://nordicapis.com/8-significant-api-breaches-of-recent-years/

On Wednesday, 1 May 2024 at 15:31:02 UTC, Dmitry Olshansky wrote:
> ..
> ...
> Kotlin is public by default and I enjoy it thoroughly.

Fair enough. C++, C#, and Rust are private by default, and I thoroughly enjoy using them.

But 'enjoyment' was not part of the question ;-)

> Plus in D we can just slap private: at the top of the module/class.

Ah. Now I completely forgot you could do that.

module m;
@safe:
private:
// ok. now I have a much better starting point -> for 'my type' of programming.


But still, I have to 'remember' to do these things in D... and I keep forgetting that.

I also often forget to use const.

On Wednesday, 1 May 2024 at 13:06:14 UTC, Serg Gini wrote:
> On Wednesday, 1 May 2024 at 11:52:30 UTC, NotYouAgain wrote:
>> Please be respectful in your comments, if you have anything to say.
>
> Could you be so kind to prepare your post in a more structured way?
> In case this feature you are interested in, check several languages(not only Kotlin. Let’s say Java, Rust, C++, C#, Go, Swift, Julia, Python), provide outcome of their analysis, prepare some code examples which are showing shortcomings of current/proposed behaviour.

I didn't argue its shortcomings, and I gave a link that argued the issue both ways.

Plenty of people have written phd's on this topic. I don't need to write one as well.

I just wonder what whether national cybersecurity strategy's may begin to look more closely at the implication of languages that are public by default, and perhaps start to incorporate this into their recommendations (in additional to memory safety). I expect it is inevitable that they will.

https://nordicapis.com/8-significant-api-breaches-of-recent-years/

On Wednesday, 1 May 2024 at 14:33:42 UTC, Steven Schveighoffer wrote:
> ..
> ...
> I can understand the counterpoint, that you may want to start from a point of view of exposing the least amount of "set in stone" API. But not everyone is on that ship.

The starting point (for one side of the discussion) would be expose everything, then decide what not to expose.

The counter point would not (and could not) be expose nothing.

The counter point would in fact be, expose nothing, and then 'expose as little as possible'.

If I were part of a team debating this, I think the evidence points to a certain advantage of being on one side, more than the other.

https://nordicapis.com/8-significant-api-breaches-of-recent-years/

https://apisecurity.io/full-archive/

https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents

the list for references here, is very, very long...so I won't go further.