www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is public by default an unsafe default?

reply NotYouAgain <NotYouAgain gmail.com> writes:
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.
May 01
next sibling parent M.M. <matus email.cz> writes:
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?
May 01
prev sibling next sibling parent reply Serg Gini <kornburn yandex.ru> writes:
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 

Swift, Julia, Python), provide outcome of their analysis, prepare 
some code examples which are showing shortcomings of 
current/proposed behaviour.
May 01
parent NotYouAgain <NotYouAgain gmail.com> writes:
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 

 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/
May 01
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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?


Yes, it's sensible.

People most of the time want to use the things they write by 
default, and so having members be public by default is what 
people would expect.

It becomes an annoyance for the developer in languages when you 
forget the "public" equivalent, and have to go back and add it. 
I've experienced this a lot with Angular/Typescript.

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.

I don't see how public by default affects memory safety.

-Steve
May 01
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 1 May 2024 at 14:33:42 UTC, Steven Schveighoffer 
wrote:

 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?


 Yes, it's sensible.

 People most of the time want to use the things they write by 
 default, and so having members be public by default is what 
 people would expect.

 It becomes an annoyance for the developer in languages when you 
 forget the "public" equivalent, and have to go back and add it. 
 I've experienced this a lot with Angular/Typescript.


Kotlin is public by default and I enjoy it thoroughly.

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

—
Dmitry Olshansky
CEO   [Glow labs](https://glow-labs.pro)
https://olshansky.me/about/
May 01
parent reply NotYouAgain <NotYouAgain gmail.com> writes:
On Wednesday, 1 May 2024 at 15:31:02 UTC, Dmitry Olshansky wrote:

 ..
 ...
 Kotlin is public by default and I enjoy it thoroughly.



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.
May 01
parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:


 enjoy using them.


Did this help them to be protected from atackers?
Do you have this kind of information?
May 02
next sibling parent NotYouAgain <NotYouAgain gmail.com> writes:
On Thursday, 2 May 2024 at 19:49:40 UTC, Sergey wrote:

 On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:


 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.
May 02
prev sibling parent reply NotYouAgain <NotYouAgain gmail.com> writes:
On Thursday, 2 May 2024 at 19:49:40 UTC, Sergey wrote:

 On Wednesday, 1 May 2024 at 23:38:05 UTC, NotYouAgain wrote:


 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.
May 02
parent reply Serg Gini <kornburn yandex.ru> writes:
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
May 03
parent NotYouAgain <NotYouAgain gmail.com> writes:
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/#/
May 03
prev sibling next sibling parent reply NotYouAgain <NotYouAgain gmail.com> writes:
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/
May 01
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 1 May 2024 at 23:24:01 UTC, NotYouAgain wrote:

 On Wednesday, 1 May 2024 at 14:33:42 UTC, Steven Schveighoffer 
 wrote:

 ..
 ...
 I don't see how public by default affects memory safety.


 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.


As far as D is trying to be "safe by default", this is in the 
context of memory safety only.


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

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


I can't see how a language can stop people from not exposing API 
they didn't intend to expose.

Just the top one on the list:

"With the Optus API beach, attackers discovered a publicly 
exposed endpoint that didn’t require authentication."

How is D possibly going to enforce that certain API routes on a 
high-level framework have framework-specific authentication 
enabled?

-Steve
May 01
parent reply NotYouAgain <NotYouAgain gmail.com> writes:
On Thursday, 2 May 2024 at 00:27:40 UTC, Steven Schveighoffer 
wrote:

 ..
 ...


Either I accidently made by agrument absurd, or you are 
intentionally redirecting my argument to make it sound absurd?

I was of course referring to API's in the sense the 'safety' 
extends to more than just memory safety. I'm sure you would agree 
here.

In any case, the abstract notion of safety was the inherent topic 
for this discussion, not memory safety.

So referring back to the Subject: "Is public by default an unsafe 
default?"

I'd have to say yes, it is, because the surface for accidents 
(and attacks) is bigger than what it would otherwise have been.

What are my chances of hacking an API that was accidently private 
(because that was the default)? I'd say my chances decrease. They 
surely don't increase.

What are my chances of accidently using a private implementation 
property/method, when the implementation is all 'public by 
default'. I'd say my chances certainly increase. They surely 
don't decrease.

A few posts ago someone mentioned liking to program in a language 
because it was public by default. But liking or not liking, is 
not related to safe or unsafe.

I don't like locking all my windows and doors.

I'd like to leave them open.

In the past, I actually often forget to do just that (in a place 
I no longer live in). The consequences? I got broken into 6 times 
(although not really broken into, since they just climbed in 
through an open window).

I'd say private by default has the same advantages (and 
disadvantages) of locked by default. But I still prefer the minor 
inconvenience of private by default.

