Flattened Property Composition: A Type-Safe and Declarative Alternative to Inheritance in C#

[humayunkhan]

Summary
C# currently lacks a native, concise, and type-safe way to include properties of one class in another without using inheritance or manually duplicating properties. This proposal suggests introducing a new feature that allows flattened property composition using the include keyword, enabling developers to declaratively reuse properties from another class while adding their own. This feature simplifies code, reduces redundancy, and improves maintainability.

Motivation
Currently, to reuse properties of one class (e.g., ClassA) in another class (e.g., ClassB), developers must:

• Use inheritance, which is often not suitable for all scenarios, particularly when the "is-a" relationship does not hold.
• Manually duplicate properties from ClassA into ClassB, leading to potential maintenance issues if ClassA changes.
• Use composition, resulting in nested structures that may not align with the desired flat structure.

None of these solutions provides an ideal balance of simplicity, type safety, and maintainability. A native feature for flattened property composition would address these shortcomings.

Proposed Syntax

1. Basic Syntax

public class ClassA
{
    public int Property1 { get; set; }
    public string Property2 { get; set; }
}

public class ClassB
{
    include ClassA;  // Includes Property1 and Property2 as direct properties of ClassB

    public bool Property3 { get; set; }
    public DateTime Property4 { get; set; }
}

Equivalent generated code:

public class ClassB
{
    public int Property1 { get; set; }
    public string Property2 { get; set; }
    public bool Property3 { get; set; }
    public DateTime Property4 { get; set; }
}

2. Handling Read-Only Properties
The include keyword respects readonly and private set properties:

public class ClassA
{
    public string Name { get; } = "John";   // Read-only
    public int Age { get; private set; } = 30;  // Private setter
}

public class ClassB
{
    include ClassA;
}

Equivalent generated code:

public class ClassB
{
    public string Name { get; } = "John";   // Preserves readonly
    public int Age { get; private set; } = 30;  // Private setter preserved
}

3. Delegation for Properties with Logic
Properties with custom logic or private dependencies are automatically delegated:

public class ClassA
{
    public int ComputedValue => CalculateValue();
    private int CalculateValue() => 42;
}

public class ClassB
{
    include ClassA;
}

Equivalent generated code:

public class ClassB
{
    private ClassA _a = new ClassA();
    public int ComputedValue => _a.ComputedValue;  // Delegated automatically
}

4. Handling Properties with Side Effects
Properties with interdependencies are also delegated to preserve side effects:

public class ClassA
{
    private int _age;
    public int Age
    {
        get => _age;
        set
        {
            _age = value;
            YearsUntilRetirement = 65 - _age;
        }
    }
    public int YearsUntilRetirement { get; private set; }
}

public class ClassB
{
    include ClassA;
}

Equivalent generated code:

public class ClassB
{
    private ClassA _a = new ClassA();
    public int Age
    {
        get => _a.Age;
        set => _a.Age = value;  // Preserves setter logic
    }
    public int YearsUntilRetirement => _a.YearsUntilRetirement;
}

5. Conflict Resolution
If two included classes define properties with the same name, the compiler throws an error unless resolved explicitly:

public class ClassC { public int SharedProperty { get; set; } }
public class ClassD { public int SharedProperty { get; set; } }

public class ClassE
{
    include ClassC;
    include ClassD;  // Conflict: SharedProperty
}

Potential Solution: Use aliasing:

include ClassC as C;
include ClassD as D;

// Properties accessible as C.SharedProperty and D.SharedProperty

6. Customization with "with" Clause
Developers can customize inclusion behavior with a with clause:

public class ClassA
{
    public string Name { get; } = "John";
    public int Age { get; private set; } = 30;
    public int ComputedValue => 42;
}

public class ClassB
{
    include ClassA with
    {
        Name as Flattened;     // Directly includes 'Name'
        Age as Delegated;      // Delegates 'Age' to ClassA
        ComputedValue as Ignored;  // Ignores 'ComputedValue'
    };

    public string AdditionalProperty { get; set; }
}

Equivalent generated code:

public class ClassB
{
    private ClassA _a = new ClassA();

    public string Name { get; } = "John";   // Flattened
    public int Age
    {
        get => _a.Age;
        set => _a.Age = value;              // Delegated
    }
    public string AdditionalProperty { get; set; }  // Custom
}

Features and Benefits

