Add using extension to allow use of static methods as extensions

[Pzixel]

Problem

We often encounter a problem with methods such as string.IsNullOrEmpty, char.IsLetterOrDigit that could be extension but aren't. I see a lot of project full of:

public static class StringExtension
{
   public static bool IsNullOrEmpty(this string value) => string.IsNullOrEmpty(value);
}

It could be solved with using static, but it doen't work well with null propagation:

public static class CharExtension
{
	public static bool IsLetterOrDigit(this char c) => char.IsLetterOrDigit(c);
}

...

char? c = null;
bool? b = c?.IsLetterOrDigit(); // works well as extension
bool? b2 = char.IsLetterOrDigit(c); // even doesn't compile

but things become worse with reference types:

public static class ArrayExtension
{
	public static bool Exists<T>(this T[] array, Predicate<T> match) => Array.Exists(array, match);
}

...

Match[] arr = null;
bool? b1 = arr?.Select(m => m.Value)?.Select(s => s.Length)?.ToArray()?.Exists(_ => true); // ok
bool? b2 = Array.Exists(arr?.Select(m => m.Value)?.Select(s => s.Length)?.ToArray(), _ => true); // ok at compile time, but crashes at runtime with NullRef

I has written here a typical example: we have some query with null propagations and then we want to call some static method. We always can follow a good ol' way by storing query into variable and then checking it before calling some method (Array.Exists in this example), but why have we if we already have compiler for that purpose?

Solution

In addition to using static add using extension that just allow to call all public static class methods that takes instance of this or derived class as first parameter as extensions.

using extension System.Array;

static void Main()
{
	int[] arr = null;
	bool? b1 = arr?.Exists(_ => true);
}

that compiles just like null propagation:

static void Main()
{
	int[] arr = null;
	bool? b1;
	if (arr == null)
		b1 = null;
	else
	{
		b1 = Array.Exists(arr, _ => true);
	}
}

[svick]

Isn't the solution to actually change the methods into extension methods? Have you considered proposing that in corefx?

[Pzixel]

@svick no, I suppose that turning all methods into extension may be unwanted on one hand, and may hurt method resolution algorithm on another. And of course you understand that it will make this keyword optional, which introduce two subtly different ways to do exactly the same thing, and it's pretty bad. Thus it's completely language feature, that has nothing to deal with CLR, so why would I propose it in corefx repo?

[alrz]

@svick

Isn't the solution to actually change the methods into extension methods?

that's simply a breaking change. Aside that using static does not bring extension methods in scope, you never know that there exists some other extension method with the same name already in client code.

namespace System {
  public static class X {
    // we made this an extension method in corefx
    public static bool M(this string str) { .. }
  }
}
namespace MyNamespace {
  public  static class Y {
    // have already been an extension method
    public static bool M(this string str) { .. } 
  }
}


// then this code will break
using System;
using MyNamespace;

class C {
  void M()
  {
    "".M(); // ERROR: call is ambigious
  }
}

I liked this proposal but it would make more sense if it is introduced at the same time that we have "extension everything" feature.

[alrz]

However, we could define those extensions in another namespace like System.Extensions, if that's what you meant. Though I don't think that's a good idea since it duplicates some of methods.

PS: Making string.IsNullOrEmpty an extension method requires another feature because String is not static.

[Pzixel]

@alrz I don't see how it differs from today's situation when you have two similar extension methods.

PS: Making string.IsNullOrEmpty an extension method requires another feature because String is not static.

This proposal doesn't require class to be static. Since string.IsNullOrEmpty is a static method which takes its instance as first parameter it can be treated as an extension.

[alrz]

I don't see how it differs from today's situation when you have two similar extension methods.

If you already defined an extension method named IsNullOrEmpty somewhere and also imported System namespace, it no longer compiles after this change.

This proposal doesn't require class to be static. Since string.IsNullOrEmpty is a static method which takes its instance as first parameter it can be treated as an extension.

If you're proposing to just make string.IsNullOrEmpty an extension, that wouldn't be possible because currently the compiler requires the containing class to be static.

[Pzixel]

If you already defined an extension method named IsNullOrEmpty somewhere and also imported System namespace, it no longer compiles after this change.

You can now declare two static classes with IsNullOrEmpty and get the same compile time error. I don't see any crime here.

If you're proposing to just make string.IsNullOrEmpty an extension, that wouldn't be possible because currently the compiler requires the containing class to be static.

using static shouldn't behave 100% like current extension methods. I don't see any problem in working with public static members of non-static class.

[alrz]

Note: none of my claims are applied to using extension, I just pointed out that changing corefx as @svick suggested is not an option.

[Pzixel]

@alrz ah, I missed it. Then ok. But I explicitely wrote that we don't require any CLR support so it can be C#-only feature. Everyone likes this kind of features because they can use it on .Net 2.0 and don't require anything but latest visual studio.

[Pzixel]

Today encountered with yet another situation where this is needed.

int entityId = input.AsMaybe().Map(long.Parse).GetOrElse(-1);

It's not possible now to rewrite it on null propagation. And I don't see how could it be rewrited properly without boilerplate if tryparse and so on. So this feature still be useful, but more limited than I was expecting.

However, if we don't import two or more types with Parse method it still possible:

using extension System.Int64;

...

int entityId = input?.Parse() ?? -1;