[Proposal] Expose methods for property and event accessors

[ashmind]

Problem

It's sometimes convenient to use an event or property accessor in a generic way.

For example, property cannot be passed by reference, but you might want to pass its setter. In current language this is often done by v => x.Property = v, which is an extra delegate that is verbose, inefficient, and hides property from type inference of the enclosing call.

In the same way, any generalization over event attachment or removal would require a similar delegate, and often even more verbosity around explicit types.

Solution

Provide a syntax to use accessors directly, for example:

x.MyProperty::get
x.MyProperty::set
x.MyEvent::add
x.MyEvent::remove

(Probably a terrible syntax, but demonstrates the idea)

Internally, this will compile to x._getMyProperty and similar, which already exist.

Problems

This would need a good syntax.

Personally I wouldn't mind x.MyProperty.get where any existing member named .get would have priority -- but it might not be good enough. Alternatively, while syntax like getterof() is almost as verbose as the delegate, it still has type inference and saves an anonymous wrapper method.

Alternative

Eliminate CS0571 (but still hide these members unless accessed explicitly).
It's unlikely CS0571 is enough to allow compiler a change in name generation anyway.

[dsaf]

Related to #1653.

[HaloFour]

How would you pass a property setter if not by a delegate? You mean trying to pass off a property in place of a ref parameter? I don't see how the compiler could accomplish that.

[alrz]

didn't #5444 address this?

[orthoxerox]

@alrz not really.

A property behaves like a field of some type T, but is actually a pair of Func<T> and Action<T> accessor method. This proposal would allow us to access these accessors directly to pass them around. For example, take a look at this SO question: http://stackoverflow.com/questions/27034107/passing-and-storing-a-reference-to-an-object-field-to-another-object-without-ref . You can see a double delegate x=>prgTest.Value=x, I don't know if Roslyn optimizes it away or not. Of course, ref fields would solve the same problem as well.

[alrz]

@orthoxerox Exactly, in #5444 you can get that pair of delegates

// without an instance
Func<Foo, int> getter = Foo::MyProperty;
Action<Foo, int> setter = Foo::MyProperty;
// with an instance
Func<int> getter = foo::MyProperty;
Action<int> setter = foo::MyProperty;

[HaloFour]

@orthoxerox It doesn't result in a double-delegate invocation. There is only one delegate invocation, but that calls a helper method on a display class created in order to hold onto the enclosed instance. Creating the display class does involve an allocation and I don't know how aggressively the JIT could eliminate that. It would be nice if Roslyn could detect the delegates of properties and optimize them.

Method references should at least eliminate the need to have to use a lambda go-between and to get a delegate directly to the property accessor method.

[alrz]

IIRC Delegate.CreateDelegate uses BindToMethodName or BindToMethodInfo and that's what the point is in that proposal, avoid that additional lambda.

[ashmind]

Sorry for the confusing description. What I meant is eliminating an internal class/method created by the compiler -- of course in a delegate use case there would still be a delegate, but it would point directly at an accessor, as people noted above.

[ashmind]

@alrz Your example of #5444 syntax is interesting, but does not seem to cover events?

Overall #5444 seems like it can be combined with this proposal into something like User::FirstName.get which would be simpler for overload resolution as you don't have to consider both Action and Func.

[ashmind]

@orthoxerox

Of course, ref fields would solve the same problem as well.

Not completely, as ref is less flexible than a delegate -- you can't pass it into some nested lambdas, etc.
Though one alternative I considered was having ref x.Y convertible to some Ref<T> with set/get delegates and maybe even a Name. That would have been amazing, but I have a feeling C# team wouldn't go that far.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.