Relax CS0571 (cannot explicitly call operator or accessor)

[jl0pd]

CS0571 is generated whenever someone tries to access underlying method of accessor or operator. For example

class MyClass
{
     public event EventHandler Changed;
     public int Value {get; set;}
     public int this[int idx] { get => 0; set { } }
}

var c = new MyClass();
c.set_Value(42);
c.get_Value();
c.get_Item(7);
c.set_Item(7, 42);
c.add_Changed((sender, e) => {});
c.remove_Changed((sender, e) => {});

All of the invocations raise CS0571. This behavior seems redundant, compiler should warn or tooling should just hide members (like when [EditorBrowsable(EditorBrowsableState.Never)] is used). I guess it was introduced at C# 1 timeframe, when properties were new feature for mainstream language and compiler team decided to force users to use proper syntax. It was fine and justified for some period of time, but now a lot of methods take delegates as input and some people may want to get better performance by reducing allocations. One problem is that code foo(() => capturedVar.Property) produces 1 more allocation compared to foo(capturedVar.get_Property).

Today I've had a need to pass delegate, which would take item from dictionary

var dict = new Dictionary<int, int>();
// instead of
// foo(dict.get_Item);
// I have to write
foo(x => dict[x]);

Another example is System.Reactive:

using System.Reactive.Linq;

public class Foo
{
    public event EventHandler MyEvent;
}

var foo = new Foo();
Observable.FromEventPattern(foo.add_MyEvent, foo.remove_MyEvent); // CS0571
Observable.FromEventPattern(h => foo.MyEvent += h, h => foo.MyEvent -= h); // clunky

I ask to relax CS0571 and either

1. change it from error to warning, which could be suppressed
2. remove error altogether and hide accessors by tooling (better option)

[bernd5]

These helper methods are just implementation details - it would be possible to implement them in different ways.

I would not like to leak those details. You can wrap every property accessor in a lambda, so you get a proper delegate:

var c = new MyClass();
var c_setValue = (MyClass c, int v) => c.Value = v;
var c_setValueCaptured = (int v) => c.Value = v;

c_setValue(c, 42);
c_setValueCaptured(44);

The compiler could recognise such lambda creations and optimize them away...

[HaloFour]

ECMA335 suggests that they may typically be named in this convention but there is no requirement to do so and the runtime doesn't care what they're called (or even what their signature is). Although a compiler can't just go and change the convention without breaking all assemblies that depend on the current convention.

[john-h-k]

It is required for CLS compliance no?

[jl0pd]

It is required for CLS compliance no?

II.22.28

9. Any getter method for a property whose Name is xxx shall be called get_xxx [CLS]
10. Any setter method for a property whose Name is xxx shall be called set_xxx [CLS]

[HaloFour]

CLS is just a suggestion and a great deal of what you can do in C# isn't CLS compliant. Honestly I don't think CLS has ever been particularly relevant.

[bernd5]

The spec just says that the signatures are reserved - but those are not mandatory regarding the spec.

See: https://github.com/dotnet/csharpstandard/blob/draft-v7/standard/classes.md#143102-member-names-reserved-for-properties

[jl0pd]

These helper methods are just implementation details - it would be possible to implement them in different ways.

Is will be a major breaking change for 20 years of code. Nobody will change it.

I would not like to leak those details

It's a well-known detail of how properties are implemented.

By the way, F# allows to do same thing

open System
type MyClass() =
    member val Value : int = 0 with get, set
    member _.Item 
        with get idx = 0 
        and set idx value = ()
    
    [<CLIEvent>]
    member _.Changed = Event<EventHandler, EventArgs>().Publish
    
let c = MyClass()
c.set_Value(42);
c.get_Value();
c.get_Item(7);
c.set_Item(7, 42);
c.add_Changed(fun sender e -> ());
c.remove_Changed(fun sender e -> ());

[CyrusNajmabadi]

and some people may want

Generally speaking, this is an appropriate argument when backed with feedback from said group. i.e. if we actually saw tons of people asking for this, then that would help make the case that people want this and we should reconsider. However, if it's been 20 years and there's only a single ask for this in all that time, it seems far more likely that very few people actually want this and the existing solutions are sufficient in practice.

[Joe4evr]

True. And while I believe this doesn't meet the bar anyway, I do recall a previous ask for getting a delegate to a type's constructor (which I'd consider in the same bucket and similarly niche).

[TahirAhmadov]

I agree with @Joe4evr, it looks to me like OP is asking for property/event delegate creation, which I think is worthwhile. He figured the best way would be to expose the accessor methods in the language, but I think there may be a better way, and there are other discussions which request this, but I couldn't find them easily.

[colejohnson66]

There’s been times where I’ve wished for features, but I never mention them. This one in particular I have wished for, but never requested because a wrapper delegate works good enough.

[Overruler]

I would like to call operators explicitly, because I'm trying to figure out why foreach (Series series in chart1.Series[0..3]) results in CS1503 Argument 1: cannot convert from 'System.Range' to 'string' and I can't use Visual Studio's Go to Definition command to navigate to where the operator is implemented, but, if I could call that operator like it were just another regular method, then Visual Studio should go to the definition without any problem, by my reasoning.

• I don't see operators mentioned in the interceptors proposal and that proposal seems open to some interceptions never being possible, so that's not an alternative as it is.

• I doubt it's possible to implement a generic extension method that wraps an operator, given the variance over class/struct types, nullability and implicit conversions, so converting operator overloading into method calls without altering the semantics seems infeasible.

As such, I think the only option is for the language to provide this feature. I see no reason why syntax for an alternative way of invoking the code that implements an operator shouldn't be provided.

[siegfriedpammer]

You should be able to navigate to the indexer in VS by ctrl-clicking on the [ if I am not mistaken..., just like you can hover over any operator in VS to see it's signature.

The Series collection/type most likely only provides indexers accepting int and string, but not a System.Range... It's up to the implementation to add support for the new language feature.

[BlinD-HuNTeR]

I would like to suggest two different approaches:

1 - Instead of exposing the accessor methods directly, maybe C# could introduce the :: operator just like in Java, allowing you to use a property accessor as a "method group" for a delegate, while still forbidding direct calls to it. So it would become foo(capturedVar::Property), and for an indexer, it could probably be foo(capturedVar::this).

2 - If the problem is just the extra allocation, then I suppose Roslyn could improve the management of captured variables, such that if a single object reference is captured in the lambda, use that object directly as the delegate target, instead of synthesizing a "DisplayClass" to contain the variable and method body. With this approach, the body of the delegate would become a static method, that takes the captured object as the first parameter, and the delegate would be a "closed delegate pointing to static method", with the captured object as the delegate target.

This kind of delegate can already be produced currently through the use of extension methods, you can use an extension method as method group, and the delegate will point to that method directly, while capturing the "this" parameter as the target.