Integrated Reflection API for Simplified Property Access in C#

[SoftwareLey]

Abstract:
This proposal introduces a built-in reflection mechanism that simplifies access to object properties without requiring developers to rely on the traditional Type API. By providing intuitive methods for property existence checks and value retrieval or assignment, this feature aims to streamline dynamic scenarios, especially in JSON serialization and deserialization workflows.

Motivation:
Currently, working with reflection in C involves the use of complex APIs like 𝚃𝚢𝚙𝚎.𝙶𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚒𝚎𝚜 and 𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝙸𝚗𝚏𝚘.𝙶𝚎𝚝𝚅𝚊𝚕𝚞𝚎, which can lead to verbose and error-prone code. This complexity becomes particularly evident when dealing with dynamic objects (e.g., 𝙴𝚡𝚙𝚊𝚗𝚍𝚘𝙾𝚋𝚓𝚎𝚌𝚝) or scenarios involving JSON manipulation. The proposed feature would enhance developer productivity by allowing simpler and more intuitive access to object metadata.

𝐏𝐫𝐨𝐩𝐨𝐬𝐞𝐝 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧:
Introduce a set of universal extension methods for all objects that provide clean and efficient access to properties without needing to interact directly with 𝚃𝚢𝚙𝚎.

𝐊𝐞𝐲 𝐅𝐞𝐚𝐭𝐮𝐫𝐞𝐬:

1. 𝐏𝐫𝐨𝐩𝐞𝐫𝐭𝐲 𝐄𝐱𝐢𝐬𝐭𝐞𝐧𝐜𝐞 𝐂𝐡𝐞𝐜𝐤: A method like 𝙷𝚊𝚜𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢(𝚜𝚝𝚛𝚒𝚗𝚐 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝙽𝚊𝚖𝚎) to determine if an object contains a specific property.
2. 𝐏𝐫𝐨𝐩𝐞𝐫𝐭𝐲 𝐑𝐞𝐭𝐫𝐢𝐞𝐯𝐚𝐥: A method like 𝙶𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝚅𝚊𝚕𝚞𝚎(𝚜𝚝𝚛𝚒𝚗𝚐 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝙽𝚊𝚖𝚎) to retrieve the value of a given property safely.
3. 𝐏𝐫𝐨𝐩𝐞𝐫𝐭𝐲 𝐀𝐬𝐬𝐢𝐠𝐧𝐦𝐞𝐧𝐭: A method like 𝚂𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝚅𝚊𝚕𝚞𝚎(𝚜𝚝𝚛𝚒𝚗𝚐 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝙽𝚊𝚖𝚎, 𝚘𝚋𝚓𝚎𝚌𝚝 𝚟𝚊𝚕𝚞𝚎) to set the value of a given property dynamically.

𝐂𝐨𝐝𝐞 𝐄𝐱𝐚𝐦𝐩𝐥𝐞𝐬:

𝚌𝚜𝚑𝚊𝚛𝚙
// 𝙲𝚑𝚎𝚌𝚔𝚒𝚗𝚐 𝚒𝚏 𝚊 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚢 𝚎𝚡𝚒𝚜𝚝𝚜
𝚒𝚏 (𝚘𝚋𝚓.𝙷𝚊𝚜𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢("𝙽𝚊𝚖𝚎"))
{
𝙲𝚘𝚗𝚜𝚘𝚕𝚎.𝚆𝚛𝚒𝚝𝚎𝙻𝚒𝚗𝚎($"𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢 '𝙽𝚊𝚖𝚎' 𝚎𝚡𝚒𝚜𝚝𝚜: {𝚘𝚋𝚓.𝙶𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝚅𝚊𝚕𝚞𝚎("𝙽𝚊𝚖𝚎")}");
}

