Adding a new design constraint to D

[forkit]

On Thursday, 16 June 2022 at 07:16:56 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 16 June 2022 at 01:04:22 UTC, forkit wrote:
>> On Thursday, 16 June 2022 at 00:06:14 UTC, forkit wrote:
>>>
>>
>> see .. the world does not come crashing down, simply because 
>> you can declare something private ;-)
>>
>>
>> (in Swift)
>>
>> // -----------
>> struct A
>> {
>>   private static var x = 100;
>>   fileprivate static var z = 200;
>> }
>>
>> //print(A.x); //  error: 'x' is inaccessible due to 'private' 
>> protection level
>> print(A.z); // ok
>>
>> // -----------
>
> Swift has 5 different access control modes:
>
> - private: as in C++
> - file private: for the source file
> - internal: for a collection of sources files constituting a 
> module
> - open access: allows subclassing and override outside the 
> module
> - public: …
>
> Swift also does some conservative analysis of references, 
> preventing writing to references if there is an alias that 
> would make it a conflict:
>
> https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html

yes, in essence, the everything is global in a Swift module, much 
like like D (at least conceptually). Although the module concept 
is different in Swift (being a bunch of file that make up module 
- which i like much better than the D concept).

So Swift provides that same convenience as D, of not having to 
state anything, and just go about writing code, if that's your 
style.

But it allows people to 'choose' a style -> private (scope 
private), and fileprivate (private to the file).

I mean, choice is good right?

Well, I like it anyway.