On Wednesday, 15 June 2022 at 02:15:16 UTC, norm wrote:
> On Wednesday, 15 June 2022 at 01:57:28 UTC, zjh wrote:
>> On Wednesday, 15 June 2022 at 01:21:51 UTC, monkyyy wrote:
>>
>>> Id suggest fixing ancient template bugs and getting several competing compilers going to compete with c++;
>>
>> In any case, we should not be afraid of `change`! not be afraid of `complexity`!
>> Take a look at `'rust'`. It is becoming more and more `complex`. Take a look at `other mainstream languages`. Which is not `complex`?
>>
>> `C++23, c++26` is absolutely monsters! But people don't care!
>
> I find C++ is getting easier to use with each release. Bring on C++23,26,... because each release adds new features that make using C++ that much easier use correctly and harder to use incorrectly.
>
> D's only real problem is people power. That will not be fixed by the constant bickering seen on these forums, it just drives potential developers away if anything. I said it before, instead of worrying about private, which TBH is a tiny issue because what is there now works reliably and well for 99% of code, maybe help D progress with actions not words.
>

That's cause D still very much operates in the small (in more than one way).

languages that have this feature, operate in the large.

when you operate in the large, tighter encapsulation, explicit intent, enforceable design, become very important aspects in developing correct code.

when you operate in the small, these matter a lot less - and so they'll be seen as unnecssary, constraining, and unwelcome, and often result in bickering, as you say.

A lot of this controversy comes back to Walters firm view, that 'the module' is the unit of encapsulation in D, 'and that's all there is too it' attitude.

Of course, anyone from OOP will know that a class is a very important unit of encapsulation in its own right.

What Walter fails to acknowledge in this 'firm view' (apart from the above), is that encapsulation is actually an abstract concept that can apply at any level whatsoever, including at the level of module-level-components (code inside a module).

Indeed most code within a module is already encapsulated in some way (by the code itself, not the module).

A function is encapsulated.

An enum is encapsulated.

Even an int is encapsulated.

A class is encapsulated .. well... actually, no.. it isn't. No in D. You can't do it.

On Tuesday, 14 June 2022 at 23:44:24 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 23:31:35 UTC, forkit wrote:
>>
>> please review that part of his arguement again.
>
> to be specific, it was this part
>
> "The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things."
>
> That is not a valid argument against private(scope).
>
> It an argument against anything.
>
> I demonstrated how invalid this part of his argument is, by referring back to @mustuse (his proposal).
>
> I need arguments against the idea being proposed, not any idea.

Given that 'opportunity cost' is mentioned as the main cost, implies that Paul found nothing technically wrong this new feature; if the idea was unsound etc., I'm sure that it would have been mentioned before this.

Given that 'opportunity cost' was explicitly mentioned (which as you say, is a self-evident cost for any new feature), implies that he believes that the opportunity cost of this nothing-wrong-in-principle private(scope) feature is too high.

I really can't see how @mustuse is relevant to private(scope) benefit-to-cost ratio, beyond the "well, @mustuse got in, so there's no reason for private(scope) not to get in" type argument...but maybe that's just me not understanding the connection.

Jordan

On Wednesday, 15 June 2022 at 02:53:32 UTC, forkit wrote:
>

for an OO programmer, coming to D, to delegate its encapsulation to the module, is an antipattern.

no wonder is causes some much controversy.

delegate a classes encapsulation to the module will come back to haunt him/her... and likely anyone that uses or maintains that code.

I'd recommend OO programmers consider very carefully, whether D is an appropriate choice of language.

On Wednesday, 15 June 2022 at 03:01:19 UTC, Jordan Wilson wrote:
> On Tuesday, 14 June 2022 at 23:44:24 UTC, forkit wrote:
>> On Tuesday, 14 June 2022 at 23:31:35 UTC, forkit wrote:
>>>
>>> please review that part of his arguement again.
>>
>> to be specific, it was this part
>>
>> "The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things."
>>
>> That is not a valid argument against private(scope).
>>
>> It an argument against anything.
>>
>> I demonstrated how invalid this part of his argument is, by referring back to @mustuse (his proposal).
>>
>> I need arguments against the idea being proposed, not any idea.
>
> Given that 'opportunity cost' is mentioned as the main cost, implies that Paul found nothing technically wrong this new feature; if the idea was unsound etc., I'm sure that it would have been mentioned before this.
>
> Given that 'opportunity cost' was explicitly mentioned (which as you say, is a self-evident cost for any new feature), implies that he believes that the opportunity cost of this nothing-wrong-in-principle private(scope) feature is too high.
>
> I really can't see how @mustuse is relevant to private(scope) benefit-to-cost ratio, beyond the "well, @mustuse got in, so there's no reason for private(scope) not to get in" type argument...but maybe that's just me not understanding the connection.
>
> Jordan

Yes. I want to know what is technically wrong with private(scope).

then I can attempt to address that concern.

If we establish that nothing is technically wrong (in terms of the cost of implementing it in particular), and, we establish that it's a useful idea, then we can move to the issue of prioritising the addition of this feature over that feature. It's not that this point is not relevant, its just not relevant at this stage.

This starting to sound like a nice diversion tactic to me ;-)

On Wednesday, 15 June 2022 at 03:10:32 UTC, forkit wrote:
>

oh. I just finally got swift working on windows..took way more effort than I anticipated :-(

so that's where my attention will be for a while..

I'm sure many will be happy to hear this ;-)

On Wednesday, 15 June 2022 at 03:28:10 UTC, forkit wrote:
>

The fact is, this idea has no chance of ever being in D, as Walter is too stuck in his way, and forces OO programmers to fully surrender the encapsulation of a class, to the module. It's just a ridiculous demand.

The approriate response, would be, let's compromise... here's a feature that does exactly what you need, and doesn't impact those who don't need it.

But no... too stubborn.

That's the cause of the controversy. Not the idea. The idea will continue to pop up... the same response will come from Walter, and around..and around... we go....

I'm getting off ;-)

Bye!