Overloading on in/byval should cause an error

[VSadov]

The following seems to not result in an error, but should:

namespace ConsoleApp33
{
    class Program
    {
        static void Main(string[] args)
        {
            var o = new P1();
        }

        public void Foo(in int z) { }

        public void Foo(int z) { }
    }

    class P1: Program
    {

    }
}

We should also add tests to make sure we select the correct overload, also in case of in situation of ambiguity (because of inheritance or extension methods)

[tannergooding]

@VSadov, why would that cause an error (I'm guessing a language design decision)?

I would expect a user is allowed to differentiate by Foo(in 5) (or Foo(ref 5) or Foo(ref readonly 5)) vs Foo(5).

This makes adding ref readonly overloads, where you only had byval overloads previously, a breaking change.

This is a bit confusing, because users are allowed to add a ref overload and have it work (so I can have Foo(ref int z) and Foo(int z), but not Foo(in int z) and Foo(int z)).

[VSadov]

Right now there is no way to guide overload resolution at the call site.
You cannot do Foo(ref readonly 42). I can see this as a possibility in the future, but I still would not guess what syntax would be for operators - ref readonly 42 + ref readonly 42 ?

Anyways, as it is currently would not be possible to call either of the overloads, we will disallow such situations. Once/if it is possible to disambiguate, we can relax the restriction.

[OmarTawfik]

@VSadov do we have a decision on this? should we move this to 15.later?

[VSadov]

It is not officially confirmed, but otherwise nearly decided to allow this kind of overloading, even when it is not callable (if common, we can introduce disambiguating syntax at call site in the future).

[VSadov]

It is confirmed with LDM to be ok.

[tannergooding]

@VSadov, do you have a link to the design notes?