1. Type-Safe Property Inclusion: Properties included via include are fully type-checked at compile time.
2. Flattened Structure: The properties from ClassA become direct properties of ClassB without requiring nesting.
3. Minimal Boilerplate: Reduces repetitive code by eliminating manual property duplication.
4. Easy Maintenance: Changes to ClassA automatically propagate to ClassB, ensuring consistency.

Comparison to Existing Features

• Inheritance: include is more flexible as it avoids enforcing an "is-a" relationship.
• Composition: Unlike declaring a property of type ClassA, include results in a flat structure, which is often more desirable in DTOs and other data structures.
• Source Generators: While source generators can automate property duplication, they require additional setup and do not integrate natively with the language.

Use Cases

1. Data Transfer Objects (DTOs): Simplify the creation of flattened DTOs that aggregate properties from multiple sources.
2. Configuration Classes: Include common configuration properties in multiple classes without duplication.
3. Model Composition: Enable modular and reusable model definitions in domain-driven design.

Corner Cases and Challenges

1. Circular Dependencies
Problem:
If two classes include each other directly or indirectly, infinite recursion could occur during compilation.

Example (Circular Dependency):

public class ClassX
{
    include ClassY;  // Refers to ClassY
}

public class ClassY
{
    include ClassX;  // Refers back to ClassX (circular)
}

Solution (Compiler Check):
The compiler should detect such cases and throw a compilation error like:

Error: Circular dependency detected between ClassX and ClassY.

2. Versioning and Compatibility
Problem:
Changes in the included class could break dependent classes if properties are renamed, removed, or modified.

Example (Breaking Change):

// Original Definition
public class ClassA
{
    public string Property1 { get; set; }
    public int Property2 { get; set; }
}

public class ClassB
{
    include ClassA;  // Works fine initially
}

If ClassA changes like this:

// Breaking Change: Property2 removed
public class ClassA
{
    public string Property1 { get; set; }
}

The compiler should raise an error:

Error: Property 'Property2' is not defined in 'ClassA' but is expected by 'ClassB'.

Solution (Selective Inclusion):

public class ClassB
{
    include ClassA { Property1 };  // Only includes specific properties
}

Generated Code:

public class ClassB
{
    public string Property1 { get; set; }
}

3. Reflection and Metadata
Overview:
The include feature should work seamlessly with C#'s reflection system to support tools like serializers, validation frameworks, and ORMs. This includes metadata propagation, custom attributes, and conflict resolution.

Reflection Scenarios and Solutions:

Property Discovery in Reflection
Example (Expected Reflection Output):

public class ClassA
{
    public int Property1 { get; set; }
}

public class ClassB
{
    include ClassA;
    public string CustomProperty { get; set; }
}

Reflection Code:

foreach (var prop in typeof(ClassB).GetProperties())
{
    Console.WriteLine(prop.Name);  
}

Expected Output:

Property1
CustomProperty

Solution:
Properties generated through include should be fully discoverable using Type.GetProperties().

Metadata Propagation
Example (Data Annotations for Validation):

using System.ComponentModel.DataAnnotations;

public class ClassA
{
    [Required]
    [StringLength(10)]
    public string Name { get; set; }
}

public class ClassB
{
    include ClassA;
    public int Age { get; set; }
}

Validation Code:

var obj = new ClassB { Name = null, Age = 25 };  // Missing required Name
var context = new ValidationContext(obj);
var results = new List<ValidationResult>();

bool isValid = Validator.TryValidateObject(obj, context, results, true);
Console.WriteLine(isValid);  // Expected: False

Solution:

The compiler should automatically copy metadata attributes from the source class properties (ClassA) to the generated properties in the target class (ClassB).

Custom Attribute Customization
Example (Custom Attribute Override):

[AttributeUsage(AttributeTargets.Property)]
public class CustomAttribute : Attribute
{
    public string Description { get; }
    public CustomAttribute(string description) => Description = description;
}

public class ClassA
{
    [Custom("Original Description")]
    public string Info { get; set; }
}

public class ClassB
{
    include ClassA with
    {
        Info as Flattened with [Custom("Overridden Description")]; 
    };
}

Reflection Code:

var infoProp = typeof(ClassB).GetProperty("Info");
var customAttr = (CustomAttribute)infoProp.GetCustomAttribute(typeof(CustomAttribute));
Console.WriteLine(customAttr.Description);  // Expected: "Overridden Description"

Solution:

The compiler should support metadata overrides using the with clause for fine-grained control.

Origin Metadata Tracking
Example (Metadata Annotations for Property Origins):
The compiler could automatically generate a special attribute like [GeneratedProperty] for included properties:

