digitalmars.D.bugs - [Issue 10150] New: Prefix method 'this' qualifiers should be just ignored anytime
- d-bugmail puremagic.com (53/53) May 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (10/10) May 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (13/13) May 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (10/10) May 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (10/10) May 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (31/31) Jun 27 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (18/18) Jun 27 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (14/14) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (7/7) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (9/12) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (33/36) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (11/11) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (23/31) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (6/35) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (15/20) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (17/37) Jul 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (25/52) Jul 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
- d-bugmail puremagic.com (14/17) Jul 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10150
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Summary: Prefix method 'this' qualifiers should be just ignored anytime Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: k.hara.pg gmail.com By fixing issue 9199, git head rejects all meaningless method qualifiers for non-method functions. class C1 { const static void fc() {} // NG in both 2.062 and git head immutable static void fi() {} // NG in both 2.062 and git head shared static void fs() {} // OK in 2.063 but NG in git head inout static void fw() {} // OK in 2.063 but NG in git head } class C2 { static void fc() const {} // NG in both 2.062 and git head static void fi() immutable {} // NG in both 2.062 and git head static void fs() shared {} // OK in 2.063 but NG in git head static void fw() inout {} // OK in 2.063 but NG in git head } const void fc1() {} // NG in both 2.062 and git head immutable void fi1() {} // NG in both 2.062 and git head shared void fs1() {} // OK in 2.063 but NG in git head inout void fw1() {} // OK in 2.063 but NG in git head void fc2() const {} // NG in both 2.062 and git head void fi2() immutable {} // NG in both 2.062 and git head void fs2() shared {} // OK in 2.063 but NG in git head void fw2() inout {} // OK in 2.063 but NG in git head --- But this behavior is restrictive and now breaking exist code. Dlanguage allows to rewrite prefix storage class to label syntax and scope syntax. const void foo() {} // previous const: void foo() {} // label const { void foo() {} } // scope Making errors for the functions enclosed by attribute would be inconvenient. So, I'd like to propose that: 1. Module level functions and class/struct scope static functions just ignore prefix method 'this' qualifiers (const, immutable, shared, and inout). 2. But specifying them at postfix position should be rejected. The rule is consistent and make writing code more handy. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull https://github.com/D-Programming-Language/dmd/pull/2071 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/958abf2c48333cc0f800dff51da435338458b751 fix Issue 10150 - Prefix method 'this' qualifiers should be just ignored anytime https://github.com/D-Programming-Language/dmd/commit/091cb6eea52eec998f60d8e6be6b54413d173b3b [enh][REG2.063a] Issue 10150 - Prefix method 'this' qualifiers should be just ignored anytime -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Commit pushed to 2.063 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/7c3ed3e585e829c7bf97ca8f78b6c7d76c98b0ba [enh][REG2.063a] Issue 10150 - Prefix method 'this' qualifiers should be just ignored anytime -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 11:26:24 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 27 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 11:28:34 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 27 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Dicebot <m.strashun gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.strashun gmail.com I think "const T foo" should be parsed as "const(T) foo" where T is not void and be an error otherwise. (I was almost certain that former was how it has behaved before!) This is a very natural style to type in, especially for those that come from C/C++. Silent no-op is probably most dangerous decision possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 I actually see no rationale behind this change because enhancement descriptions mentions only function returning "void". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 10:43:09 PDT ---This is a very natural style to type in, especially for those that come from C/C++.Well not entirely, since 'const void *' in D and C++ mean different things, const(void*) vs const(void)*.Silent no-op is probably most dangerous decision possible.Yep, at least for non-grouped declarations like I've mentioned. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra gmail.comI think "const T foo" should be parsed as "const(T) foo" where T is not void and be an error otherwise. (I was almost certain that former was how it has behaved before!)I think that would be a horrible decision, because "const T foo" *means* something for member functions. Your proposed change would have a different parse meaning depending on if the function is member or not: const T foo(); (1) struct S { const T foo(); (2) } Method (1) would return a const(T). But method (2) would return a T. As much of a surprise as it is for C++ new comers, D's "const" syntax is simply different (and better). The word "const" all by itself is a function attribute, and that is all it should ever be. The compiler should *help* catch such erroneous usage, not silently ignore it. Also, having a different behavior depending on prefix/postfix makes no sense to me. Both are *equally* wrong, and arguably, "prefix qualifiers" have *higher* chances of being actual mistakes. The evidence of this has already been demonstrated in this thread, and is brought up *regularly* in learn (and even then, only when it actually creates problems). So we brake some code? Yes. Code that was most probably silently wrong to begin with. This is a "good move". The error is verbose and explicit, and the fix is trivial. Let's keep making D safe by default please (!) Let's do everyone a favor and put a definitive *end* to this mess. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150 I want both to go to return type. Prefix qualifier -> return type. Postfix qualifier -> function type. If qualifier is not applicable to return type, it falls through to function type (as far as I understand the grammar anyway). Simple and obvious. The very idea that prefix qualifier has something to do with function type is confusing and error-prone. And this change makes it much worse. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150I want both to go to return type. Prefix qualifier -> return type. Postfix qualifier -> function type.Typ? "Both", then you state two different things.If qualifier is not applicable to return type, it falls through to function type (as far as I understand the grammar anyway).AFAIK, anything returnable can be qualified with const, so there would be no fall through case.Simple and obvious. The very idea that prefix qualifier has something to do with function type is confusing and error-prone. And this change makes it much worse.What about: -------- struct S { const nothrow pure T foo(); nothrow pure const T bar(); } -------- What does (should) foo return? What about bar? The current rules are obvious: stand alone attribute => Function. Simple and obvious. There is no reasons for "const" to get special treatment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150I 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.-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150Sorry for the empty post, my finger slipped on "commit". I just wanted to add that when C code is copy pasted and *compiles* in D, then the rules say it *must* create the same results during runtime: This is not a problem here, because it *should* still produce the same actual results. However, it is largely *expected* that the C code will have the same meaning and/or semantic, in the one in D. Given that this is not the case, then things should be changed to either mean the same thing (IMO bad idea), or emit a compile time error. The middle ground is an extremely dangerous place to stand. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I disagree with this change, this is extremely dangerous behavior when interfacing with C. Take a look at the following: [...]
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150Typ? "Both", then you state two different things.Both free function and method.AFAIK, anything returnable can be qualified with const, so there would be no fall through case.I don't know if const(void) is valid, but at least pure is applicable to return type only when it is one of function types so it will fall through. I am not speaking only about const, all attributes should behave consistently.What about: -------- struct S { const nothrow pure T foo(); nothrow pure const T bar(); } -------- What does (should) foo return? What about bar?both return const(T) (at the very least, I have no idea what T is). When I am speaking about postfix qualifier I mean "T bar() const pure nothrow"The current rules are obvious: stand alone attribute => Function. Simple and obvious. There is no reasons for "const" to get special treatment.No, they are more like "stand alone attribute -> function or no-op, you'd better be careful!". And breaks similarity with C/C++ principle. And makes your code needlessly "Lisp-y". Behaviour has been very confusing all the time but at least it slapped me into face every time I tried to type stuff in a more natural syntax. Not any more. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150Well, such a change would break existing code that is correct and respects the spec. I'm not sure changing the semantics of such code would be acceptable. D allows attributes to be placed either prefix or postfix. Forcing "const" to only work right hand side is a C++ holdover. There should be no difference where you place it. If anything, I find it weird when I find code that is written like: "pure property T foo() const" Why place the const there? Put it on the left, that's where you placed everything else...What about: -------- struct S { const nothrow pure T foo(); nothrow pure const T bar(); } -------- What does (should) foo return? What about bar?both return const(T) (at the very least, I have no idea what T is). When I am speaking about postfix qualifier I mean "T bar() const pure nothrow"I agree both are problem. I happen to think the better solution is that no-op becomes explicit compile error. This is both safe, and doesn't add special positional casing.The current rules are obvious: stand alone attribute => Function. Simple and obvious. There is no reasons for "const" to get special treatment.No, they are more like "stand alone attribute -> function or no-op, you'd better be careful!". And breaks similarity with C/C++ principle.And makes your code needlessly "Lisp-y".Don't know lisp.Behaviour has been very confusing all the time but at least it slapped me into face every time I tried to type stuff in a more natural syntax. Not any more.I agree we should be slapped in the face every time we type something wrong. Currently, being slapped in the face for wrong postfix is good. Also being slapped for wrong prefix would be better. The solution of saying "prefix applies to return value", would be a big interface change. Even where we to agree it is the right decision, I don't think it could acceptable change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10150The solution of saying "prefix applies to return value", would be a big interface change. Even where we to agree it is the right decision, I don't think it could acceptable change.You have asked what it my opinion about "how it should behave", not about "what can be released" ;) I don't expect this to change, it is a design mistake with roots too ancient to shake it. But I at least want it to remind me every time about it, not fail silently. This pull request was a disaster. Actually, paying even more attention to initial enhancement description I see no valid use case. "const: void foo() {}" - this should be an error, nothing convenient about letting it go. P.S. By "Lisp-y" I have meant excessive () bracket usage. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 01 2013