On Monday, 29 October 2018 at 15:50:33 UTC, 12345swordy wrote:
> On Monday, 29 October 2018 at 15:00:07 UTC, Stanislav Blinov wrote:
>
>> So? You, the programmer, are breaking encapsulation here by accessing 'private' member.
> There is no encapsulation break, as it located in the same module. The encapsulation that you speak of is human enforced.

Again, so?..
If I saw such code in C++, I'd known that it either won't compile, or I'd need to check if I'm in a friend code.
If I saw such code in D, my first thought would be that the author did that intentionally. Because *that's what D's 'private'* is intended for.

This is quite common pattern in D:

--- list.d

struct List(T) {
    private struct Node { /* ... */ }
    private Node* head;
}

auto makeList(R)(R range) {
    import std.range;
    alias T = ElementType!R;
    alias Node = List!T.Node; // oh no, that'd break "encapsulation" in C++
    Node* head;
    foreach_reverse (e; range) {
        auto n = new Node(e);
        n.next = head;
        head = n;
    }
    return List!T(head);
}

--- main.d

void main() {
    auto list = [ 1, 2, 3, 4 ].makeList;
    /* ... */
}

And this doesn't just apply to lists. It becomes *very* easy to make complex implementations without putting in made-up roadblocks for yourself, or jumping through hoops to "white-list" friends. That is what D's 'private' for. For everything else, there are packages. Now, if that's not enough for you, then you need to show, quite clearly, *why* that is.

>> That'd be interesting to see. Why didn't you put those supposed limitations in there to begin with? I.e. what's the purpose of this "messy draft"?
> To get feedback. Which allows me to spot things that need revisiting or need better explaining. This isn't the final draft. Not by a long shot.

Then why are you arguing? Wouldn't it be more productive to analyze the feedback and update the document as you see fit? So far you didn't present any practical use case for your proposal, other than some arguable "good practice", people are saying as much.

>> Global variables aren't accessing anything. You (the programmer) are, by assigning values to them.
> That counter point doesn't make any sense. You act like that I am arguing that they are intelligent or something.

No, you're arguing that having globals somehow breaks "encapsulation" of *other* data. It doesn't, not unless the programmer says so. Copying a *value* from a private member to another variable isn't breaking any encapsulation at all. You literally do that all the time when implementing your beloved getters.

>> That's not an issue with encapsulation at all. That's a lifetime issue.
> Not my point. The point is that the compiler won't complain that you are getting the local variable in the function from outside the function, irregardless that you set it to private or not and will compile just as fine.

The compiler does complain for cases when it should, as I've shown in the example that you cut out. You're not getting anything from outside the function, you pass it over from within.

>>> Nested classes/functions are not encapsulated. The module itself is the unit of encapsulation.
>>
>> You're confusing encapsulation and scopes now:
> *shrugs*
>  The other user treat them as one as the same.

And?..

On Monday, 29 October 2018 at 16:31:31 UTC, Stanislav Blinov wrote:

> Then why are you arguing? Wouldn't it be more productive to analyze the feedback and update the document as you see fit? So far you didn't present any practical use case for your proposal, other than some arguable "good practice", people are saying as much.
That a really good question, bad habit I suppose?

> And?..
Why did you specifically call me out then?

On Monday, 29 October 2018 at 16:40:43 UTC, 12345swordy wrote:

>> And?..
> Why did you specifically call me out then?

Because it's your thread and your DIP, so you at least should get your definitions straight, and clearly communicated.