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.

[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.