Proposal: Custom Operators

[MovGP0]

There should be a way to create custom operator extensions. They are very useful in creating DSLs. Examples:

Often used Methods

See also: #170

public static class StringExtensions 
{
    public static string operator (??!) (this string left, string right) 
    {
        return string.IsNullOrEmpty(left) ? right : left;
    }
}

usage:

var result = left (??!) right;

generated code:

var result = StringExtensions.op_QmarkQmarkBang(left, right);

Mathematics

public static class VectorExtensions 
{
    // '~' indicates a prefix operator 
    public static Vector operator (~-) (this Vector vector) 
    {
        return new Vector(-1.0 * vector.X, -1.0 * vector.Y);
    }

    public static Vector operator (*) (this Vector vector, double value) 
    {
        return new Vector(vector.X * value, vector.Y * value);
    }

    public static Vector operator (*) (this double value, vector) 
    {
        return vector (*) value;
    }

    // ...
}

Parser Generators

See also: FParsec.Primitives

public static ParserExtensions 
{
    public static Parser<B, U> operator (>>=)<A,B,U> (this Parser<A, U> p, Func<A, Parser<A, U>> f)
    {
        // ...
    }

    // ...
}

See also

• Operator Overloading (F#)

[ygc369]

I like this idea.

[iam3yal]

@MovGP0 Why?

Do you really think that the following:

var result = left (??!) right;

Is more clear/readable than this?

var result = string.IsNullOrEmpty(left) ? right : left;

What would happen if two libraries define the same operator but they have different semantics for it?

What would happen if the designer at some point will introduce the operator ??! into the language? wouldn't it confuse people because there could be nearly two identical operators?

[MovGP0]

@eyalsk no I don't. Proposal #170 is mostly to save on typing. Mentioning it was simply my way to give an very easy example.

The real usefulness lies in complex scenarios like mathematics, parser generators, SMT solvers, and the like.

[iam3yal]

@MovGP0 Can you give me a complex example then that using a method is a blocker? or/and can you answer my questions?

[MovGP0]

@eyalsk

"Can you give me a complex example then that using a method is a blocker"

you can always use a named method instead. the intention behind of having a DSL with custom operators is to improve the expressiveness of the language, which in turn improves readability and reduce typing.

---

"What would happen if two libraries define the same operator but they have different semantics for it?"

This is the same issue with every extension method. You would have to give the full namespace:

var scaledVector = VectorExtensions.(*) (vector, factor);

---

"What would happen if the designer at some point will introduce the operator ??! into the language? wouldn't it confuse people because there could be nearly two identical operators?"

There is a difference between (*) and *. The first is the extension method while the second is the operator of the class.

And yes, this might confuse people occasionally, but I'm not expecting the language to introduce new operators when you can use extensions instead.

[iam3yal]

@MovGP0

you can always use a named method instead. the intention behind of having a DSL with custom operators is to improve the expressiveness of the language, which in turn improves readability and reduce typing.

Improving readability is extremely subjective, you know that. :)

This is the same issue with every extension method. You would have to give the full namespace:

Nop it's not because methods operate on objects and you (the programmer) can understand from the context on what you operate.

It is not the same with operators, if you have two operators that have the same syntax but different semantics then mixing them in the same codebase would be cumbersome and confusing.

There is a difference between (*) and *. The first is the extension method while the second is the operator of the class.

Yes, I understand but I think that it would be confusing.

Just stating my opinion here but I think that many people confuse terseness with readability, if symbols have well defined meaning, I don't mind it and in fact I prefer it but I'm against defining arbitrary symbols, maybe it just me though, dunno. :)

[GeirGrusom]

Kotlin supports something like this called infix operators functions. It's very useful.
Basically extension methods that you can call using infix notation.

For example, kotlin-test has something like this:

should("name be equal to Goofy") {
    character.name shouldBe "Goofy"
}

Where shouldBe is an infix operator that may throw an assert exception.

What precedence order should extension operators have?

[orthoxerox]

Custom operators are a nifty idea, but only if the language has been designed from the ground up to support them.

You could try adding them to Roslyn yourself to see the amount of effort that is necessary to support them in the parser and beyond. Even if you take a shortcut and base their precedence on the first character to avoid rewriting the whole syntax tree after obtaining semantic information, it's still a whole lot of work and syntactic ambiguities are still there.

Should a! !b be parsed as (a!) ! b or a ! (!b)?

[iam3yal]

@GeirGrusom Does it allow you to add these infix operators as symbols?

[GeirGrusom]

@eyalsk No; they follow the same rules as identifiers.

[MovGP0]

@orthoxerox to avoid ambiguity, the expressions would be evaluated from left to right.

Assuming that you have the following code:

public static class ComplexExtensions
{
    public static Complex operator (*) (this Complex left, this Complex right) {
        return left * right;
    }

    public static Complex operator (*) (this Complex number) {
        return number.Conjungate();
    }

    public static Complex operator (~*) (this Complex number) {
        return number.Inverse();
    }

    public static Complex operator (**) (this Complex number, double exponent) {
        return number.Pow(exponent);
    }
}

the expression var r = a (**) b; would map to

var r = ComplexExtensions.(**) (a, b);

the expression var r = a (*) (*) b; would map to

var a1 = ComplexExtensions.(*) (a);
var r = ComplexExtensions.(*) (a1, b);

while the expression var r = a (*) ((*) b); would map to

var b1 = ComplexExtensions.(~*) (b);
var r = ComplexExtensions.(*) (a, b1);

[MovGP0]

@GeirGrusom named operators aren't the goal here. Existing extension method mechanisms handle those cases just welll:

[Then("name should be equal to (.*)")]
public function void NameShouldBeEqualTo(string name)
{
    var character = TestContext.Get<Character>();
    character.Name.Should().Be(name);
}

see also:

• SpecFlow
• Fluent Assertions

[GeirGrusom]

@MovGP0

named operators aren't the goal here

I didn't say it was, just that there is a language with a similar functionality and that the feature is very useful in practice.

Existing extension method mechanisms handle those cases just well

I could make the exact same claim about your proposal.