Add a quick refactoring , About delegate and event

[zms9110750]

Similar to encapsulating fields as property and reducing complete property to automatic property,
The syntax and property of events are similar, and I believe they should also have similar refactoring.

public event Action Action = () => { };

public Action action = () => { };
public event Action Action { add => action += value; remove => action -= value; } 

Compared to refactoring to simplify developer operations, I need this menu to tell newcomers that events and delegates are different, and how they are different.
The refactoring of fields helped me understand fields, property, and automatic property.
This refactoring can also help others understand delegate and event.

[CyrusNajmabadi]

@zms9110750 can you change your post to use the term 'property/properties' instead of 'attribute/attributes'? "Attributes" are something else entirely in C#. Namely [XXX(true, false)] void MyMethod() { }. It took me a long time to figure out what you were trying to say here because of this :)

[zms9110750]

I'm very sorry, I'm using machine translation

[CyrusNajmabadi]

@zms9110750 Not a problem, and nothing to be sorry about :)

[CyrusNajmabadi]

@zms9110750 Thanks for updating the original post. I will say that I am a bit confused about the request. It's worth noting that just like fields/properties, events also support the dual-representation of storage vs computed. For example, here is an event which will be backed with explicit storage in the type:

public event Action E;

With this declaration, consumers can do .E += ... and .E -= ....

However, you are not required to use the form that specifies explicit storage. You can also use the property-like form:

public event Action { add { ... } remove { ... } }`

And you can control how the add/remove actually computes at runtime. THe consumer's perspective will be the same though, They'll still do: .E += ... and .E -= ...

So... it's unclear what change you'd actually like in the language, as i think the language does work in teh way you're asking for.

--

However, it's very possible i'm misunderstanding your post. If you can shed some more light on this, that would be great. Thank you!

[HaloFour]

Is it really that common to want to set a default delegate to an event handler declared within a type? I suspect not.

Beyond that, I'm not sure what you're asking for here. If blob posts online are getting their description of "events" vs. "delegates" wrong, that's not really a problem with the language. This event syntax has been in the language since C# 1.0 and it hasn't been an issue.

[zms9110750]

@HaloFour Yes, they were wrong. But we cannot comment in the most prominent position under each blog or video.
But such a refactored menu can replace the debate about them. And help c # learners understand what is correct.

A more detailed description is that I did not request any modifications to the C # language, I only want to request modifications to the functionality of Visual Studio. I am not sure if modifications that are only valid for c # should be published to VS's community (another issue is that I cannot find VS's community)

[CyrusNajmabadi]

I only want to request modifications to the functionality of Visual Studio.

What modifications do you want to see to Visual Studio?

[zms9110750]

@CyrusNajmabadi
As I mentioned, add a quick refactoring for events and delegates. Its function and description are like to

• Encapsulate delegates as events
• Encapsulate delegate events and still use delegates
• Expand an event into a complete event
• Simplify events into automatic events

[HaloFour]

In my opinion, the only one of those that might make sense would be to refactor a public delegate field into an event. The rest don't feel very applicable, if anything they might encourage bad practices. Converting to/from explicitly defined events feels dangerous. The amount of code that the compiler emits in order to ensure that adding/removing a subscriber is thread-safe is not trivial.

I also don't see where there is a problem here. The documentation in the language is pretty clear about where and how to use events, and definitely suggests using the simpler form. I've never heard of this being a source of confusion, and it's been a part of the language for more than 20 years.