Bug 10482 – Regression (2.063): Compiler doesn't warn about prefix const

----- const int * foo(); void main() { } ----- 2.062: $ dmd test.d > test.d(3): Error: function test.foo without 'this' cannot be const/immutable 2.063: $ dmd test.d > I'm not sure how this happened, I remember we had a test-suite covering these.

This behaviour is wanted, moving const after the function name will produce an error: int* foo() const; ---- Error: function main.foo without 'this' cannot be const ---- See http://d.puremagic.com/issues/show_bug.cgi?id=10150

See also Issue 10511

This is irrelevant to Issue 10511. Global const functions are still invalid, no regressions here : http://dpaste.1azy.net/a2500829 Looks like 2.062 had bug in parser and coupled leading 'const' with function type instead of return type. IMHO this is invalid / won't fix.

(In reply to comment #3) > IMHO this is invalid / won't fix. See my comments: http://d.puremagic.com/issues/show_bug.cgi?id=10150#c4 http://d.puremagic.com/issues/show_bug.cgi?id=10150#c5 I'm reposting them here: (In reply to comment #4) > I disagree with this change, this is extremely dangerous behavior when > interfacing with C. Take a look at the following: > > ----- > extern(C) const int *foo(); > > void main() > { > *foo() = 1; // compiles > } > ----- > > The proper definition should have been: > > ----- > extern(C) const(int)* foo(); > > void main() > { > *foo() = 1; // fails > } > ----- > > It is very easy to make this mistake, it should not be silent, at least not for > module-scoped functions. > > Alternatively as a compromise I suggest we at least add this check for > extern(C) functions, because this is where this problem can occur very > frequently. (In reply to comment #4) > I disagree with this change, this is extremely dangerous behavior when > interfacing with C. Take a look at the following: > > ----- > extern(C) const int *foo(); > > void main() > { > *foo() = 1; // compiles > } > ----- > > The proper definition should have been: > > ----- > extern(C) const(int)* foo(); > > void main() > { > *foo() = 1; // fails > } > ----- > > It is very easy to make this mistake, it should not be silent, at least not for > module-scoped functions. > > Alternatively as a compromise I suggest we at least add this check for > extern(C) functions, because this is where this problem can occur very > frequently. (In reply to comment #5) > Another alternative is to make the compiler smarter, and only disallow const > where it's only applied to one function, for example: > > ----- > const int * foo(); // disallowed > > const > { > int * foo(); // ok > int * bar(); // ok > } > > const: > int * foo(); // ok > ----- > > This would be for the sake of convenience, to avoid breaking existing code.

Sorry for the duplicate paste of comment 4.

Yeah, have figure out that it is actually no-op in prefix mode now. Still not what title claims, but is.. inconvenient. Moving in that thread.

This is an intended change comes from issue 10150, so is not a regression. Today dmd never distinguishes prefix storage class and scopes/labeled ones. That's a design decision which sometimes talked by Walter. But also, I can agree that it is a little bug-prone behavior. So I switch this into enhancement issue.

(In reply to comment #7) > This is an intended change comes from issue 10150, so is not a regression. > > Today dmd never distinguishes prefix storage class and scopes/labeled ones. > That's a design decision which sometimes talked by Walter. > > But also, I can agree that it is a little bug-prone behavior. > So I switch this into enhancement issue. Yep, it is not a regression but a breaking change introduces by 10150, which should not have been implemented in the first place. I wish I have noticed that pull request before it was merged. There is currently minor discussion on topic in 10150 thread.

Another case from the IRC by someone new to D: ----- import std.stdio; int hidden[4]; ref const int[4] getConstHidden() { return hidden; } void main() { writeln(hidden); foreach (ref i; getConstHidden()) i = 1; writeln(hidden); } ----- This needs to be fixed.

I opened identical issue 12967, and it has been fixed in 2.066. *** This issue has been marked as a duplicate of issue 12967 ***