[Proposal] Make event a contextual keyword

[kharai-tor]

There are scenarios where "Event" can be a business object, for example an EF entity within a software created to sell tickets or a class in an event logging system.

Here are usages of @event in Sentry's .NET SDK for example:
https://github.com/search?q=repo%3Agetsentry%2Fsentry-dotnet%20%40event&type=code

In such scenarios it would be much more pleasant to just be able to name variables and parameters event instead of @event.

The event keyword appears in such a specific spot in C# grammar that it could easily be a contextual keyword(or so I think) and thus allow the word to be used as an identifier too. In fact, I assume the event keyword has been around since before contextual keywords even existed in C# otherwise it might have been one of them right from the start.

[huoyaoyuan]

Contextual keywords also existed since the beginning of C#, for the get/set accessors of properties and add/remove properties of events.

The position of event keyword is not an easily distinguishable context. It appears like a modifier of a field. All modifiers are not contextual so that they are clearly distinguishable with type name.

[kharai-tor]

So with these two examples:

event e;

event Action e;

The former could be interpreted as a type name and the latter could be interpreted as a keyword. So they could be distinguished by the number of words basically. And it seems other keywords can't appear after the event keyword so if that's true the ordering of keywords shouldn't mess with that.

Am I missing something?

[huoyaoyuan]

So they could be distinguished by the number of words basically.

It may be in theory distinguishable, but troublesome for compile and IDE to support, especially when you are typing partial code.

[HaloFour]

From a parsing perspective I imagine it wouldn't be at all difficult to make the event keyword contextual. Question is whether there's a lot of value in doing so, especially since it's easy to quote it with @. There seems to be more interest in having the compiler be a bit more opinionated about what is a keyword vs. what should be a type name, so this proposal feels like a step in the opposite direction.

[kharai-tor]

The whole thing with contextual keywords, if I understand correctly, is to allow identifiers as much as possible at the cost of making the implementation more difficult. You could have all contextual keywords as regular keywords, make the implementation easier and be able to escape them all with @. But since that's not the case and the notion of contextual keywords exists I felt that event fit in that bucket. But again, that might just be me. If no one agrees I'll close the discussion.

[davidroth]

You are not alone. Been in this situation many times and als find it ugly to use @event.
I remember that I sometimes used e instead.

[CyrusNajmabadi]

Why is @event unpleasant?

[The-Futurist]

That is all accurate. There are sections of the grammar that would need to be filled in. (The lexical grammar portions). The syntactic grammar is complete.

So what is the file for? why do they go to the trouble of generating CSharp.Generated.g4? what's it used for?

[CyrusNajmabadi]

To provide a grammar for the language. For whatever purpose someone might see fit to use it.

Also, as I mentioned above, in a very real way, it clearly documents the grammar that each branch/release of ours supports. For example, if you go into the 'features/roles' branch, you'll see the updated grammar for 'extension types'.

This also helps ensure that as we merge prs, or features back into 'main' that the language changes are easy to review and in line with expectations.

[The-Futurist]

OK, I'm still not seeing why the file is created though, seems it can only be consumed by a human reader. Why exclude the lexical definitions anyway? you might make a change at the lexical level and surely seeing that in the file would be helpful. Is this all a Roslyn question, if so I might raise it there.

[HaloFour]

I don't know if there are newer conversations. IIRC the antlr file is only there for reference, and the team has no interest in going through the motions to create and maintain a second reference parser.

dotnet/roslyn#8379
#1902

[CyrusNajmabadi]

OK, I'm still not seeing why the file is created though,

I answered this already, with several reasons given.

Why exclude the lexical definitions anyway?

I opened a pr to add them.

you might make a change at the lexical level and surely seeing that in the file would be helpful.

Agreed.

Is this all a Roslyn question, if so I might raise it there.

Feel free.

[erik-kallen]

YES, Please.

I use events (as in the theoretical concept) all the time. I use events (as in the C# keyword) pretty much never. Being able to name my "events" event instead of evt would be nice.

[CyrusNajmabadi]

The cost is marginal here. But i don't see the benefit. We have an existing solution to this. I don't see the need for two solutions.

[CyrusNajmabadi]

Remember that every feature starts at -100. A feature has to actually justify itself. So far, that's not bee present here.

[HaloFour]

as you can read the cost of changing the system to support this is deemed to far outweigh the benefits.

In this case the cost is relatively trivial, but the benefits are even more trivial, thus it isn't worth the effort.

Some grammars are designed specifically to not restrict identifiers like this

They trade one restriction for another. But if you find languages like that so much better to use, feel free to go use them. You know that C# will never be such a language, so why keep harping on it ad nauseam?

when new keywords are added in case that new keyword clashes with already used identifiers.

Which isn't relevant to this conversation as event has been a keyword since C# 1.0.

[CyrusNajmabadi]

@Korporal please keep things on topic. Halo's responses were about the costs and the continued digressions into non-c# grammars that seem to commonly come with your posts. This is the repo for C# discussion. The aspects of other languages isn't relevant here as we're not trying to follow what others do, but set our own rules and designs based on what we think is best for the ecosystem, including revisiting and relitigating decisions from 25 years ago that we haven't seen any need to change.

[The-Futurist]

Remember that every feature starts at -100. A feature has to actually justify itself. So far, that's not bee present here.

If the cost of some feature is known to be "marginal" then shouldn't that feature start at -1 or something?

[333fred]

No. The smallest "marginal" feature will still cost dozens of hours of engineering time, just in approving it in LDM, implementing, testing, adding new documentation, etc.

[CyrusNajmabadi]

No. That's the entire point. Features have to deliver substantive value. That value has to overcome the fact that any feature comes, by default, with detrimental impact to the ecosystem and community, regardless of the cost to implement it.

So the feature itself must outweigh those detriments. Often substantively for us to take it.

[The-Futurist]

So the feature itself must outweigh those detriments. Often substantively for us to take it.

I was agreeing with you, I wrote "the cost of changing the system to support this is deemed to far outweigh the benefits",

[CyrusNajmabadi]

the cost to change the system here is marginal. The gain though is even less. The feature starts at -100. We want to see real widespread benefit to warrant even considering it (even if the costs are tiny). We reject the majority of proposals here simply because the feature doesn't meet that hurdle and doesn't get championed thusly.

Also, can you please actually reply to the threads, and not start new threads :)

[The-Futurist]

the cost to change the system here is marginal. The gain though is even less.

Indeed so the cost is greater than the benefit.

[CyrusNajmabadi]

@Korporal I'm not saying it's cost vs benefit here. I'm saying, it's "benefit" period. The benefit isn't here at all regardless of cost. This could cost zero and i wouldn't take it because of detriment to the ecosystem. :)

as you can read the cost of changing the system

[CyrusNajmabadi]

We are not going to get into digressions about other languages, or minutia of cost analyses. The position for us on keywords so far is that we think they are valuable for the language and ecosystem, and that changing existing keywords to be contextual is a non-goal. If that ever changes, we'd revisit this. But for now, this has effectively been subsumed into the decisions in this space we've had several times over the lifetime of C#.