Feature Request: Allow multiple static types with the same name to be referenced in a file

[YairHalberstadt]

Lets say I want to add a custom numerical type. For example I want to have a numeric type that is accurate to one decimal place

public struct OneDpNum
{
    private readonly int _value;
    public OneDpNum(double val) => _value =val*10;
    public override string ToString()
    {
        var units = _value / 10;
        var dp = _value % 10;
        return $"{units}.{dp}";
    }
    ...
}

Now I want to add various static utility methods to deal with OneDpNum. For example I want to add the Math.Max method. However I want this to feel like a numeric type, so I put the Math class in the namespace System for consistency with other numeric types.

namespace System
{
    public static class Math
    {
        public static OneDpNum Max(OneDpNum a, OneDpNum b) => a > b ? a : b;
    }
}

Unfortunately this wont work, as there will now be a type conflict between the BCL System.Math, and my System.Math.

Ok, let's move it to a different namespace:

namespace OneDpNum
{
    public static class Math
    {
        public static OneDpNum Max(OneDpNum a, OneDpNum b) => a > b ? a : b;
    }
}

But now you can't reference Math.Max(int, int) and Math.Max(OneDpNum, OneDpNum) in the same file as there will be ambiguity between the types. You have to use the full name for at least one of them, so you have to specify OneDpNum.Math.Max. That's not the end of the world, but it makes OneDpNum feel much clunkier to use.

So this proposal is to allow calls on methods and properties of multiple static classes with the same name, so long as there are no conflicts between the methods/property.

A method or property call is conflicted if a method/property exists in both types with the same signature (excluding return types).

So for example

using System;
using OneDpNum;
'''
typeof(Math) //not allowed - ambiguous
var a = new OneDpNum();
Math.Max(a,a) // allowed since the best method this can be resolved to is OneDpNum.Math.Max(OneDpNum, OneDpNum), and this method only exists in OneDpNum.Math.

[YairHalberstadt]

If type classes are implemented, an System.Math was updated to use them, that would of course solve the issue in this case much more neatly.

[svick]

Wouldn't static extension methods, which I think are part of "Extension everything" #192, solve this?

[YairHalberstadt]

@svick
Yep, that would solve this too

[YairHalberstadt]

I won't close this, seeing as it's not clear if or when static extension methods will be implemented, but certainly they are a preferred solution.

[Austin-bryan]

I mean, I would like to be able to put it in System.Math because then it's more organized and feels less clunky.

Regardless, I believe this could be possible because it just has to view the two Math as one class and just use basic function overloading from there.

[YairHalberstadt]

@willard720
That was my thinking

[quinmars]

System.Math is not a namespace, but a static class. As far as I know a static class is on CLR level a "ordinary" abstract sealed class. So you are actually asking to scatter one class over several assemblys. I doubt that will ever happen.

[YairHalberstadt]

This could be implemented at a purely compiler level, so long as the classes are in different namespaces.

[YairHalberstadt]

The compiler just has to add in the full namespace for you - as it does anyway for every type. Namespaces don't exist at the IL level.

[theunrepentantgeek]

I can see this causing a great deal of confusion in two different ways.

Example the first: Vendor use

Consider when a vendor inevitably uses this feature and includes something in its public API.

For the sake of illustration, let's assume it's an additional version of System.Math that includes support for complex numbers. When someone is using the library and needs to search for usage/docs, where are they going to end up? Most likely at the official documentation for System.Math - and none of the methods to support complex numbers will be listed because they're not written by Microsoft.

In the best case, the developer doing the search realizes what is going on (perhaps because they added the library in the first place), adds the vendor name to the search and finds what they need. All they've wasted is a little time.

In the worst case, the person is totally unaware of what's going on and can't solve their problem. Perhaps they file a bug on GitHub reporting that documentation is missing for some method on System.Math - a bug that gets closed with "Nothing is missing - we don't support complex numbers".

Unique namespaces help people find documentation, examples, StackOverflow questions (and answers) and more.

Example the second: Versioning

Classes evolve all the time - and it's not normally considered a breaking change to add a new method with a new name to an existing class.

But with this proposal, there's a very real chance that a new method added to, say, System.Math would conflict with another method from a different assembly/author/project, causing a compilation error due to an ambiguous method call.

[YairHalberstadt]

@theunrepentantgeek

That's only where they have the same namespace. This feature would also be beneficial if they have a different namespace, but you can reference them both in the same file.

[mikernet]

@theunrepentantgeek I don't know if that's an argument against this. If you are using a library and you have imported the namespace into your file, updating that library and recompiling can already cause all sorts of ambiguity problems. If they add a type that has a name that conflicts with a different type in another namespace you've imported then you get a conflict. If they added an extension method that conflicts with an extension method in an imported namespace then you get a conflict. I think it is well understood that updating a library that contains new members can cause ambiguity issues that you will have to resolve.

I think this would have been a great way to enable "static extension methods" (I use the term loosely - they aren't extension methods, it's just matching the member name to multiple types) off the get go and it should still be considered even with "extension everything". If there are multiple candidates for a static type then it should just consider all of them and only complain if the member access doesn't disambiguate between them.

[juliusfriedman]

I see this issue only because your type doesn't handle casts from Int or Double and doesn't have a constructor for Int.

If you made your class explicitly have those operators you would be able to use Min and Max but would need to round trip back through having a construction from Int or Double as well..
https://github.com/juliusfriedman/net7mma/blob/master/Concepts/Classes/Number.cs