[GeneratedProperty("IncludedFrom", "ClassA")]
public string Name { get; set; }

Reflection Code:

foreach (var prop in typeof(ClassB).GetProperties())
{
    var metadataAttr = prop.GetCustomAttribute<GeneratedPropertyAttribute>();
    if (metadataAttr != null)
    {
        Console.WriteLine($"{prop.Name} was included from {metadataAttr.SourceClass}");
    }
}

Expected Output:

Name was included from ClassA

Metadata Conflicts
Example (Conflicting Attributes):

public class ClassA
{
    [Display(Name = "Original Name")]
    public string Name { get; set; }
}

public class ClassB
{
    include ClassA with
    {
        Name as Flattened with [Display(Name = "Overridden Name")];
    };
}

Reflection Code:

var nameProp = typeof(ClassB).GetProperty("Name");
var displayAttr = (DisplayAttribute)nameProp.GetCustomAttribute(typeof(DisplayAttribute));
Console.WriteLine(displayAttr.Name);  // Expected: "Overridden Name"

Solution:

• If a property is redefined using the with clause, custom attributes override inherited attributes.
• If no custom attributes are defined, the compiler propagates original attributes from the source class (ClassA).

4. Immutable Record Types
Problem:
Including mutable properties in immutable records would break immutability principles.

Example (Invalid Use):

public class ClassA
{
    public int Property1 { get; set; }  // Mutable
}

// Attempting to include mutable properties in an immutable record
public record ClassB
{
    include ClassA;  // Violates immutability
}

Solution (Enforce Immutability):
The compiler should enforce immutability rules for included properties in records:

public class ClassA
{
    public int Property1 { get; init; }  // Immutable
}

public record ClassB
{
    include ClassA;  // Allowed, properties must be init-only
}

Generated Code:

public record ClassB
{
    public int Property1 { get; init; }
}

5. Overuse and Abuse
Problem:
Developers might overuse the feature, creating bloated classes with too many properties.

Example (Overuse):

public class ClassA
{
    public int PropA1 { get; set; }
    public int PropA2 { get; set; }
}

public class ClassB
{
    public int PropB1 { get; set; }
    public int PropB2 { get; set; }
}

public class ClassC
{
    include ClassA;
    include ClassB;
    public int AdditionalProperty { get; set; }
}

Solution (Best Practices & Static Analysis):

• Provide best practice guidelines (e.g., avoid including too many classes).
• Add static analysis checks to detect excessive property inclusion and suggest refactoring.

A similar proposal
#5897

Conclusion
The include keyword enables simplified property composition while maintaining type safety, reducing boilerplate, and offering customization. It complements existing C# features like inheritance, composition, and source generators while offering a more concise and native experience.

[HaloFour]

You could use a struct to define the data members and use a source generator to create the delegating properties.

I don't see this as a language feature as it wouldn't work well at all across assembly boundaries as the internal state of a class may not be known at the time of compilation or could change between compilation and runtime.

[CyrusNajmabadi]

No Additional Setup: Using SGs requires additional NuGet packages, MSBuild configuration, and sometimes extra tooling that developers might want to avoid.

This is not a compelling reason to push something into the language. Indeed, it actively pushes against doing that. A nuget package (both authoring and consumption) is generally on the order of 3 or more orders of magnitude less costly than doing a language feature. If this can be solved with an SG, it means it can be delivered in a single day, instead of taking 3+ years to get it. It means everyone can use it today, on many existing compilers, instead of needing everyone to update to a new compiler to get it. Etc. etc. etc :)

[humayunkhan]

I understand the argument that using a Source Generator (SG) could deliver functionality faster, but I believe that relying on SGs for core language features comes with significant trade-offs. While SGs are powerful, they don’t provide the same level of integration, developer experience, and long-term ecosystem consistency as built-in language features. Here’s why the include keyword deserves to be part of the C# language itself:

1. SGs Are Not a Substitute for a Language Feature

• SGs generate code behind the scenes, requiring developers to manage generated partial classes mentally. This can cause readability issues and make the developer experience less intuitive.
• Language features integrate directly into the language syntax, ensuring first-class IDE support like IntelliSense, refactorings, navigation, and error messages. SGs cannot provide the same level of native tooling support without significant manual setup.

2. Long-Term Value Beats Short-Term Delivery

