www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4070] New: prefix const on member functions considered confusing

reply d-bugmail puremagic.com writes:
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: -------
Apr 05 2010
next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 11 2010
prev sibling parent d-bugmail puremagic.com writes:
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: -------
May 04 2012