Feedback on Átila's Vision for D

Aliak something at
Sat Oct 19 11:10:43 UTC 2019

On Saturday, 19 October 2019 at 07:45:14 UTC, drug wrote:
> On 10/18/19 5:37 PM, Aliak wrote:
>> On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:
>>> On 10/17/19 11:48 PM, aliak wrote:
>>>> On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker 
>>>> wrote:
>>>>> On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:
>>>>>> [...]
>>>>> Private to the module *is* correct in D.
>>>> That's debatable: 
>>> You complain that `doAmazingStuff` can access private members 
>>> of class A if this function and this class are placed 
>>> together in one module and continue complain that if you put 
>>> that class in its own module then `doAmazingStuff` now cannot 
>>> access private members of A and isn't a "first class" citizen 
>>> of class A. Could you explain you position clearly?
>> My position on what? No private access is the consequence of 
>> moving a function out of a module.
>  That's probably my misunderstanding but I think you took a bad 
> example to show the problem.
> You state that:
> 1) it is bad that `doAmazingWork` has private access to class A 
> members if it is in one module with class A
> 2) it is bad that `doAmazingWork` has no private access to 
> class A members if it is in an other module than class A
> In my opinion these statement are contradictory

Oh. I see. Statement 1 is that it *can* be bad. And for statement 
2, I do not think i state anywhere that it’s bad? I can try and 
rephrase maybe? (Suggestions?)

Some languages have moduleprivate and privateprivate. If D had 
that then you could actually protect your objects, and if you 
wanted to allow non-state related variables to only the module 
you could do that too. So functions can access moduleprivate vars 
and do things that outside modules couldn’t and variables can be 
fully protected within a class if need be as well.

More information about the Digitalmars-d mailing list