Proposal: allow non-public operators

[gafter]

@jskeet commented on Fri Jan 08 2016

Currently, all operators have to be public. This can reduce readability of internal-only code where an operator would otherwise be natural. This proposal is to allow things like:

internal static Foo operator +(Foo foo, Bar bar)

Use-case: in Noda Time we have types of:

• public struct Instant
• public struct Offset
• internal struct LocalInstant

We have operations for adding an Offset to an Instant to get a LocalInstant, and the reverse subtraction operation. These would idiomatically be implemented using operators, and were while LocalInstant was public (long before the first release). It's annoying that they can't be :(

(I don't know whether this would require a CLR change or whether it could just be a C# language change...)

I suspect there isn't much benefit in having other access modifiers beyond public and internal, but that's probably best discussed after deciding whether or not even allowing internal is desirable.

---

@leppie commented on Fri Jan 08 2016

Nice suggestion 👍

I cant see any issue with the CLR for this. Edit: The only mention is the naming rules for operators, and nothing else beyond that.

I can't even think it would be hard to implement in the compiler.

---

@HaloFour commented on Fri Jan 08 2016

I'm curious as to the reason that non-public operators aren't allowed. This restriction is explicitly stated in the C# spec, §10.10:

The following rules apply to all operator declarations:

• An operator declaration must include both a public and a static modifier.

---

@AdamSpeight2008 commented on Fri Jan 08 2016

@HaloFour Me Too.

---

@ViIvanov commented on Mon Jan 11 2016

@HaloFour,l @AdamSpeight2008

May be, reason is next: moving code with with non-public operators used from one project to another can have an unexpected semantic.

---

@ViIvanov commented on Mon Jan 11 2016

May be, compiler should require, that visibility of operator is same as operand with lowest type visibility?

For example, we should not have an ability to create an internal operator for two public types, but can create an internal operator for public and internal types.

---

@alrz commented on Mon Jan 11 2016

@ViIvanov Can you give an example? I think that would be the issue with moving any code!

---

@AdamSpeight2008 commented on Mon Jan 11 2016

We could allow the visibility to be treated as a scoping clarifier. eg
var baz = internal( foo + bar );
Which will use an internal implementation of the operator plus.

---

@svick commented on Mon Jan 11 2016

@AdamSpeight2008 To me, that sounds like a separate feature on top of this one and one that is not very useful.

---

@AdamSpeight2008 commented on Mon Jan 11 2016

@svick
It would be useful as it would let state that you explicitly what the internal overload.

public static t0 operator +( t0 x, t0 y ) {..}
private static t0 operator +(t0 x, t0 y) {...}

---

@svick commented on Mon Jan 11 2016

internal overload? You can't have two methods that differ only by their access modifier in C# or IL. I don't see why would you want that and this issue is not about that.

I assumed it was about situations like:

public class A
{
    public static A operator +(A a, B b) { … }
}

public class B
{
    internal static A operator +(A a, B b) { … }
}

But that still doesn't seem very useful to me.

[ViIvanov]

@alrz Sorry, I was wrong about issue with moving code and you are right.

[john-h-k]

I agree that this would be really useful - although for a slightly different reason. There are several places in my code base where having implicit/explicit conversions would be very useful, but publically exposing them wouldn't be ideal