Bug 4070 – prefix const on member functions considered confusing

struct foo { const foo* bar( ) const { return new foo; } } This function does not return a const foo, as one might expect. Rather, it is twice specified that this function does not change any members of foo. This is troublesome because, everywhere but in a function declaration, const foo* would be equivalent to const( foo* ). It is hence a source of confusion and inconsistency. If this is a case of unfortunate C++ inheritance, please make const foo bar( ) an error, and enforce the use of parentheses. If not, get rid of it.

It's current behavior is consistent. Const without parentheses applies to the outermost declaration. So, for: const foo* bar(); the const applies to the outermost part of the type, which would be the function type, not the function return type. The following syntactical usages of const all have the same meaning: const: foo* bar(); and: const { foo* bar(); } and: const foo* bar(); as all attributes behave the same way.

The point is that it's confusing, not inconsistent. It's confusing to read since the this parameter is hidden. Yes, it's consistent and unambiguous, but it's confusing. It's your prerogative not to disallow the syntax, but keep in mind that allowing the const before a function that returns a type will result in most style guides advising against it because it's too confusing. Effectively, the fact that it's confusing will negate its usage. Isn't one of the goals of the programming language to come up with consistent, *sensible* syntax? This is compounded by the fact that the const qualifier has an alternative location.

Your points are good ones, but I just feel that introducing another special case into the syntax for attributes will make things worse.

Thinking some more about this I can add: A possible piece of the Zen of D language: Special cases in the language are bad, but sometimes they can be acceptable if they turn a consistent behaviour that can lead to mistakes/bugs into a good compile-time error. An example of this is disallowing: for(int i;i<10;i++);

Symmetry is good in a language, because it makes the compiler smaller, the language manuals smaller, and makes it simpler for programers to learn the language. But breaking symmetry is acceptable if this helps avoid bugs. A thread where "Manu" has found a problem caused by const prefixing: http://forum.dlang.org/thread/CAOC+-J9Pw31mMSSnCR4kC89siNYkg27Lm7CNk7r+prRo+DQq=Q@mail.gmail.com I invite people to add more cases in this thread.