On Tuesday, 14 June 2022 at 07:05:14 UTC, JG wrote:
> On Tuesday, 14 June 2022 at 06:43:36 UTC, forkit wrote:
>> On Tuesday, 14 June 2022 at 06:09:57 UTC, JG wrote:
>>>
>>> I think you are missing part of your analysis. Is this a complete feature you are suggesting to be added? I also haven't thought it through to the end but for instance wouldn't something like "friend" need to be added shortly after adding this?
>>>
>>
>> No. I cannot see how such a concept (of needing to add friend) would ever apply here??
>
> So there is no use case for "friend class" in C++?

My point is, there is no problem making friends in D, cause everyone is already your friend - you got no choice anyway - that's how it is, full stop.

the problem is in the unfriending part.

if you take this too the extreme, as some no doubt will, the argument will be 'well if they're not friends then why put them in the same module?'.

but that's a strawman argument - which results from taking the point to the extreme.

I'm about friends that can have the capacity to keep some part of their existence to themselves, and under their control.

this is what D lacks.

friends are defined by their ability to mutate every aspect of each other.

However, in D they are (cause it lacks this feature I'm suggesting).


>
>>> Another point that you are perhaps missing is that each person who uses D probably has at least one thing they would like added to the language (which they consider to be extremely important). If all these things were added, D would be much more complicated than it is now, even if each is a minor change.
>>>
>>
>> This may be a valid reason for not adding 'any' new feature, but it is not a valid reason for not adding 'this' feature.
>>
>
> Isn't that a bit of a weak answer? Couldn't anybody proposing
> a feature they want answer the same way?
>

To understand the downside of implementing this particular feature, I need to know arguments specific to this feature.

Arguments that can be applied to any feature are not relevant, in this context, that is what I'm saying here.

The argument put forward relates to 'change' in general. Not this feature, specifically.


>>
>>> In reading what you wrote I didn't find the following clear:
>>>
>>>> However, the one-class-per-module approach, imposes its own new design constraint, and not one the programmer necessarily makes of his/her own volition.
>>>
>>>
>>>> It also does not necessarily follow, that a class in its own module, is there for the purposes of stipulating this constraint.
>>
>> Putting one class in a module by itself, means no other code except that class is in that module, and therefore the class does not need to 'hide' anything from any other code in the module - cause there isn't any other code in the module.
>>
>> But putting one class in a module by itself, demonstrates no intent whatsoever.
>>
>> You have to ask the designer why they chose to do that.
>>
>> The option suggested would 'explicately' specify an intent, and can do so *without* enforcing a one-class-per-module design constraint onto the programmer.
>
>
> If what you say were true, couldn't we say that from now on putting
> a class alone in a module shows the intent of making private mean
> private to the class?

any convention can be used to indicate intent.

I don't wont to indicate intent.

I want to explicately state intent. I want the compiler to enforce that intent.
I want anyone reading my code, to immediately understand my intent, and not rely on them understanding my 'conventions'.

On Wednesday, 15 June 2022 at 01:51:41 UTC, forkit wrote:
>
> ...
> friends are defined by their ability to mutate every aspect of each other.
>
> However, in D they are (cause it lacks this feature I'm suggesting).
>

ooops. of course:

"friends are defined by their ability to mutate every aspect of each other."

should have been:

"friends **aren't** defined by their ability to mutate every aspect of each other."

On Tuesday, 14 June 2022 at 11:22:58 UTC, Paul Backus wrote:
>
> ...
> Sure, you could make an argument that the effort spent on @mustuse could have been better spent elsewhere.
>
> The main difference between @mustuse and private(scope) is that @mustuse was *impossible* to simulate using existing language features, whereas private(scope) can be simulated by extracting the relevant code into its own dedicated module. I understand that you have reasons for disliking this workaround, but the fact that a workaround exists is still relevant when determining what ought to be prioritized.
>

I don't accept this argument either, because to 'simulate' private(scope) using the one-class-per-file approach, you must be willing to accept a considerable design constraint - i.e. one-class-per-module.

The cost of simulating, is too high. that is my point here.

It's not about disliking the workaround suggestion. It's about the cost of doing it.

Also, it's not actually simulating private(scope) anyway, not by any stretch of the imagination, since there is no other code besides the class, in that file.

It's just a workaround to avoid the need for private(scope), but at a considerable cost to the design choice you're then forced to accept in return.

To take a qoute of the internet:

"Having 17k line classes can be confusing, 17k line files with 170 classes in it can be confusing, having 170 classes in 170 files can be confusing.".