Code That Says Exactly What It Means

[Peter C]

On Thursday, 30 October 2025 at 22:27:32 UTC, ealot wrote:
> On Thursday, 30 October 2025 at 21:49:45 UTC, Peter C wrote:
>> On Thursday, 30 October 2025 at 13:31:48 UTC, Zealot wrote:
>>>     [...]
>>
>> Thanks for raising the discussion ;-)
>>
>> I think I might be missing your point though (i.e. the code 
>> below works just fine):
>>
>> // ===============
>>
>> module foo;
>> @safe:
>> private:
>>
>> import std;
>>
>> public class A
>> {
>>     scopeprivate int p = 1;
>>     private int a = 42;
>>     protected  int b = 43;
>>     int c = 44;
>> }
>>
>> // ===============
>>
>> module bar;
>> @safe:
>> private:
>>
>> import std;
>> import foo;
>>
>> void main()
>> {
>>     auto a = new A;
>>
>>     static foreach(i; 0..a.tupleof.length)
>>     {
>>         writeln(__traits(getVisibility, a.tupleof[i]), " => ", 
>> a.tupleof[i]);
>>     }
>> }
>>
>> // ===============
>>
>> scopeprivate => 1
>> private => 42
>> protected => 43
>> public => 44
>
> a) tupleof ignores the privacy attributes. tupleof allows you 
> to access private state.
> b) any code that exists and uses getVisibility now has a new 
> case introduced which it doesn't handle, so you would break all 
> that code by introducing scopeprivate.

Reflection is critical to a number of D's standout features - 
e.g. compile-time metaprogramming and generic programming.

Thus, if scopeprivate were introduced, the guiding principle 
*must* be non-breaking behavior for existing reflection code.

So, in theory, existing code that doesn't know about scopeprivate 
won't break, crash or misbehave, but it might need to adapt to a 
new case that it didn't handle before.

That is, the burden will rightly be on the introspection logic 
itself, to filter or update its logic.

That’s the right balance: reflection remains stable, while 
introspection evolves to respect new semantics.