I was pleasantly surprised that you can in fact take some control 
over this in D.

So I encourage more D programmers to do just that.


module m;
 safe:
private:

....
May 02
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 2 May 2024 at 08:05:32 UTC, NotYouAgain wrote:

 I was of course referring to API's in the sense the 'safety' 
 extends to more than just memory safety. I'm sure you would 
 agree here.

 In any case, the abstract notion of safety was the inherent 
 topic for this discussion, not memory safety.

 So referring back to the Subject: "Is public by default an 
 unsafe default?"


No.


 I'd have to say yes, it is, because the surface for accidents 
 (and attacks) is bigger than what it would otherwise have been.


For attacks definitely not.

There is nothing that a systems level programming language can do 
to prevent a creative programmer from accessing the private parts 
of an API (we are not talking about web APIs). Just mirror the 
data definition with the `private` keyword removed, and cast the 
instance to the new definition. With D's introspection 
capabilities it is even easier than that.

So accessibility attributes have nothing to do with security, 
they are simply a means to manage binary compatibility between 
different releases of a library and as an aid to reason about 
code (assuming you have no one in your team doing tricks like the 
above).

Believing that accessibility attributes have any significance 
regarding security is dangerous.

-- Bastiaan.
May 02
next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 2 May 2024 at 17:22:25 UTC, Bastiaan Veelo wrote:


 There is nothing that a systems level programming language can 
 do to prevent a creative programmer from accessing the private 
 parts of an API (we are not talking about web APIs). Just 
 mirror the data definition with the `private` keyword removed, 
 and cast the instance to the new definition. With D's 
 introspection capabilities it is even easier than that.


Imho, it's more about protecting from sloppy misuse of api not 
intended to be public from the get go, and lazyiness in properly 
setting private to declarations on a module, not malicious 
reverse engineering.
May 02
prev sibling parent reply NotYouAgain <NotYouAgain gmail.com> writes:
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.
May 02
parent NotYouAgain <NotYouAgain gmail.com> writes:
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'.
May 02
prev sibling parent Dom DiSc <dominikus scherkl.de> writes:
On Wednesday, 1 May 2024 at 23:24:01 UTC, NotYouAgain wrote:

 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.


At least in D  safe is only about memory safety - and even that 
is not the default :-/
May 02
prev sibling parent NotYouAgain <NotYouAgain gmail.com> writes:
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.
May 01
prev sibling next sibling parent WhoMeAgain <tedious bore.com> writes:
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
May 01
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, May 1, 2024 5:52:30 AM MDT NotYouAgain via Digitalmars-d 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-intern
 al/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.


For the most part, public and private really don't have anything to do with
 safe or memory safety. The primary exception would be when an  safe /
 trusted public API is being presented, but the internals are doing  system
stuff that has to be  trusted.

In such cases, if symbols are accidentally left public rather than private,
then  trusted code could be making assumptions that are not valid if any
external code accesses the symbols which were supposed to be private. But
even then, anything  system which is done with those private symbols will be
treated as  system, so the  safety system will prevent you from doing
anything that isn't memory safe with those symbols. It's just that if
 trusted functions make assumptions about the state of the symbols which are
not necessarily valid if external code has access to those members, then
 trusted would be treating stuff as  safe when it shouldn't, which could
lead to memory safety problems.

So, in a case such as that, having a symbol accidentally marked as public
could create  safety issues, but for the vast majority of code, it won't,
and so  safety and symbol visibility are largely orthogonal concerns (just
not 100% orthogonal).