// 𝚂𝚎𝚝𝚝𝚒𝚗𝚐 𝚊 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚢 𝚟𝚊𝚕𝚞𝚎 𝚍𝚢𝚗𝚊𝚖𝚒𝚌𝚊𝚕𝚕𝚢
𝚘𝚋𝚓.𝚂𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝚅𝚊𝚕𝚞𝚎("𝙰𝚐𝚎", 𝟹𝟷);

// 𝙳𝚢𝚗𝚊𝚖𝚒𝚌𝚊𝚕𝚕𝚢 𝚛𝚎𝚝𝚛𝚒𝚎𝚟𝚒𝚗𝚐 𝚙𝚛𝚘𝚙𝚎𝚛𝚝𝚒𝚎𝚜 𝚠𝚒𝚝𝚑𝚘𝚞𝚝 𝚝𝚑𝚛𝚘𝚠𝚒𝚗𝚐 𝚎𝚡𝚌𝚎𝚙𝚝𝚒𝚘𝚗𝚜
𝚟𝚊𝚛 𝚟𝚊𝚕𝚞𝚎 = 𝚘𝚋𝚓.𝙶𝚎𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢𝚅𝚊𝚕𝚞𝚎("𝙽𝚘𝚗𝙴𝚡𝚒𝚜𝚝𝚎𝚗𝚝𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢");
𝚒𝚏 (𝚟𝚊𝚕𝚞𝚎 == 𝚗𝚞𝚕𝚕)
{
𝙲𝚘𝚗𝚜𝚘𝚕𝚎.𝚆𝚛𝚒𝚝𝚎𝙻𝚒𝚗𝚎("𝙿𝚛𝚘𝚙𝚎𝚛𝚝𝚢 𝚍𝚘𝚎𝚜 𝚗𝚘𝚝 𝚎𝚡𝚒𝚜𝚝.");
}

𝐔𝐬𝐞 𝐂𝐚𝐬𝐞𝐬:

• Dynamic JSON handling: Simplify serialization/deserialization workflows.
• Framework development: Improve accessibility for library authors working with dynamic types.
• General productivity: Provide an elegant solution for property management in loosely typed scenarios.

𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐂𝐨𝐧𝐬𝐢𝐝𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬:
The implementation would leverage existing reflection mechanisms under the hood, optimized to minimize overhead while maintaining C's strong performance guarantees.

Benefits:

• Enhanced readability and conciseness of code.
• Reduction in boilerplate for reflection-heavy operations.
• Streamlined support for scenarios like JSON serialization/deserialization with ExpandoObject.

[yaakov-h]

This sounds like a change for a third-party library or https://github.com/dotnet/runtime and has no bearing on the C# language.

[SoftwareLey]

Thank you for the feedback! You’re absolutely right—this proposal might be more suited for the .NET runtime or libraries rather than being part of the C# language itself. I'll take your advice and move this to the appropriate repository (dotnet/runtime).
The idea focuses on improving the developer experience when working with dynamic objects like and JSON serialization/deserialization scenarios, which would align well with the runtime and associated libraries. I appreciate your input and will revise and resubmit it in the correct context. Thanks again for pointing this out!

[CyrusNajmabadi]

Could this not just be provided simply with extension methods that defer to the actual runtime apis under the covers?

[CyrusNajmabadi]

The suggested syntax (obj["PropertyName"]) is aimed at bridging this gap by introducing a streamlined, integrated approach

I don't know why that syntax would be any better than a syntax like: obj["prop", defaultValue] which would be possible with what we are providing in the language. You're not selling me on why this dedicated syntax is so critical, especially as it doesn't seem particularly clear, nor does it seem to save over what can already be done:

obj[<DefaultValue>"PropertyName"]
obj["PropertyName", DefaultValue]

This could lead to notable performance improvements, as the compiler could generate tailored code

Please be specific as to the code the compiler could generate in these cases.
The latter is also shorter and easy to read.

[CyrusNajmabadi]

it is about improving the elegance and usability of working with dynamic types in C#

