digitalmars.D.bugs - [Issue 4070] New: prefix const on member functions considered confusing
- d-bugmail puremagic.com (28/28) Apr 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4070
- d-bugmail puremagic.com (26/26) Apr 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4070
- d-bugmail puremagic.com (20/20) Apr 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4070
- d-bugmail puremagic.com (7/7) Apr 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4070
- d-bugmail puremagic.com (14/14) Apr 11 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4070
- d-bugmail puremagic.com (11/11) May 04 2012 http://d.puremagic.com/issues/show_bug.cgi?id=4070
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 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
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 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
http://d.puremagic.com/issues/show_bug.cgi?id=4070 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy yahoo.com 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
http://d.puremagic.com/issues/show_bug.cgi?id=4070 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
http://d.puremagic.com/issues/show_bug.cgi?id=4070 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc 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
http://d.puremagic.com/issues/show_bug.cgi?id=4070 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