http://d.puremagic.com/issues/show_bug.cgi?id=4070

           Summary: prefix const on member functions considered confusing
           Product: D
           Version: 2.041
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: simen.kjaras@gmail.com


--- Comment #0 from Simen Kjaeraas <simen.kjaras@gmail.com> 2010-04-05 10:26:45 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4070


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2010-04-05 12:43:18 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4070


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-04-05 13:44:02 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4070



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2010-04-06 02:28:21 PDT ---
Your points are good ones, but I just feel that introducing another special case into the syntax for attributes will make things worse.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4070


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #4 from bearophile_hugs@eml.cc 2010-04-11 09:02:16 PDT ---
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++);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4070



--- Comment #5 from bearophile_hugs@eml.cc 2012-05-04 13:05:39 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------