Auto implemented operators

[ja72]

If an operator is defined for a type to automatically define it for an IEnumerable of that type. Now you can only fly manipulate collections in predefined ways (like negating all numbers) without having to explicitly write out .Select() or .Zip() every time.

To negate the first 10 items of an array you now need

B = A.Take(10).Select((x)=>-x).ToArray()

vs

B = -A[0..9]

Which one is clearer to the reader?

Auto implemented operators should work as follows:

• Operator on one collection results into a collection (similar to .Select( x=> -x ))
• Operator on two collections results into a collection (similar to .Zip( (x,y)=> x-y ))
• Operator on a collection and a single item results into a collection (similar to closures .Select (x=> x-a))

So off the bat, users can start manipulating collections of integers, string, & floats without any additional coding effort. To manipulate collections of custom types, obviously the appropriate operator should be declared in the type.

[ja72]

This would truly make collections first class citizens, dare I say it, just like Fortran ;-)

[DarthVella]

That's the sort of behaviour I'd expect shapes and extensions to be able to implement.

public extension AddableEnumerable of IEnumerable<T> where T : Addable
{
    public T[] operator +(T left, IEnumerable<T> right) => right.Select(x => x + left).ToArray();
}

etc etc

[DavidArno]

Have a read of the range feature, which might see the light of day with v7.3.

[ja72]

@DarthVella The point is that the programmer wouldn't have to write any extra code to operate with collections. If the a type has an operator, then the collection of the type should have it also.

class A
{
    public static A operator - (A a1, A a2) { return /* implement logic */ }
}

and later in code

A[] foo, bar;
// and later ...
var result = foo-bar;

[ja72]

@DavidArno The range feature was the inspiration for this issue. I can see how auto implemented operators work to enhance ranges. It is also how Fortran operates with the elemental keyword, saving programmers from having to write countless loops by vectorizing the code.

[HaloFour]

I disagree. The container is not it's elements and the nature of the behavior of the operator on the container would be expected to be different from on its elements. For example, why would + mean to add up the elements between two collections vs. concatenating the collections together? How would the operator deal with collections of disparate sizes? You're asking the compiler to bake in a lot of policy automatically, and I don't think that's a good idea.

For your original example of getting a range in an array, C# is introducing slices (or spans) and they're looking to implement a range operator which can be used in indexers. That will solve that need nicely.

[ja72]

@HaloFour

1. The operator would have the same semantics as the underlying type.
2. Unequal lengths of collections are handled the same way Enumerable.Zip() does. Nothing new would be required.

Essentially this is just syntactic sugar, replacing the operator with the appropriate LINQ statement

[HaloFour]

@ja72

Essentially this is just syntactic sugar, replacing the operator with the appropriate LINQ statement

I argue that it's unnecessary. For as infrequent as something like this would come up you already have a relatively quick and easy way to accomplish it via LINQ which puts much more control in the hands on the programmer.

[ja72]

@HaloFour in the area of scientific computing this comes up all the time. Possibly in the area of Graphics also (like operating on collections of PointF) where the user cannot append the underlying class with a new operator. You don't think the users would prefer (A+2*B)/3 to A.Add(B.Multiply(2)).Divide(3)? The whole point of operators is to make code more readable and natural. Sequencing LINQ statements isn't as natural common mathematical conventions.

PS. Thank you for looking into this.

[HaloFour]

@ja72

You can always write your own collection class which does implement the overloaded operators and use that. Once and done. Could even be in a NuGet package. There's no reason to do that down at the language level.

[CyrusNajmabadi]

Possibly in the area of Graphics also (like operating on collections of PointF) where the user cannot append the underlying class with a new operator

You would not want operators working this way in graphics. Your example: A.Take(10).Select((x)=>-x).ToArray() would be death. The allocation of the new array would never be allowed. You'd either apply the operator to each value, putting the result into an already allocated buffer that you reused, or you'd apply the operator in place.

[ja72]

@HaloFour

I know I can write my own (which I have for every custom type I design). The point being that it is automatic and I would never have to write yet another silly wrapper code that takes a collection and operates on each element. Lets free the user from boilerplate code. Make collections a first class citizen and use the existing design of classes to reduce unnecessary code.

[CyrusNajmabadi]

@HaloFour in the area of scientific computing this comes up all the time.

I've done this sort of computing. In those specific cases, we simply did this:

struct MySpecialVector {
  private readonly double[] values;
  public double this[int i] => values[i];

   public static MySpecialVector operator ...
}

Now we can define all the semantics we want precisely, without having inefficient implementations supplied by having these operators translate out to Linq calls. Linq would be absolutely a non-started in the scientific and graphics spaces due to the allocations and overhead.

[CyrusNajmabadi]

Make collections a first class citizen

This is really hard to do due to the different domain requirements that people have. Especially the people that want to operate over collections in a numeric manner.

First, this is a non-starter for any sort of operation that would cause an allocation. No one is going to apply an operator over their million element collection if it allocates another million elements. :)

[jnm2]

I want to second Cyrus. Wrapping primitive concepts like ints and arrays in a struct to endow special semantics of validation or behavior is something that has paid off for me.