On Thursday, 9 June 2022 at 01:04:26 UTC, forkit wrote:
> IMO, without justification.

Maybe you should fork it.

On Thursday, 9 June 2022 at 01:09:14 UTC, Adam Ruppe wrote:
> On Thursday, 9 June 2022 at 01:04:26 UTC, forkit wrote:
>> IMO, without justification.
>
> Maybe you should fork it.

when I win the lotto, that's what I'll do (cause i'd need a team of pretty good compiler developers to get anywhere, and they hard to find, and kinda expensive to employ ;-)

Their very first project would be:

private - private, as it should be.

private[module] - private as it currently is.

Then, no need to do 'workarounds' anymore.

Co-operative mutablity will no longer be the default. You'll have to opt-in to it.

Now, the compiler will tell you when you're invariants are being compromised.

You won't have to ever 'remember' to 'just not do it'.

On Thursday, 9 June 2022 at 01:04:26 UTC, forkit wrote:
> On Thursday, 9 June 2022 at 00:38:56 UTC, Mike Parker wrote:

> I have no say in this, other than these 'work arounds' that you insist I follow - including the best one yet 'just don't do it'.

I explained that. Here's some code since it apparently wasn't clear what I meant:

```d
class Foo {
    int specialSauce;

    void onlyModifySauceHere(int newVal) {
        assert(newVal > someMin && newVal <= someMax);
        specialSauce = newVal;
    }

    void functionAddedByCluelessTeamMember() {
        specialSauce *= 100;
    }
}
```

How is this problem solved in Java? Don't do it. C++? Don't do it.

In D, if you don't want functions in the module accessing private class members, don't do it. There is no practical difference whatsoever if the offending function is above or below the closing brace.

> I do not have to make the case

You're the one who wants the feature, so yeah, the onus is on you or someone who agrees with you to convince the maintainers of the language that it's a feature worth having. Otherwise, it isn't going to happen.

You've said enough about this topic in this thread and others that you could have written a DIP by now. And both of us are repeating the same points over and over, so I'm done with it.

On Thursday, 9 June 2022 at 01:54:22 UTC, Mike Parker wrote:

>     int specialSauce;

That was supposed to be private, of course.

On Friday, 3 June 2022 at 05:58:06 UTC, Mike Parker wrote:
>
> ...
> In D, given module `mymod`, you can split your aggregates into individual files and make a package module:
>
> ```
> - mymod
> -- package.d
> -- classA.d
> -- classB.d
> -- freefuncs.d
> ```
>
> Then clients can still treat `mymod` as a single module, and you get your ideological purity. But your problem of programmers having access to the private memvers of `ClassA` if they have access to `classA.d` doesn't go away. It's just been moved to a different module.

Those last two lines of your response, is 'my justification'.

i.e. none of the workarounds make the problem go away.

All they do is add totally unnecessary cognitive load, to what should be a really simple, straightforward, design decision - I want this to be private to this class.

Access control decisions should not be dictated to me by D.

Access control is a decision I (the designer) have the right to make, and also the right to expect the compiler to enforce.

Claiming this right to be just 'ideological purity' is a nice distraction ;-)

On Thursday, 9 June 2022 at 01:54:22 UTC, Mike Parker wrote:
>
> You've said enough about this topic in this thread and others that you could have written a DIP by now. And both of us are repeating the same points over and over, so I'm done with it.

In Australian politics, you don't bring a measure to the floor, unless you already have good insight into how that measure will be accepted, or not.

I'd take the same approach with a DIP.

i.e first ascertain what level of support there might be.

If the indication is very little support, don't bother bring the measure to the floor - cause you already know it's going nowhere.

Clearly there is so little support for this simple idea, that it's pointless discussing any further.

Good luck in the contstant explaining to new comers, as to why private doesn't really mean private, and why you have to do various workarounds to simulate it, and why the compiler will never (can never) enforce those decisions, and why D will not even consider an option to let the designer make the decision.

You'll need to provide better arguments though. Cause you're current arguments are not persuasive enough, IMO, to quickly shutdown the discussion of this issue, when it inevitably arises again.

On Thursday, 9 June 2022 at 04:52:13 UTC, Ola Fosheim Grøstad wrote:
>
> ....
> What forkit asks for isn’t unreasonable, the syntax was unreasonable.
>

putting aside the idea of this every being accepted....

as far as syntax goes... i still think an @annotation, rather than a word, or a new word, is the best approach. An annotation seems very consistent with the D style to me.

class myClass
{
  @self private string secret;
}