Fix Issue 15379 - "final" attribute on function parameter

[ntrel]

final is not allowed here in D2.

void foo(final int a){} // error!

finalpar.d(1): Error: variable `finalpar.foo.a` cannot be `final`, perhaps you meant `const`?

[dlang-bot]

Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	15379	normal	"final" attribute on function parameter

[dkorpel]

It's not a parse error though, this compiles:

version(none) void foo(final int a) {}

So the grammar should allow it.

[ljmf00]

It's not a parse error though, this compiles:

version(none) void foo(final int a) {}

So the grammar should allow it.

Why we should allow something that apparently doesn't have a useful meaning? I think moving the error to the parser, if we can have the same kind of error message, and fixing the grammar is a good path. Otherwise, if this has some meaning for templates, we should perhaps update the spec?

[dkorpel]

Why we should allow something that apparently doesn't have a useful meaning?

I meant to say "the grammar should allow it or the implementation should be updated to match the new grammar".

I think moving the error to the parser, if we can have the same kind of error message, and fixing the grammar is a good path.

There are plenty of errors that could be caught by the parser but are currently caught during semantic analysis, keeping the grammar simpler.

version(none) 
void f() scope {
    break;
    default:
    switch (0) {}
    "useless";
}

I'm not against changing the parser here per se, but moving errors to parse time isn't a "good path" by default.

[ntrel]

There are plenty of errors that could be caught by the parser but are currently caught during semantic analysis, keeping the grammar simpler.

In this case the grammar is not simpler. I think the reason it parses was for the error advising to use const. That error is probably not needed anymore, or could perhaps be done in the parser. If not, the spec should note that final is not valid here.

[ntrel]

I think the reason it parses was for the error advising to use const

Perhaps it was so D1 and D2 code can co-exist in the same module? So perhaps it should still parse if this is still a goal.

[ntrel]

As this seems intentional to not error on parsing, I have added a note to the docs instead of removing final.

@dkorpel Can you remove the waiting for dmd label now please?