Is public by default an unsafe default?

Atila Neves atila.neves at gmail.com
Tue May 7 17:06:48 UTC 2024


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.


More information about the Digitalmars-d mailing list