Allow trailing semicolons at the end of property declarations

[irvnriir]

Can CS1597 be removed? Why saving space of 1 per hundreds of chars in expense of simplicity and even consistency, is enforced?

Is there any functional reason for it?

When writing alot, or prototyping, i get builds failing because of this. And as far i see, it has no functional purpose.

Even if it isn't needed for the lang, it could be added as a warning, but why in a world its a compilation error so can't even be disabled user-side?

[CyrusNajmabadi]

The build doesn't crash here. An error is given stating you have a superfluous token.

We'd need to update the grammar here to allow this, and that would need a compelling argument as to why to allow this.

[irvnriir]

There've been a long discussion on Discord. As the last bits, the reasoning for not doing this, was that statements which affect a {<<..>>} block could be added after that block as a feature in future.

p.s.

this your response above, is just a request to write-up the process of how and why the following happens:

When writing alot, or prototyping, i get builds failing because of this.

i would suggest/request to try making functional constructive responses next time. ty for attention.

[CyrusNajmabadi]

i would suggest/request to try making functional responses next time.

You're asking for a change to the language, as i stated: that would need a compelling argument as to why to allow this.

That still remains the case. We won't make any changes without strong reason to do so.

i would suggest/request to try making functional responses next time.

As per the prior conversation, please abide by the .net code of conduct. This includes treating people with respect and having constructive conversations on the myriad aspects of language design that we discuss here. Thanks.

[FaustVX]

@irvnriir

There've been a long discussion on Discord. As the last bits, the reasoning for not doing this, was that statements which affect a {<<..>>} block could be added after that block as a feature in future.

p.s.

this your response is just a request to write-up the process of how and why the following happens.

When writing alot, or prototyping, i get builds failing because of this.

i would suggest/request to try making functional constructive responses next time. ty for attention.

Maybe I'm missing something, but why are you responding to yourself ?

[irvnriir]

@FaustVX i'm not. i initially had a sentence after the ".", idk if thats allowed in English, but that doesn't cause any confusion afaik. i also was too tired to notice the ".", though in accordance to my previous sentence, i think it didn't require fixing.

Edit: the missing above was technically an error, but i omitted it in attempt to be more polite/neutral.

[CyrusNajmabadi]

Is there any functional reason for it?

yes. the grammar defines teh syntactic rules of the language. And having our compiler not deviate from those rules is something we consider very important. This ensures consistency among users about how to read/write C#, and it means we don't introduce deviations into our compiler that then potentially interfere with future language changes.

When writing alot, or prototyping, i get builds failing because of this.

Deleting hte extra semicolon seems pretty simple and cheap to do. What is causing the extra semicolons in the first place? What other extraneous tokens do you have when prototyping?

but why in a world its a compilation error so can't even be disabled user-side?

It's illegal syntax. Like with all extra tokens or missing tokens, we can guess what you might have meant, but we really have no idea. And since we don't know, we fail (like every other mainstream compiler out there).

[CyrusNajmabadi]

It works in some constructs. But there are many more it does not. We have examples in discord with you :-)

[CyrusNajmabadi]

there is no complexity

There is. We shared a huge area of complexity with you in discord. This overlaps future design space ideas we have.

This is a critical part of lang design. The designs have to fit with the past and also feel like they will not impede the future.

Furthermore, complexity (even if small) would be only one part of the concerns here. The other concerns already listed still apply. All of that needs to be considered as a whole for every proposal.

[irvnriir]

adds complexity. And it potentially interferes with future design space.

its 2 different things. whether to allow "};" or not, doesn't affect complexity, though that depends on whether allowing "};" makes sense to you. in code its 1 if in a list, so no structural complexity either.

Furthermore

thats why i said "little fix".

[CyrusNajmabadi]

It does affect complexity. We went over this in depth in discord. I also listed the issue above with this, especially as it impacts future design work in this space.

[CyrusNajmabadi]

in code its 1 if in a list, so no structural complexity either.

This is not the case. Every feature that operates syntactically on property declarations needs to be updated. That is inherent complexity.

Note. This is not a hypothetical. We've slightly changed the syntax to support tiny changes like this to a few constructs. Like allowing using to end with a semicolon, as well as namespace decls. As well as a ton of other "seemingly tiny" grammar changes. They have a lot of complexity because we have thousands and thousands of lines that expect the tree to look a certain way.

As a core example, this will break intelligence for the token following the ; until we go and fix that feature up to understand this. That's just one of a huge number of features.

[CyrusNajmabadi]

Why saving space of 1 per hundreds of chars in expense of simplicity and even consistency, is enforced?

It's not to 'save space'. It is simply that we have grammar rules. And if one wants those grammar rules to encompass more token sequences, then the grammar needs to be updated accordingly. The spec also needs to then say what the impact of that extra token is (even to say that it is ignored).

the reason we don't normally do this is simply that it adds excess to the language, compiler, and all higher tooling that in practice doesn't make things substantively better for users. We generally only want this sort of syntactic flexibility if there is a big win for users. For example, there are compelling cases to be made about allowing trailing commas in lists, due to users have something like:

   x1, 
   x2, 
   x3, 
   x4,

And wanting to be able to reorder those easily by just moving lines around. If the last comma is not allowed, this becomes more annoying. This is at least something we can identify as something a large set of users do and find value in, and so we allow this sort of extra, technically not necessary token.

However, there an infinite number of extraneous tokens people could place anywhere. adding support for everything is not viable. So we add hte support where there is a compelling case for it, and there is a clear indication a lot of people would be helped out. That is not the case here afaict.

[irvnriir]

the topic is about a specific case, not randomly picked token at randomly picked spot. but at the time i don't state this to have a large or widespread impact.

[CyrusNajmabadi]

the topic is about a specific case

yes. And i'm explaining how we assess individual cases. That involves showing an example of where we would consider adding support for extra syntax, and the difference between the two.

but at the time i don't state this to have a large or widespread impact.

Right. And i'm stating that that's something we care about. We are unlikely to make changes if they're not goign to have substantive benefit to our ecosystem. There are millions of users we have to cater to, and we cannot invest in one-off features that will help one user out in their particular use case.

[irvnriir]

.. That involves showing ..

your example, and parts of the response, are good. i should've quote the part which i was responding too.

[CyrusNajmabadi]

I'm locking this at this point. Both in discord and here there appears to be no attempt to provide any sort of justification for this feature. Furthermore, the op doesn't seem interested in understanding the design process or the critiques levied against this.

This conversation seems to have run its course and no efforts are being made to substantively engage here.

More time has been spent arguing there and here than the ecosystem would ever will back in time spent on this proposal. @irvnriir I recommend for future proposals that you be more willing to accept that a feature needs to be more valuable to us than just helping you so you can avoid a single char mistake. Think broadly about the millions of other users out there and whether or not this will meaningfully affect them. If so, be prepared to argue and demonstrate why that is.