[Proposal]: Allow / Allowed — Per-method caller whitelisting

[philipkalimo]

Proposal: allow/allowed — Per-method caller whitelisting

https://github.com/philipkalimo/csharp-allow-allowed.git

---

Summary

Introduce two new access-control constructs for C#:

1. allow<T...> — a class-level trust list specifying which classes or groups the class is willing to expose certain members to.
2. allowed<T...> — a method-level caller whitelist, specifying exactly which classes or interfaces can invoke a given member.

This allows precise, compile-time enforced encapsulation, reducing accidental misuse of APIs and simplifying code that currently requires internal facades or friend-style patterns.

---

Motivation

• Current access modifiers (private, protected, internal, public) are coarse-grained.
• Some scenarios require fine-grained, predictable relationships between classes, e.g., a Weapon class exposing certain methods only to a Handler class.
• allow/allowed enables these relationships to be declared directly in the type system, with compile-time enforcement and no runtime overhead.

---

Syntax / Examples

Class-level trust list:

class Weapon allow<Handler, WeaponSystem> { 
    // Weapon trusts Handler and WeaponSystem for access
}

Method-level whitelist:

class Weapon allow<Handler> {
    allowed<Handler> void Reload() { /* callable only by Handler */ }
    allowed<WeaponSystem> void Fire() { /* callable only by WeaponSystem */ }
    void InternalCheck() { /* default visibility */ }
}

Interface-based allowance:

interface IWeaponController { }
class Weapon {
    allowed<IWeaponController> void Aim() { }
}
// Any class implementing IWeaponController may call Aim()

Group wildcard (optional):

group CombatTeam { Handler, AIController }
class Weapon allow<@CombatTeam> {
    allowed<@CombatTeam> void Configure() { }
}

---

Semantics

1. Method-level allowed overrides class-level allow.

2. Calls from classes not listed result in a compile-time error: ERR_NOT_ALLOWED_CALLER.

3. Interfaces and inheritance respect allowed rules:

   • Derived or implementing classes cannot broaden the allowed set.

4. Optional support for generics, groups, and namespaces for scalable use.

---

Implementation Notes

• Minimal prototype: transpiler/preprocessor converting allow/allowed to existing C# constructs.
• Analyzer approach: Roslyn-based analyzer enforcing rules and producing clear compile-time diagnostics.
• Core language integration: full compiler support for metadata, IDE tooling, and runtime optimization.

---

Benefits

• Predictable code relationships between classes.
• Strong compile-time enforcement of access rules.
• Reduces accidental API misuse, improves maintainability.
• Backwards compatible — existing code continues to work.

[CyrusNajmabadi]

This is already doable in the language. Use attributes to demarcate the types of interest (attributes can be generic, or can use typeof(T) in them). THen, as you say:

Analyzer approach: Roslyn-based analyzer enforcing rules and producing clear compile-time diagnostics.

You just write an analyzer that checks with whatever rules you care about.

[philipkalimo]

Thanks for pointing that out yes, I agree that attributes + Roslyn analyzers could approximate the feature today. In fact, I think that’s a great way to prototype the behavior.

Where I think a language-level feature would still add value:

Discoverability & readability: allowed is immediately clear in the method signature, whereas attributes are easy to overlook.

Ergonomics: Attributes require boilerplate and extra analyzer setup, whereas keywords are concise and built-in.

Tooling support: With language keywords, IDEs, refactoring tools, and documentation generators would treat caller restrictions as a first-class part of the API.

Consistency with existing modifiers: Keywords like private/protected/internal already exist; allowed fits naturally in that family.

So I definitely see analyzers as a good stepping stone (and even a way to validate demand), but my hope with this proposal is to elevate caller-specific access control into the language itself, making it as natural as private or protected.

[333fred]

See all of the discussions on friend accessibility, including #2073, #9261 (this is a near-exact duplicate, just with a different keyword), #9523, #8830, and others.

[philipkalimo]

Attributes + analyzers can enforce access rules, but they are less reliable in practice. Attributes alone don’t stop unauthorized calls, and analyzers require extra setup and maintenance in every project. In environments like Unity, analyzers aren’t automatically executed by the editor, so enforcement can fail silently. A native allow/allowed feature would be automatic, clear in the code, and reliably enforced by the compiler.

[HaloFour]

That sounds like a problem with Unity tooling that they should address. Analyzers are a core part of the C# compiler and expected to be used to enforce project policy just like this use case.

[HaloFour]

Either way, an analyzer would be the way to implement such a feature at this time. As you mentioned, that would prove out the design and identify the audience that would benefit from this feature, which would be necessary to determine if it would be worth the enormous amount of effort required to implement as a language feature.

[philipkalimo]

Thanks for the clarification! I understand that the Unity-specific concerns are outside the scope of the language discussion. I just wanted to provide context for one real-world scenario where this feature could be valuable.

I’ll focus on prototyping with an analyzer to validate the design and demonstrate its usefulness, and I look forward to any further feedback on the language-level implementation itself.

[ufcpp]

If you're worried about Unity, Unity won't support C# vNext either.