The point i'm trying to make here is that it doesn't seem to improve that. The elegance and usability you are asking for already seems possible today with the tools available (and the 'indexer' part is coming in C# 14, which solve this and a far broader swath of concerns).

[CyrusNajmabadi]

but effortless and efficient,

Please be crisp here. Can you show how the proposal here produces a result that requires less effort than the options we've pointed out are already available?

Also, wrt efficiency, please provide some sort of example of how the compiler could/would be more efficient here, vs what any normal code could do in the approaches we've already mentioned. :)

If hte argument is that these suggestions are better, then that needs actual demonstrations that that is the case.

[SoftwareLey]

After further reflection on the concept, I have rethought the approach and now propose a slightly refined syntax. This updated version aims to make the feature more universal and clearer while retaining its elegance and power. Below is a fully commented example that demonstrates how the enhanced {} syntax can significantly simplify dynamic object manipulation in C#, while also ensuring flexibility and consistency with the language’s principles.

---

Code Example and Comments

using System;
using System.Dynamic;

class Program
{
    static void Main()
    {
        /*
         * Suggestion for Discussion:
         * 
         * The following code demonstrates a proposed language extension for C# 
         * that uses a new syntax with {} brackets. This syntax allows developers 
         * to work seamlessly with dynamic objects (like ExpandoObject) and even 
         * anonymous types using Reflection behind the scenes.
         * 
         * Benefits of this approach:
         * 1. Automatic Extension: 
         *    - When using obj{"Invoice.Customer"} = "Herbert", the compiler
         *      is instructed to use Reflection to look for the property "Invoice.Customer".
         *      If it doesn't exist, the object is automatically extended with this property.
         *
         * 2. Nesting Made Trivial:
         *    - You can specify nested properties such as "Invoice.Customer.Address.Street" 
         *      all in one go, and the necessary nested objects will be created dynamically.
         *
         * 3. Type Safety with Generics:
         *    - Syntax like obj<string>{"Test.Data"} explicitly indicates that the expected
         *      value is of type string. This enforces type checks and ensures that any incompatible
         *      types cause a runtime exception, preventing subtle bugs.
         *
         * 4. Built-In Existence Check:
         *    - The addition of a method like .Exists() (e.g., obj{"x"}.Exists()) provides a built-in 
         *      way to check if a property exists before attempting to use it.
         *
         * This elegant extension reduces boilerplate code and improves the readability and maintainability 
         * of code that interacts with dynamic or loosely-typed objects.
         */

        // Create a dynamic object using ExpandoObject which supports runtime extension.
        dynamic obj = new ExpandoObject();

        // 1. Simple dynamic property assignment: Automatically creates "Invoice.Customer" if it doesn't exist.
        obj{"Invoice.Customer"} = "Herbert";
        Console.WriteLine($"Customer: {obj{"Invoice.Customer"}}"); // Output: Herbert

        // 2. Nested property assignment: Dynamically creates nested properties.
        obj{"Invoice.Customer.Address.Street"} = "Main Street";
        Console.WriteLine($"Street: {obj{"Invoice.Customer.Address.Street"}}"); // Output: Main Street

        // 3. Generic type-specific access: Ensures that "Test.Data" is a string.
        //    If the property exists but is not a string, an exception is thrown.
        obj<string>{"Test.Data"} = "Default Value";
        Console.WriteLine($"Test.Data: {obj<string>{"Test.Data"}}"); // Output: Default Value

        // 4. Existence check: Verifies whether the property "Invoice.Customer" exists.
        if (obj{"Invoice.Customer"}.Exists())
        {
            Console.WriteLine("The property 'Invoice.Customer' exists.");
        }
    }
}

---

Conclusion

I think, this approach is elegant and intuitive because the {} syntax inherently signals that Reflection will be used for access. Even when the object is of type object, the use of this syntax ensures that the compiler assumes it is a dynamic object and utilizes Reflection appropriately. This flexibility becomes particularly important when the object type might be passed to a function as object. Developers can work confidently, knowing that dynamic expansion and manipulation will work seamlessly, regardless of whether the object originated from ExpandoObject, anonymous types, or another dynamic structure.

By removing ambiguity and streamlining dynamic programming in C#, this proposal has the potential to unlock a wealth of new possibilities for the language. It minimizes boilerplate code, improves readability, and allows for more expressive and developer-friendly syntax. This refined approach, coupled with its power and clarity, can drive innovation and further enhance the elegance of C#.

Thank you for engaging in this discussion, and I sincerely hope this proposal resonates and hits the right note for further exploration and refinement

[HaloFour]

There's no need for new syntax here:

 obj["Invoice.Customer"] = "Herbert";
Console.WriteLine($"Customer: {obj["Invoice.Customer"]}");

obj["Invoice.Customer.Address.Street"] = "Main Street";
Console.WriteLine($"Street: {obj["Invoice.Customer.Address.Street"]}");

[SoftwareLey]

Enhanced Reflection Syntax and Special Methods

Imagine a scenario where reflection isn’t a clunky workaround using string-based keys, but a streamlined, self-contained language feature. For instance, consider the syntax:

obj<BindingFlag.Private, string>{"Test.Method"}("1", "2");

This clearly indicates that a reflective call is taking place with explicit flags, a target type, and a method name. Since we’re defining a completely new syntax, we can tailor it precisely to our needs. There’s no need to conform to the legacy constraints of arrays or dictionaries. The result is not only more intuitive but is designed from the ground up to be safe, efficient, and versatile.

---

Special Methods Made Possible

With a dedicated syntax, you can easily incorporate special methods that extend the capabilities of reflective operations. For example, consider the idea of checking whether a property exists before trying to access or modify it. In our new syntax, this could be expressed as:

obj{"Test.Property1.Property2"}.Exists();

This kind of operation becomes a first-class citizen in the language. Some potential benefits include:

• Clarity: Anyone reading the code immediately understands that this is a reflective operation and that we’re explicitly checking for the existence of a property.
• Consistency: Special methods like Exists(), or even others such as AddDynamicProperty(), RemoveProperty(), or Invoke() for methods, can be built directly into the language’s reflection framework.
• Safety: By designing this syntax from scratch, we can enforce compile-time checks where possible, avoid common runtime errors related to misspelled keys, and provide tool support (like IntelliSense) for these operations.
• Extensibility: Future extensions or custom reflection behaviors can be added without worrying about interfering with existing C# constructs. The language doesn’t need to keep in mind array or dictionary semantics, allowing for a perfectly tailored reflection mechanism.

---

A Vision for the Future

This vision for a new reflection syntax opens up a host of possibilities. By allowing specialized methods and providing an expressive, built-in way to handle dynamic properties, methods, and even deeper constructs (such as nested property access like obj{"Test.Property1.Property2"} = "Datum";, we redefine reflection as a first-class citizen within C#. It’s a revolution in how reflective operations are perceived and executed—clean, explicit, and powerful.

With such an approach, reflection isn’t just a hack or a last resort—it's an elegant, integrated part of the language that can evolve alongside our ever-growing coding challenges. What do you think of this vision for elevating reflection to a new dimension in C#?

[HaloFour]

I disagree with the notion that reflection should be any of these things. It's an inherently brittle system that requires a lot of knowledge and defensive programming. The friction of working with it ensures that it's not taken lightly. That said, via extension methods it's already pretty trivial to make helper methods to simplify reflection in those cases where you find it appropriate. And dynamic bindings enable dynamic programming scenarios rather easily. I don't see any reason to make such language changes to support this.

[SoftwareLey]

I disagree. Modern programming languages are becoming increasingly dynamic, and this evolution should be reflected in C# as well. A syntax extension like the one proposed can be integrated seamlessly, without causing major syntax challenges, and can be properly documented for clarity. It is crucial that we don't remain anchored in the past—considering the vast possibilities such an enhancement could unlock, it would truly be an elegant step forward.

Moreover, anyone using this syntax would inherently be working with reflection anyway. The current approach, however, fragments the code and reduces its readability. My proposal aims to address this by making such software far more maintainable and easier to control. It’s not just about functionality; it’s about moving C# into a more intuitive and future-ready direction."

[HaloFour]

C# has dynamic bindings. They also work with reflection behind the scenes.

I don't see anything here that can't already be accomplished with the language features that exist. You can already write extension methods that look very much like this proposed syntax, without changing the language.

[SoftwareLey]

Keep It Simple! The Next Big Thing: Reflection for All of Us!

Why should developers repeatedly reinvent the wheel when this functionality could be seamlessly integrated into the language with a new syntax? Currently, every time I work with a dynamically compiled code snippet using Emit, I must insert boilerplate reflection code—simply because the data from function parameters originates from another separately compiled snippet (JObject, ExpandoObject, or anonymous types). Without using reflection, standard code—especially when handling dynamic or anonymous types—lacks the essential type information in the current context, resulting in compiler errors.

Today, I’ve written a preprocessor that implements a portion of this new syntax, along with a helper class to optimize my workflow. Based on my practical experience, I believe that the new syntax is a game changer and can truly make all our lives easier.

By standardizing and documenting a dedicated reflection syntax, we can eliminate the redundant boilerplate that currently proliferates across millions of C# files. This proposal isn’t about reinventing reflection—it’s about perfecting it. Modern programming languages are evolving to help us work faster and more efficiently, and this new syntax would bring unprecedented clarity and ease to our codebases.

Integrating an elegant, dedicated reflection syntax into C# would streamline development, reduce errors, and improve maintainability. It would push the language forward into a more dynamic future, enabling more powerful programming constructs while eliminating the need for repetitive work. In essence, why settle for workaround solutions when a standardized, elegant, and efficient approach is within reach?

[HaloFour]

Why should developers repeatedly reinvent the wheel when this functionality could be seamlessly integrated into the language with a new syntax?

Because the bar for adding new syntax is (and should be) ridiculously high. There's zero reason to change the language here when the existing syntax can be used to provide the same features and functionality.

If you want to suggest a new standard set of APIs for reflection, feel free to do so with the runtime team. I doubt they'll find your use case compelling, and you've not demonstrated how doing so provides any of the benefits you claim it will bring. The fact that the community can solve this problem for themselves and offer their solutions to the marketplace of ideas is a very good thing.

[SoftwareLey]

Thank you for your response! I agree that introducing new syntax should be approached with caution and only for truly impactful changes. However, I believe the proposal goes beyond simply replicating existing functionality. While it’s true that the current syntax can achieve these features through workarounds, such approaches often lead to fragmented and less maintainable code.

The introduction of a dedicated reflection syntax would offer several advantages. It would standardize reflection usage, eliminate redundant boilerplate code, and make reflective operations explicit and intuitive. This isn’t just about adding new syntax—it’s about dramatically improving the readability, maintainability, and efficiency of our codebases.

As for suggesting new APIs, that is indeed a valid avenue to explore. However, I believe that embedding reflective operations directly into the language syntax offers a unique opportunity to streamline the developer experience. Rather than replacing community-driven solutions, it would establish a robust, standardized foundation for everyone to build upon.

Remark: This proposal is intended as an extension of the language, not a modification that introduces breaking changes. It is designed to be fully additive and backward-compatible, ensuring existing codebases remain unaffected while benefiting from enhanced reflection capabilities.

Thank you for considering this perspective. I’m excited about the possibilities this could unlock for making C# an even more powerful, intuitive tool for developers.

[HaloFour]

However, I believe the proposal goes beyond simply replicating existing functionality.

Nothing you have proposed achieves anything that can't already be achieved today rather trivially.

The introduction of a dedicated reflection syntax would offer several advantages. It would standardize reflection usage, eliminate redundant boilerplate code, and make reflective operations explicit and intuitive.

Reflection APIs and dynamic binding APIs are already standard. If you have suggestions to make them simpler, feel free to bring that to the runtime team. A language feature would definitely never be considered for this.

In short, you've identified a solution that is in desperate need of a problem.

[SoftwareLey]

Thank you for your detailed response. I understand your perspective that existing APIs and dynamic binding already provide solutions for reflection. While I appreciate your view, I believe the essence of this proposal lies not in addressing a non-existent problem, but in reimagining how reflection can be integrated into the language itself for better clarity, efficiency, and maintainability.

The introduction of a dedicated reflection syntax would do more than replicate functionality; it would simplify, standardize, and elevate how reflective operations are handled. It's not about reinventing APIs but about enhancing developer experience and code readability in a way that aligns with the evolving needs of modern programming languages.

Ultimately, this discussion isn’t just about feasibility—it’s about exploring potential and considering how subtle yet impactful changes can shape the future of C#. I invite you to think about how such a syntax could bring new possibilities to the language, allowing us to move forward with more simplicity and elegance.

[franchyd]

@SoftwareLey there are no gaps. extension methods can provide the exact same solution you are proposing today. The only difference is you want a new curly brace syntax instead of parentheses

This:

// Construct the object dynamically with initial values
object person = new Person
{
    Name = "Peter",
    Alter = 35,
    Adresse = new Adresse()
};

// Using the proposed syntax for dynamic assignment (PUT)
person{"Adresse.Stadt"} = "Köln";
person{"Adresse.Land"} = "NRW";

// And for dynamic retrieval (GET)
string city = person{"Adresse.Stadt"};
Console.WriteLine($"Stadt: {city}");

Provides no benefits over this:

// Construct the object dynamically with initial values
object person = new Person
{
    Name = "Peter",
    Alter = 35,
    Adresse = new Adresse()
};

// Using the proposed syntax for dynamic assignment (PUT)
person.ReflectiveSet("Adresse.Stadt", "Köln");
person.ReflectiveSet("Adresse.Land", "NRW");

// And for dynamic retrieval (GET)
string city = person.ReflectiveGet("Adresse.Stadt");
Console.WriteLine($"Stadt: {city}");

and the latter is doable today with no changes.

[HaloFour]

Thank you for considering this perspective, even if our views differ on its potential.

That's the problem, you haven't demonstrated any potential. It's curly brace syntax for the sake of curly brace syntax.

If you want to explore this space, go fork the compiler and explore it on your own. Nobody on the C# team is going to consider these language changes.

[SoftwareLey]

@franchyd, @HaloFour Yes, that is one of my intentions. The proposed new syntax is primarily aimed at enabling standardization. It is not just about offering an alternative style but about creating a clear and elegant approach to expand the language without disrupting existing functionalities. This opens up new possibilities in handling data types and intuitively signals a dynamic and modern approach, distinctly separating it from previous conventions.

[HaloFour]

This opens up new possibilities in handling data types

You haven't shown anything new. Everything you've proposed can be accomplished today using existing syntax. Standardization can be achieved just as easily through standard APIs.

[CyrusNajmabadi]

@SoftwareLey you didn't actually answer my question.

I asked:

What about the existing options we've mentioned in this thread would not have worked for you.

You didn't compare your proposal to the existing options we suggested (like a summary API built with extension methods). You just compared your suggestion to raw reflection. That's not what I asked you.

[SoftwareLey]

@CyrusNajmabadi Thank you for the feedback! I think there might have been a misunderstanding in our communication. My focus is not on achieving a specific goal, but rather on improving C# as a language overall—particularly enhancing its simplicity, readability, and elegance. These qualities are vital, as they make a language more approachable and enjoyable for developers.

One of my key considerations is the importance of directly visible purpose within the language, which makes it immediately clear that the syntax allows for a universal, fully type-independent, dynamic access to objects. My intention is to emphasize that the syntax should directly reflect what is happening in the code. This immediate readability and transparency simplify understanding for developers, enabling efficient work while reducing complexity and errors.

My focus also lies in enabling dynamic connections between classes, even when they share no common structures or interfaces. This goes beyond the limitations of dynamic, which lacks the ability to fully represent type information. Additionally, the unification and optimization of working with dynamically compiled code (via Emit) plays a central role in my thoughts. Specifically, preserving access to information about anonymous types during data exchange directly could greatly improve these workflows. However, this is just a secondary benefit of a broader unification and simplification effort.

Ultimately, I aim to streamline and refine the handling of dynamic and reflection-based features, not only to reduce boilerplate but also to create a more elegant and powerful coding experience. While it’s not about taking inspiration from a specific language, it’s about embracing simplicity and highlighting the value of a clean and intuitive syntax. I believe these improvements could strengthen C#'s position and appeal even further.

[CyrusNajmabadi]

@SoftwareLey you didn't actually answer my question.

I asked:

What about the existing options we've mentioned in this thread would not have worked for you.

You didn't compare your proposal to the existing options we suggested (like a summary API built with extension methods). You just compared your suggestion to raw reflection. That's not what I asked you.

[CyrusNajmabadi]

Once again, you are not actually responding to the points being made, or the very direct questions that need answers for us to even consider this.

Language design doesn't revolve around what you think would be great. It revolves around delivering what we think has the highest value. And for us to just that, it is necessary to compare to what is possible today. You said your proposal was far superior and would produce far better results than what you can do today. Not you HAVE NOT demonstrated that, despite several requests so far.

Please stop espousing vague virtues you feel will come. Please just do the actual comparison between the options we've stated are possible today, and your proposal. Do it side by side. Demonstrate that your claims are true. Don't just assert that. Thanks :-)

[CyrusNajmabadi]

but rather on improving C# as a language overall—particularly enhancing its simplicity, readability,

I want to address this, as you keep bringing it up. It is very much not evident that the proposal here helps with simplicity or readability. Indeed, is much simpler to be able to write and read simple, idiomatic c#3.0 code to solve this problem. That version of the language is 18 years old and is understood by the entirety of the ecosystem. It is exceedingly easy to teach and understand. It looks exactly like how c# has looked since 1.0.

It is already incredibly simple and readable. The new suggestions are neither. They utilize new syntax that has no correspondence with anything in the language. They raise complexity by having an entirely new way of doing things that would just boil down to single line methods. They do not provide tangible benefits (like allowing the compiler to optimize anything).

In a very real way, this is all a step backwards from the options that have been available since 2007.

[SoftwareLey]

@CyrusNajmabadi My aim has always been to contribute ideas that could push the evolution of C# forward, focusing on innovative language elements and functionalities that enhance usability, clarity, and developer productivity. However, it is not within my capacity to assess or directly compare existing alternatives and proposals—such evaluations are best handled by the expertise of the C# team. Their deep understanding of the language’s architecture and goals places them in the ideal position to determine what aligns with C#'s vision and roadmap.

Having been involved with both VB and C# since their inception, I’ve had the privilege of participating in nearly all beta versions and gaining extensive experience over the years. This has given me valuable insights into the evolution of the language, as well as areas where I believe opportunities for improvement exist. My day-to-day work often requires seamless integration of C# with other programming languages, such as JSON processing, which highlights how critical it is for C# to maintain versatility and efficiency.

While existing language features provide strong foundations, certain scenarios—especially in dynamic and cross-language operations—can reveal areas where enhancements might bring greater fluidity and ease. My proposal aims to address these possibilities by introducing an intuitive, unified approach that bridges gaps and streamlines workflows.

As someone deeply passionate about C# and its growth, I respect the team's processes and welcome their leadership in guiding discussions to the most valuable outcomes. In particular, I value and respect the perspective of Mad Thorgesen and his visionary ideas, as I believe they play an important role in shaping the language's future.

Thank you for the engaging discussion, and I hope my ideas can contribute to C#’s ongoing success.

[CyrusNajmabadi]

However, it is not within my capacity to assess or directly compare existing alternatives

Then why do you insist that existing alternatives are insufficient?

It has been your claim, numerous times, that this is the right way to go about providing solutions in this space. The onus is on you to demonstrate that. Especially in the face of exceedingly simple alternatives that we've discussed.

People here have done the same in response, and you have stated your position is still the right one to consider. How can we feel that that is the case when you are not willing to even provide any comparison to the trivial alternatives proposed?

[CyrusNajmabadi]

which highlights how critical it is for C# to maintain versatility and efficiency.

Please demonstrate why your language feature provides more versatility or efficiency than the simple apis proposed that would be possible to deliver today (and 15 years ago)

certain scenarios—especially in dynamic and cross-language operations—can reveal areas where enhancements might bring greater fluidity and ease.

Please demonstrate those area. Please show the greater fluidity and ease. Do this by comparing to what is already possible.

My proposal aims to address these possibilities by introducing an intuitive, unified approach that bridges gaps and streamlines workflows.

Please show how your approach is superior at bridging gaps and streamlining workflows over the existing alternatives already demonstrated multiple times.

Again, these are your claims . The are not evident to anyone here. You need to demonstrate them. You need to answer the questions given to you. Stating you can't do that, but then repeating that your solution provides this in a way that isn't possible today, will not fly :-)