• While it’s true that an SG can be developed and delivered much faster, speed of delivery shouldn’t trump design elegance and long-term value.
• Compiler-backed language features provide:
  • Better Error Messages: Integrated with the IDE and compiler for precise diagnostics.
  • Static Code Analysis: Enforced by the compiler itself, ensuring correctness.
  • Code Maintainability: Developers work with real properties, not hidden generated code.

3. Example: Records in C# (Introduced in C# 9)
Consider Records, a feature introduced in C# 9, which took several years of design discussions and multiple proposals before becoming part of the language. Before records were added:

• Developers used manual property declarations and boilerplate equality checks.
• Community projects like Fody.PropertyChanged and AutoMapper emerged, attempting to solve some of these issues using PostSharp-style SG-like techniques.

When Records were finally added after years of discussion, they:

• Simplified Data Models: Developers could create immutable models with minimal syntax.
• Reduced Boilerplate: Equality, hash code, and deconstruction were auto-generated.
• Enhanced Readability: The code became cleaner, reducing developer burden.

Before Records (Manual Work):

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public override bool Equals(object obj) =>
        obj is Person p && Name == p.Name && Age == p.Age;

    public override int GetHashCode() => HashCode.Combine(Name, Age);
}

After Records (Built-In Support):

public record Person(string Name, int Age);

Why It Matters:
Had the C# team settled for "just use a Source Generator," the solution would have been fragmented, harder to maintain, and less integrated into the ecosystem. Adding Records as a language feature provided clean syntax, compiler support, and IDE tooling, making C# development significantly more productive.

4. Complexity and Setup Overhead with SGs

• SGs require NuGet packages, MSBuild configuration, and additional tooling, which adds extra project setup complexity.
• Enterprise developers often avoid external dependencies due to security policies, maintenance concerns, or project constraints. A language feature would just work out of the box.

5. Developer Experience Matters

• Not all developers are familiar with SGs or how to configure them correctly.
• Debugging and Code Discovery are harder with SGs since generated code is hidden unless explicitly exposed.
• A language feature like include would be intuitive, discoverable, and supported by the IDE without requiring custom tools.

6. Ecosystem Fragmentation
Relying on SGs would likely result in multiple competing implementations published on NuGet, fragmenting the ecosystem. Developers would need to compare and evaluate different SG packages, each with different feature sets and limitations.

Standardized language features prevent fragmentation and ensure consistent developer experiences across projects.

Conclusion
While SGs are great for niche scenarios and custom code generation, they aren’t a replacement for core language features when the feature targets code simplicity, developer experience, and native IDE support. The example of C# Records shows how waiting for the right feature implementation can provide immense long-term value, even if it takes more time.

I hope this provides additional context on why I believe include deserves to be part of the C# language itself. I’d be glad to continue refining the proposal based on further feedback.

Thank you for considering these points!

[HaloFour]

While SGs are powerful, they don’t provide the same level of integration, developer experience, and long-term ecosystem consistency as built-in language features.

You're right, they don't. But they have the distinct advantage that you could build this capability and start using it today. The best case scenario for a language feature is that it takes about three years to go through design before it has the possibility of showing up in a release, and I can guarantee you that this proposal has no chance of even that happening.

[HaloFour]

Yes, records could have been implemented via source generators. But there was an enormous amount of feedback from the community over a long period of time that records were a kind of feature that they wanted to be first class citizens, which is why the language team decided to implement them as such. That is an exceptionally rare scenario, and is certainly not the case here.

Source generators were added to the compiler and tooling very specifically to make it possible for developers to solve these kinds of problems for themselves. They are not intended for niche scenarios, and the fact that two generators might appear on NuGet with competing implementations is definitely considered to be a good thing.

[jaredpar]

Yes, records could have been implemented via source generators.

It could have but it wouldn't have been nearly as vibrant. In particular the use of the with construct made records significantly more usable when mutations come into play. The work around inheritance could've been done with generators but it would've been more fragile than the language implemented version. Those and a few other items ended up pushing it over the edge to be a language feature vs. generator.

I understand the argument that using a Source Generator (SG) could deliver functionality faster, but I believe that relying on SGs for core language features comes with significant trade-offs

What about this though would move it to core language feature? The end product of this is a type with more members, members that could easily have been written by hand or a generator. To make this argument I think it would be good to basically compare / contrast what could be done with this proposal compared to say a generator triggered on [Include(typeof(ClassA))].

Basically

public class ClassA { ... } 
public class ClassB 
{
  include ClassA;
}

// vs. 

public class ClassA { ... } 
[Include(typeof(ClassA))]
public class ClassB { ... }

What impact would that have on developers using ClassB?