Rather, I'd say that the bigger problem with public by default is simply
that it makes it easier to have symbols that were supposed to be private end
up in your public API. Then you can end up in a situation where something
that you thought was private is being used by external code somewhere, and
when you make a change that should only affect your code's internals, it
could break user code.

So, there's definitely an argument to be had that private by default would
be better, because then you have a lower risk of accidentally having symbols
be part of your public API when you didn't intend for them to be. However,
at the same time, it's quite trivial to just slap

private:

at the top of the module if that's a concern. And there are a number of
folks who would argue that all symbols should be explicitly marked with
public or private anyway (which I'm not a big fan of, but it does work
better with maintainability and code reviews when the attributes affecting a
symbol are directly on the symbol rather than somewhere else in the file).

Also, it's far more problematic to use

public:

because it will also affect imports, and you don't want to accidentally make
imports public. So, having private as the default could lead to more issues
with imports, because folks who wanted public on most of their symbols but
didn't want to mark them individually would likely be inclined to put

public:

at the top of their module and would then likely run into problems as a
result, whereas slapping

private:

at the top of the module isn't error-prone in the same way.

In many respects, I am inclined to think that it would be better for private
to be the default (at least as long as public: is changed to not affect
imports), but at the same time, in my experience, it's pretty rare that
symbols end up being public when they weren't supposed to be, and even when
they do, since they're undocumented, it's usually only a problem if someone
goes spelunking in the code and starts using undocumented stuff that's
public.

Ultimately both public by default and private by default work just fine, and
the issues that you get with one or the other usually aren't a big deal. So,
I don't think that it's all that big a deal which one a language goes with.

And if we wanted to be particularly concerned about it, then arguably, the
correct solution would be to just require that visibility attributes be
directly on the symbols to fix the problem, which would be annoying in some
cases, but mass-applying attributes often has a tendency to cause problems,
and public: in particular can be pretty bad because of how it affects
imports.

- Jonathan M Davis
May 01
parent NotYouAgain <NotYouAgain gmail.com> writes:
On Thursday, 2 May 2024 at 00:30:44 UTC, Jonathan M Davis wrote:

 ... However, at the same time, it's quite trivial to just slap

 private:

 at the top of the module if that's a concern.


Yes, had I known that I likely would not have created this thread 
;-)

Still, i guess it's highlight that option as being available, for 
those who (like me) did not know.

I encourage people to use it more often - if you can 'remember' 
to do that.

I cannot recall the last time I forgot to lock my car when 
leaving it, but I expect it will happen one day, and 'hopefully' 
nobody will know till I get back to it.
May 02
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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?


It's sensible - that's how C works after all. But it probably 
isn't optimal. Ideally `private` would be the default in my view.


 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?


Well, since we're going to have editions it could be changed 
easier than otherwise. But still, it's probably not worth it. 
It's still a good deal of migration work for those with lots of 
old code, over what's more a matter of taste than an universally 
agreed pain point.


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


The (present module-level) `private` visibility attribute I guess.
May 02
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/2/24 13:01, Dukc wrote:

 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?


 
 It's sensible - that's how C works after all.


Arguably it is a bit more complicated in C. You would usually explicitly 
include a declaration in a header file to make symbols of a library 
visible to users. "Private" symbols would just not appear in the header 
file, and I think not including something in a header file is the 
default option. (Of course, there is no protection against other code 
making a declaration manually, but I think technically even in D you can 
access private symbols over their mangled name.)
May 02
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 2 May 2024 at 11:45:57 UTC, Timon Gehr wrote:

 It's sensible - that's how C works after all.


 Of course, there is no protection against other code making a 
 declaration manually, but I think technically even in D you can 
 access private symbols over their mangled name.


I think that would, or could fail to work because the compiler 
does not necessarily add the private symbol to the export table 
of an object file. The linker would then fail to find it.
May 02
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
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.
May 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Being public or private has nothing to do with memory safety.

Private is of interest only when complexity exceeds a certain threshold.
May 07
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
May 08