[SoftwareLey]

@CyrusNajmabadi Thank you! I believe I was able to inspire some thoughts about new possibilities for C# and expanding the developer base. Perhaps altering the language isn’t the best approach, but after so many years, I feel it might be time to introduce something new. Just as I did in 2014 with .NET, where I aimed to spark discussions and encourage innovative ideas,

"Innovation is the ability to see change as an opportunity - not a threat."
-- Steve Jobs

[CyrusNajmabadi]

Please answer the questions directed at your proposal.

Innovation is the ability to see change as an opportunity

This is not helpful. If you are proposing change, them you need to be able to answer these very basic questions. Implying that we are threatened by New ideas by asking you to simply answer questions is not going to go anywhere.

I'll note that I've asked you at least 4 times now to do this. I do not understand why you seem unwilling to respond reasonably to very basic requests.

where I aimed to spark discussions

Discussion is a two way street. Not responding to people trying to actually work on the proposal and design with you is NOT discussion. It is simply talking at people. Please show us the courtesy to actually engage and discuss the idea.

[SoftwareLey]

@CyrusNajmabadi I consider this proposal to be so straightforward that its benefits for daily work should be immediately apparent. Nonetheless, I have made an effort to address all relevant questions in the comments I provided during the proposal process. However, it seems that some points may not have been fully understood, as similar questions were repeatedly raised. I even extended the proposal during the discussion process to clarify certain aspects. Honestly, I am unsure where the misunderstanding lies. It could be that continuous text responses are harder to process in this format.
I am concerned about how such proposals are being handled and hope this feedback will be taken into account moving forward.

[CyrusNajmabadi]

I consider this proposal to be so straightforward that its benefits for daily work should be immediately apparent.

It is not. And many people (myself included) have explained why.

Nonetheless, I have made an effort to address all relevant questions

You have not. I have asked for some basic info 4 times in a row, and you still have not answered. Indeed, you stated you would not be able to provide this information.

As there has been no forward progress, and a seeming disinterest in engaging with the questions being raised, i'm locking this and marking it as properly answered.

[CyrusNajmabadi]

All the requested capabilities are already possible using C# 3.0 and simply extension methods over the core .Net reflection apis. As such, having new, complex, difficult to read, syntax that accomplishes the same, would be a net negative for the language.