Feedback on Átila's Vision for D

Nicholas Wilson iamthewilsonator at
Sun Oct 20 01:52:01 UTC 2019

On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
> On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson
>> How so? Also, you should probably be doing that anyway for 
>> different reasons.
> As in "fits in your head" is not concrete. And it's usually not 
> just "you" in a team.

What I'm saying is a boundary point exists, even if is not 
precisely defined, passed which point separating your module into 
a package is a win for readability and reasonability.

> Plus, IIRC dmd is a prime example where splitting is not 
> happening because of "reasons". So it's not always doable 
> either.

Those reasons are largely "Walter" and are unrelated.

> And thank you :) appreciate the offer! But it's not something I 
> care too much about. And to get something like this in I'd have 
> to argue for why encapsulation of user defined types is a good 
> thing. A if I actually have to argue for that, pretty sure it 
> won't go anywhere. So it's just a level of access I accept is 
> missing from D - one good thing about it is that it gives you 
> less choice so you don't need to worry about privateprivate vs 
> moduleprivate.

Indeed, no need for "friend".

> But anyway, curious, why do you think it's of marginal utility 
> at best? And on a related note have you used any languages that 
> provide both levels of granularity that I mention above?

Because that doesn't allow you to do anything fundamentally new, 
as in the above solutions _work_, even if they don't work as well 
as you'd like them to, and to me it serves as a marker that if 
you are running into that problem then you module is too large 
anyway you likely have other issues regarding trying to reason 
about the code.

No I haven't used both at the same time, but I've used them 
separately and I find that module private provides enough 
encapsulation that I don't find myself wanting something more (As 
opposed to C++ where this impossible because there is only 
textual inclusion, not symbolic imports).

More information about the Digitalmars-d mailing list