I suggest you ...

C# support static extension methods like f#

C# support static extension methods like f#

1,024 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Márcio Althmann shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • WarNov commented  ·   ·  Flag as inappropriate

    I found this requirement when I needed to have the method DateTime.NowInColombia(). It would be great id I could do that without the need of create another class...

  • Gavin Williams commented  ·   ·  Flag as inappropriate

    Vector2 class is a good example for me of why this should have already been done. Typically a Vector2 class (take a look at Numerics.Vector2) will have a range of static methods. But does it have Angle() CatmullRom() ClampLength() Constrain() FromRadians() GetNormals() Hermite() Project() etc.

    It just makes sense doesn't it, the same amount of sense as providing basic extension methods.

  • Doug commented  ·   ·  Flag as inappropriate

    This is probably the most unbalanced thing in C#. It currently makes extension methods fairly useless as there is often the need to extend the type with a static method/property.

  • Ayush Vora commented  ·   ·  Flag as inappropriate

    Oh god, let's please have this. I support absolutely ALL the points in favour of this.

  • Anonymous commented  ·   ·  Flag as inappropriate

    A lot of .NET guys are feeling abandoned out there today. They see the excitement around cross-platform, or mobile devices, or the cloud.

    .Net is the wrong product at the wrong time. That's what happens when you follow rather than lead. Microsoft's Java clone could never hope to be as successful as Java itself.

  • birbilis commented  ·   ·  Flag as inappropriate

    it would be nice if C# supported syntax like:

    public static DependencyProperty Register(static DependencyProperty x, string name, Type propertyType, Type ownerType, FrameworkPropertyMetadata typeMetadata)

    that is static extension methods for classes, that can be invoked without a class instance (just with the class type), apart from normal extension methods that can be invoked on a class instance.

    Then for example I could use it in Silverlight to add to its DependencyProperty class some extra WPF syntax that it currently misses, in order to increase code portability. It would wrap Dr.WPF's implementation of value coercion for Silverlight’s DependencyProperty. I have the related code at my Compatibility library (http://Compatibility.codeplex.com) and respective NuGet package (http://nuget.org/packages/Compatibility), but the syntactic sugar is missing to achieve source code portability (via WPF and Silverlight projects that include common files via file links) without changes.

    Note the "static DependencyProperty" parameter instead of the "this DependencyProperty" one that is used in C# extension methods (or else instead of static maybe they could use other keyword like type or typeof there, but I feel static is more appropriate).

    Related discussion:



    Also I see somebody mentions in a comment below "static extension properties" apart from "extension properties". Indeed it is natural that if static extension methods are to be allowed in the future, together with extension properties, then static extension properties should be added too (to extend a type with [attached] static properties)

  • Julius Kunze commented  ·   ·  Flag as inappropriate

    This article was created a long time ago:


    I don't like the word 'feature' in this article - because it is just a completion of the super successful extension method concept that was not implemented completely when in was introduced ("the schedule was full")!

    Come on, Visual Studio team! There are so many votes for a relatively simple language rounding off and there is still no response/consequence? You do great things - please bring them to an end!

  • Mike Marynowski commented  ·   ·  Flag as inappropriate

    +1 to Matt Dotson's comment...so simple and logical, I can't believe it wasn't included at the same time that extension methods were introduced!

  • Sven F. commented  ·   ·  Flag as inappropriate

    Here is a possible solution to static extension methods. It does not apply to all needs, but may be convenient for some cases.

    To extend classes (which are defined in external libraries) with static methods just use inheritance and name the class the same as the original, but use your own namespace which will be favored by the compiler.

    Example: I wanted to extend value conversion for XML with object handling. This is what I did:

    namespace MyNamespace

    public class XmlConvert : System.Xml.XmlConvert
    public static string ToString(object value) {...}
    public static object Parse(string value, System.Type targetType) {...}


    Now when I use "XmlConvert" it will point to the newly defined class but will still show all the static methods of the original System.Xml.XmlConvert.

  • Qwertie commented  ·   ·  Flag as inappropriate

    +1 to Matt Dotson, no syntax changes are needed. Currently I have a namespace called "Loyc.Math" and it is constantly conflicting with the System.Math class... ugh. So the C# team has the opportunity to solve multiple problems at once here.

    All the compiler has to do is

    (1) ignore static classes in new expressions (e.g. "new String(...)" should ignore a static class called String if there is one)

    (2) allow lookup in multiple classes at the same time (but do a separate overload resolution on each class -- if an overload matches in multiple classes it should be an error, lest someone should introduce a new static class and accidentally change the meaning of existing code by adding a better-matching overload.)

  • Matt Dotson commented  ·   ·  Flag as inappropriate

    You don't even need to change the syntax!! You just need to make the compiler a little smarter. Make the compiler resolve ambiguous type errors by matching the method signature. If the two types have a matching method with the exact same signature, then make a compiler error, but you have enough info to resolve the right type in 99% of the cases.

    namespace MyExtensions
    public static class Math
    public static int SomeMethod(int x)
    return 0;

    namespace Sample
    using System;
    using MyExtensions;

    public class Foo
    public void Bar()
    var x = Math.SomeMethod(5); // <<<< Currently an ambiguous type error.

  • Ron commented  ·   ·  Flag as inappropriate

    I was inspired by mabster's blog post. Here is my proposed syntax for static extension methods (on types), static extension properties (on types), and extension properties.

    // type extension method
    // Pro: goes well with existing extension method
    // Pro: goes well with proposed type extension property syntax
    // Con: is a weird parameter syntax that is not really a parameter
    public static int Foo3(static SomeStaticClass) { return 0; }

    // type extension property
    // Pro: goes well with existing extension method syntax
    // Pro: goes well with proposed method-style type extension method
    // Con: it makes a property look like a method; might be confusing for new users.
    public static int Foo4(static SomeStaticClass) { get { return 0; } }

    // instance extension property
    // Pro: goes well with existing extension method
    // Con: it makes a property look like a method; might be confusing for new users.
    public static int Foo5(this SomeClass c) { get { return 0; } }

  • RJ Hollberg commented  ·   ·  Flag as inappropriate

    I would love this! Static extension methods, extension properties, and static extension properties. And while you're at it, throw 'em in VB.NET too ...

  • Rune Juhl-Petersen commented  ·   ·  Flag as inappropriate

    This is a great idea. This idea is not new but lets hope someone reconsiders this. As F# supports this, then ofcourse C# should as well.

    I have been mising this a lot to create object factories in a better way.
    Consider defining a new() method on an Interface: ISomeInterface.new().
    Or get(id) to retrieve from database. ISomeInterface.get(id).

    Just like instance extension methods, this is just syntax sugar, but in the end your have some code that is much tidier.

Feedback and Knowledge Base