Adding a new design constraint to D

[forkit]

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'.