Add Extension Properties

[grofit]

Background

C# already supports extension methods which allow for extending existing objects without altering the core contract/shape in any way, which provides a lot of benefit in when trying to add helper, convention, fluent style additions to a given type.

So given the existing use cases for extension methods, there is a scenario where you may want to create getter/setter style properties for an object to make it easier to interact with, but currently the only avenue to do this is via extension methods, like so:

// Some class from another assembly we do not own
public class Player
{
  public Dictionary<int,int> Stats {get;}
}

// Extenstion method in our project
public static class PlayerExtensions
{
  public static int Health(this Player player) => player.Stats[StatTypes.Health];
  public static void Health(this Player player, int value) => player.Stats[StatTypes.Health] = value;
}

// Usage
var health = somePlayer.Health(); // Getter
somePlayer.Health(100); // Setter

So as you can see we can already express the getter/setter like behaviour by explicit methods but it would be good if there was a way to express this as a fully fledged Property as under the hood properties are just methods anyway.

Possible Syntax To Achieve This

Do not take this as a definitive "this is how it should be implemented" as I do not know enough about the underlying language and compiler, but this is a stab at trying to impart the high level use case.

public static class PlayerExtensions
{
  public static get int Health(this Player player) => player.Stats[StatTypes.Health];
  public static set void Health(this Player player, int value) => player.Stats[StatTypes.Health] = value;
}

// Usage
var health = somePlayer.Health; // Getter
somePlayer.Health = 100; // Setter

This would potentially also allow other operators to be used on the properties making them more useful than the explicit method approach we have at the moment.

[HaloFour]

See: #5498 dotnet/roslyn#11159

The team is exploring syntax like the following which would enable any kind of extension member:

public extension PlayerExtensions of Player {
    public int Health {
        get => this.Stats[StatTypes.Health];
        set => this.stats[StatTypes.Health] = value;
    }
}

The exact syntax/keywords for declaring the extension is still up for discussion.

[CyrusNajmabadi]

@dmrickey We're exploring this under the umbrella of shapes/roles/extensions.

[IvanPizhenko]

Are there any plans to include this say into C#12?

[CyrusNajmabadi]

@IvanPizhenko we are currently designing 'extensions' and working on a prototype. We cannot say which release this will necessarily go into though yet.

[nxrighthere]

@CyrusNajmabadi Is it possible to track this process somewhere? The linked issue here is closed, and the last mention of the extension properties I found is here.

[KennethHoff]

@nxrighthere The most official issue is here: #7771.

It's not only properties, but everything.

[drizzle-mizzle]

Would be really helpful

[MemeDeveloper]

NOT a new nor unpopular request....

e.g. lots of people wanted this in 2009 (see here Jon Skeet's reference to Eric Lippert's blog post from 2009):

"EDIT: They didn't appear in C# 5, and as of July 2014 it doesn't look like it's going to be in C# 6 either.
Eric Lippert, the Principal Developer on the C# compiler team at Microsoft thru November 2012, blogged about this in October of 2009:
Why No Extension Properties? – Fabulous Adventures In Coding"

"I stopped counting how many times over the years I opened this question with hopes to have seen this implemented.
Well, finally we can all rejoice! Microsoft is going to introduce this in their upcoming C# 8 release."
-- Korayem ~2017

Or e.g.
https://stackoverflow.com/questions/619033/does-c-sharp-have-extension-properties
#192
https://blog.ndepend.com/c-8-0-features-glimpse-future/
dotnet/roslyn#3357
dotnet/roslyn#5165
dotnet/roslyn#5624
dotnet/roslyn#6136
dotnet/roslyn#11159

Go on csharplang team you know it makes sense... (also while we're at it being able to implement an interface with an anonymous object... like we can in Typescript, or java)... why spend so much effort giving us e.g. relational pattern matching, or global using directives... certainly the latter.... is something that effects my live as a full stack dotnet focused dev... not at all... but "extend everything" and "anonymous implementations" would be pure MAGIC for productivity for thousands and thousands of devs all over the world !!!

https://stackoverflow.com/questions/191013/can-anonymous-class-implement-interface

#4301
#2517
#4148
#738
#1542
#2298

[CyrusNajmabadi]

@MemeDeveloper we're already working on this.

[CyrusNajmabadi]

why spend so much effort giving us e.g. relational pattern matching,

Because there is value there.

is something that effects my live as a full stack dotnet focused dev

We have to consider the entire ecosystem, not just an individual developer.

[jamesford42]

Bump. My vote here, for this.
Aside: Is this "question" post the best place for me to be upvoting a potential feature?

[CyrusNajmabadi]

extend MyExtensions : System.String

The syntax is a strawman so we can figure out the semantics we want.

[HaloFour]

The syntax is illustrative only. Nothing has been settled on.

Odds are that the language will require naming the extension given a witness type will be emitted and it's easier to make that explicit rather than auto-generated, especially since it will be a part of any public API and changes to the generation strategy will break existing consumers.

Making it somewhat different from inheritance is also likely as one feature extensions is aiming to solve is extension implementation of interfaces:

public extension StringExtensions for string : IDisposable {
    // why?  who knows
    public void Dispose() => Console.WriteLine($"Disposed: {this}");
}

[jamesford42]

Counter-proposal
;D

extend System.String
{
   IDisposable.Dispose() => { };
}

[HaloFour]

Very timely:

#7777

[JustinMinnaar]

Cool. 👍

My unrequested opinion on that syntax though.. Yuk.

I suspect that the following might be a more intuitive way of representing it, since everyone is already familiar with inheritance, and logically what they are wanting to do is add a property/method to an existing type.

How about...

extend System.String
{
   bool IsWhiteSpace { get => string.IsNullOrWhiteSpace(this); }
}

Notes...

For the rare person who wants these extensions for internal library use only they can specify internal, but specifying private would be invalid likely, and public is implied. That all also applies to the members of the extension you are adding, public is implied, internal could be specified.

For the even more rare person who must have a specific name for this type, and wants to deal with any resulting name clashes themselves, they can do so. But by default what would be a lot better is to remove the required boilerplate type name that inevitably conflicts when library a and b both have a public static class Extensions.

Ex. (of specifying a type name)

extend MyExtensions : System.String
{
   // ...
}

It would be nice if existing static methods on the String class could be changed to extension methods.

Then, instead of

   if (String.IsNullOrWhitespace(x)) ...

You would be able to use

    If (x.IsNullOrWhitespace()) ...