Introduce `private(this)` Access Modifier

[CoPilot]

On Friday, 4 July 2025 at 09:26:30 UTC, Peter wrote:
> DIP: xxxx
> Title: Introduce `private(this)` Access Modifier
> Author: [Your Name]
> Status: Draft
> Created: 2025-07-04
>
> ## Abstract
>
> This DIP proposes adding a new access modifier, 
> `private(this)`, that applies only to class and struct members.
> Outside the defining module it behaves identically to `private`.
> Within the module, however, it restricts access to the scope of 
> the declaring type, preventing any other code in the same 
> module from touching it.
>
> ## Rationale
>
> Currently, D’s `private` grants access to all code in the same 
> module.
> While that can simplify internal communication, it undermines 
> encapsulation by allowing unrelated types
> and functions in the same module to directly manipulate class 
> or struct internals.
> Enforcing true type-level privacy strengthens abstraction 
> boundaries and helps maintain invariants.
>
> ## Specification
>
> - Applicable only to class and struct members.
>
> - Outside the defining module, `private(this)` == `private`.
>
> - Inside the defining module:
>   - Only code lexically inside the body of the same class or 
> struct may access the member.
>   - No free functions, mixins, nested types, or other types in 
> the module may access it.
>
> - All existing access rules (transitive private, inheritance, 
> package scopes) remain unchanged.
>
> ## Example
>
> module example;
>
> struct S
> {
>     private(this) int x;    // Only S’s code can touch x
>     int getX() { return x; }
> }
>
> void helper()
> {
>     S s;
>     // s.x = 5;             // Error: x not accessible here
> }
>
> Pros and Cons
> -------------
>
> Pros of not having private(this)
>
>     Simpler access model with just private at module level.
>
>     No new keyword to learn or confuse beginners.
>
>     Existing codebases remain fully functional without change.
>
> Cons of not having private(this)
>
>     Invariants can be broken by unrelated code in the same 
> module.
>
>     Difficult to enforce strict encapsulation; relies on 
> documentation and discipline.
>
>     Module-sized privacy may encourage large modules with weak 
> boundaries.
>
>
> Pros of having private(this)
>
>     Strong, compiler-enforced type-level encapsulation.
>
>     Clearer abstraction boundaries and safer internal 
> invariants.
>
>     Encourages smaller, focused modules and cleaner 
> object-oriented design.
>
> Cons of having private(this)
>
>     Introduces another access modifier and slightly raises 
> language complexity.
>
>     Potential confusion between private and private(this) for 
> new users.
>
>     May require refactoring of existing module-heavy code to 
> satisfy the stricter rules.

This is a well-reasoned and timely proposal—thank you for putting 
it forward.
Motivation and Design

The rationale for private(this) is compelling. D’s current 
private model, while pragmatic, does blur encapsulation 
boundaries within a module. Introducing a stricter, type-scoped 
access modifier would empower developers to enforce invariants 
more robustly and design with clearer abstraction layers.

I especially appreciate that:

     The behavior outside the defining module remains unchanged, 
preserving backward compatibility.

     The feature is opt-in and non-breaking, allowing gradual 
adoption.

     It aligns with modern language trends toward finer-grained 
access control (e.g., Swift’s fileprivate, Kotlin’s internal).

Questions and Clarifications

A few areas I’d love to see clarified or expanded:

     Syntax Choice Why private(this) specifically? It’s readable 
once explained, but might be non-obvious to newcomers. Were 
alternatives like typeprivate, strict private, or a new keyword 
considered?

     Nested Types and Lambdas Would nested types or lambdas 
defined lexically within the class/struct have access to 
private(this) members? If so, it would be helpful to spell that 
out explicitly.

     Mixins and Templates D relies heavily on mixins and 
templates. How would private(this) behave in those contexts? 
Would a mixin inside a class have access? What about a template 
instantiated within the type?

     Tooling and Diagnostics Would the compiler provide clear, 
actionable diagnostics when access is denied due to 
private(this)? This could help reduce confusion and improve 
adoption.

     Migration and Adoption While this is non-breaking, have you 
considered tools or compiler flags to help identify where 
private(this) could be beneficial in existing codebases?
Broader Impact

This proposal encourages better modularity and encapsulation, 
which could lead to cleaner, more maintainable code across the 
ecosystem. It also aligns well with D’s philosophy of giving 
developers precise control when they want it, without forcing 
complexity on those who don’t.

Strong +1 from me on the concept. Looking forward to seeing how 
this evolves!