Allow operators to be defined as instance methods.

[lostmsu]

Yes, we've read https://blogs.msdn.microsoft.com/ericlippert/2007/05/14/why-are-overloaded-operators-always-static-in-c/

However, there are many scenarios, when having operators to be static methods fail. Main one being inability to represent generic algebras, which is hindering efforts to make C# suitable for scientific computing.

My proposal is simple: allow defining operators without static keyword, and permit them on interfaces. When performing operator overloading, always choose static operators defined in 7.0 way, if present, and issue a warning, if there is also a matching instance operator.

E.g.

interface IAlgebraic<T>{ T operator+(T other); }

struct Vector3<T>: IAlgebraic<Vector3<T>> where T : IAlgebraic<T>, new() {
  public T A,B,C;
  public Vector3<T> operator+(Vector3<T> other)
    => return new Vector3<T>(A + other.A, B + other.B, C + other.C);
}

P.S. IMHO, the fact, that users of the feature can shoot themselves in the feet by making asymmetric addition that way should not prevent legitimate use. There are users, who would be able to do that with inheritance, but nobody is arguing for it to be deprecated.

[YairHalberstadt]

However, there are many scenarios, when having operators to be static methods fail. Main one being inability to represent generic algebras, which is hindering efforts to make C# suitable for scientific computing.

Can you add this scenario to your proposal please?

[lostmsu]

@YairHalberstadt , sure, no problem. I just assumed, that everyone tried this hundreds of times, and know what I am talking about.

UPD. Moved the code sample into the initial post.

[YairHalberstadt]

Never assume 🙂

[YairHalberstadt]

There are various proposals around type classes that aim to address this problem from the opposite angle. Namely, allow interfaces to declare static members.

One disadvantage is they will only work in generic contexts.

[lostmsu]

@YairHalberstadt type classes require CLR changes, or type erasure. This needs neither.

[YairHalberstadt]

@lostmsu
No they don't. See the shapes proposal.

[lostmsu]

@YairHalberstadt the shapes proposal seems to cover what I am looking for, but the implementation cost would be much higher, and would introduce generic parameter bloat. Since CLR has (or at least used to have) very tight restrictions on the number of generic parameters, it might not be viable.

[YairHalberstadt]

The shapes proposal was proposed by Mads Torgerson, the program manager for C#. They are likely going to look very very hard into implementing it.

It could be it isn't actually manageable, but I would hold on for now...

[lostmsu]

@YairHalberstadt well, I've done that for F# back in university ~10 years ago: https://archive.codeplex.com/?p=ntypeclasses
From my experience, it is not elegant enough.

[YairHalberstadt]

Elegant, as in elegant to use, or elegant as in elegant CodeGen?

[CyrusNajmabadi]

Shapes/TypeClasses/etc. has a lot of interest at the LDM level. There are many reasons for this. However, one of hte primary ones is that it's felt that there are so many issues/proposals/things-people-want that wuold just fall under such an umbrella. So, instead of having to define 50 different features to do everythin in a one-off fashion, you just define the one large and flexible feature that subsumes all the rest at an acceptable-enough level.

[lostmsu]

@YairHalberstadt elegant as in design and semantics, and also codegen.
New type declaration keywords, the need for implicit TypeClass type parameter, a whole new set of rules to find an appropriate implicit instance.
For codegen, as I mentioned - generics bloat, which might require CLR upgrade.

[lostmsu]

@CyrusNajmabadi , as far as I can see, having type classes would not make the code in the example as elegant as it could be, because you'd still have to call T.Add(T other) instead of simply doing T + T unless what I request is implemented.

[YairHalberstadt]

You should be able to define operators in type classes, and by constraining a type parameter to a type class you would be able to write T + T as desired.

[lostmsu]

@YairHalberstadt , as under the hood the type classes are represented as interfaces, that would imply you can define operators on interfaces.

[lostmsu]

@HaloFour what is the basis then?

[HaloFour]

@lostmsu

Whether the feature solves problems and fits within long-term vision of the language.

[CyrusNajmabadi]

IMHO, "Love" here is quite skewed.

As are "jokes". You're the one who opened up that part of the discussion. I'm just pointing out that that it's not an the objective of hte C# language to minimize people making jokes about it.

[lostmsu]

You're asking for a feature in the short term. I'm explaining why that's not felt ot be appropriate.

And I am explaining why it should.

However, I did not see any argument against time-boxing the shapes feature, except that it is the way things are.

[CyrusNajmabadi]

And I am explaining why it should.

Your explanations run contrary to the LDM's goals and hte way they look at and assess features (especially features which are considered to be subsumed by some umbrella feature).

However, I did not see any argument against time-boxing the shapes feature, except that it is the way things are.

Correct. It i the way that things are. The LDM has chosen that.

[HaloFour]

However, I did not see any argument against time-boxing the shapes feature, except that it is the way things are.

Because that does not lead to good design. Time box a spike, sure, as to not spin out down a rabbit hole. But that doesn't apply to the design of the entire feature, or whether or not it will ship, regardless of when it might ship.

C# will never adopt an approach of trying to force features into a release. If that's what you need from a language you'd be better served elsewhere.

[CyrusNajmabadi]

C# will never adopt an approach of trying to force features into a release. If that's what you need from a language you'd be better served elsewhere.

indeed, it's often the opposite. If the feature isn't good enough, it will often get pulled in order to not run the risk of:

A delayed feature is potentially good; a bad feature is bad forever.

[lostmsu]

Your explanations run contrary to the LDM's goals

What are LDM's goals? I want to be clear on this.

[CyrusNajmabadi]

What are LDM's goals?

To ship the features they feel are appropriate on the timeline they deem best.

[lostmsu]

To ship the features they feel are appropriate on the timeline they deem best.

That sounds quite terrible.

[CyrusNajmabadi]

@lostmsu This doesn't seem to be going anywhere. If you would like to dsicuss things more, i highly recommend gitter.im/dotnet/csharplang or gitter.im/dotnet/roslyn

Many community and team members participate there (including former and current LDM members) and it's far more conducive to this sort of discussion.

[CyrusNajmabadi]

That sounds quite terrible.

Oh well.

[lostmsu]

Gitter does not have threads, neither does GitHub unfortunately.

[CyrusNajmabadi]

Gitter does not have threads, neither does GitHub unfortunately.

Oh well. It's up to you. It sounds like you would like to have a discussion of the process around language changes. gitter.im/dotnet/csharplang is likely to be a far better venue for that versus this github issue.

[kendrahavens]

Closed a developer community feedback as duplicate.