Re: const int vs. int const
Jonathan M Davis: Well, it _does_ follow the language spec, so it's not broken in that sense, but it's a broken design IMHO in that it causes confusion and bugs, and it has resulted in complaints in the past and will continue to do so until it's changed. So, I do think that it's true that there will ultimately be fewer complaints if we make the change than there will be if we don't. +1 It's a worthwhile overdue little breaking change. Bye, bearophile
Re: const int vs. int const
On Saturday, 16 August 2014 at 21:42:59 UTC, Jonathan M Davis wrote: On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, but it's either that or have people running into this problem and complaining about it and the bugs that it causes for years to come. And it's _already_ bad practice to put const, immutable, inout, or shared on the left-hand side without parens, and pretty much everyone has run into the problem at one time or another when trying to return const from a function and would know to avoid putting those atributes on the left. So, the vast majority of code wouldn't be affected. And of course, we'd do it via deprecation, so it wouldn't immediately break code. For what it is worth, I can confirm this bit me and a coworker of mine. Deprecation of this makes sense. IIRC there's a bunch of C valid code that are rejected by dmd because the semantic is different. This seems to be one of those cases.
Re: const int vs. int const
On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. -- /Jacob Carlborg
Re: const int vs. int const
On 8/16/2014 11:50 AM, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, and for this case it is not worth it.
Re: const int vs. int const
On Saturday, 16 August 2014 at 19:23:48 UTC, Walter Bright wrote: Yes, and for this case it is not worth it. This shows one more time that D needs a tool (similar to gofix) that allows automatic conversion of source code compatible with version x to code compatible with version x + 1.
Re: const int vs. int const
On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, but it's either that or have people running into this problem and complaining about it and the bugs that it causes for years to come. And it's _already_ bad practice to put const, immutable, inout, or shared on the left-hand side without parens, and pretty much everyone has run into the problem at one time or another when trying to return const from a function and would know to avoid putting those atributes on the left. So, the vast majority of code wouldn't be affected. And of course, we'd do it via deprecation, so it wouldn't immediately break code. So, yes, I can see why it's a breaking change would be given as a reason not to do it, but given that this is a definite wart in the language that is consistently giving problems to D newbies and just outright avoided by D veterans, most code that would be affected is probably wrong anyway, and it's not a feature that's at all desirable to have, so I _definitely_ think that the change is worth it. Certainly, I would want to know every line of code that I have that has any of these attributes no the left-hand side of a function without parens, because that would mean that there's a bug in my code that I didn't catch. - Jonathan M Davis
Re: const int vs. int const
On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. ... and not breaking it will include the same complaints years from now for not fixing it. Mike
Re: const int vs. int const
On Saturday, 16 August 2014 at 19:23:48 UTC, Walter Bright wrote: On 8/16/2014 11:50 AM, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, and for this case it is not worth it. It is worth it. There are going to be consequences either way. However, if it is addressed, the consequences on one side will be temporary. Not addressing it will ensure the consequences on the other side remain indefinitely. Following a well-managed, gradual, deprecation procedure will make the change tolerable. Mike
Re: const int vs. int const
On Sat, 16 Aug 2014 12:23:49 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: Yes, and for this case it is not worth it. it worth it. we can fix alot of such things while our userbase is relatively small. we will be doomed to live with this legacy when userbase becomes huge. heh, i know the language which suffers from the legacy: C++. if i want C++, i know where to download the compiler. ;-) signature.asc Description: PGP signature
Re: const int vs. int const
On Saturday, 16 August 2014 at 19:43:36 UTC, Fool wrote: On Saturday, 16 August 2014 at 19:23:48 UTC, Walter Bright wrote: Yes, and for this case it is not worth it. This shows one more time that D needs a tool (similar to gofix) that allows automatic conversion of source code compatible with version x to code compatible with version x + 1. I agree, but it's going to take you, I, or another motivated individual to build it. It's existence might help influence the attitude towards breaking changes. I'm considering working on it, embarking on yet another tangent of my tangent. A good start would be to create a utility in the https://github.com/D-Programming-Language/tools, and add the ability to change `alias existingSymbol newSymbol` to 'alias newSymbol = existingSymbol`. With this in place, it could set a precedent for adding more language upgrades. Brian, if you have this code (or a start) in your short-term memory, please share. The D gatekeepers could help by putting some (non)verbal support behind such a tool. Mike
Re: const int vs. int const
On Saturday, 16 August 2014 at 23:39:59 UTC, Mike wrote: On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. ... and not breaking it will include the same complaints years from now for not fixing it. Mike Clarification: I realize nothing is broken, so no fixing is needed. But it seems like a nice improvement. Mike
Re: const int vs. int const
On Sunday, 17 August 2014 at 02:44:26 UTC, Mike wrote: On Saturday, 16 August 2014 at 23:39:59 UTC, Mike wrote: On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. ... and not breaking it will include the same complaints years from now for not fixing it. Mike Clarification: I realize nothing is broken, so no fixing is needed. But it seems like a nice improvement. Well, it _does_ follow the language spec, so it's not broken in that sense, but it's a broken design IMHO in that it causes confusion and bugs, and it has resulted in complaints in the past and will continue to do so until it's changed. So, I do think that it's true that there will ultimately be fewer complaints if we make the change than there will be if we don't. - Jonathan M Davis
const int vs. int const
This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works
Re: const int vs. int const
On Friday, 15 August 2014 at 17:05:55 UTC, John wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works It is intentional, and I think this best practice idea doesn't apply to D in the same was as C/C++. The reason this is an issue in C/C++ is because const char * is equivalent to char const *, but once typedefs and templates enter the picture things start to get confusing. Since D allows the const qualifier to use parens to specify what part of the type it applies to, we don't need to support the C style syntax.
Re: const int vs. int const
On Friday, 15 August 2014 at 17:16:45 UTC, Sean Kelly wrote: On Friday, 15 August 2014 at 17:05:55 UTC, John wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works It is intentional, and I think this best practice idea doesn't apply to D in the same was as C/C++. The reason this is an issue in C/C++ is because const char * is equivalent to char const *, but once typedefs and templates enter the picture things start to get confusing. Since D allows the const qualifier to use parens to specify what part of the type it applies to, we don't need to support the C style syntax. Ok, thanks for reply.
Re: const int vs. int const
On Friday, 15 August 2014 at 17:05:55 UTC, John wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works btw, it works either way if I use auto auto const minWage = 11; //works const auto minWage = 11; //works The same flexibility is missing when the actual type is used.
Re: const int vs. int const
On Fri, Aug 15, 2014 at 05:05:53PM +, John via Digitalmars-d wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works Nah, the better practice is to write const(int) instead of const int, which is ambiguous when used to specify a function's return value. For example, const int func(); is *not* the same as: const(int) func(); which can be quite a nasty surprise for the unwary. My personal practice is to always write const(int) everywhere, thus eliminating the ambiguity. T -- No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. -- Simon St. Laurent on xml-dev
Re: const int vs. int const
On 08/15/2014 07:18 PM, John wrote: btw, it works either way if I use auto auto const minWage = 11; //works const auto minWage = 11; //works ... auto does not serve any purpose here. The same flexibility is missing when the actual type is used. In particular, auto is not a wild-card type in that example. const minWage = 11;
Re: const int vs. int const
On 8/15/2014 10:45 AM, H. S. Teoh via Digitalmars-d wrote: Nah, the better practice is to write const(int) instead of const int, which is ambiguous when used to specify a function's return value. For example, const int func(); is *not* the same as: const(int) func(); which can be quite a nasty surprise for the unwary. My personal practice is to always write const(int) everywhere, thus eliminating the ambiguity. const without parentheses is a 'storage class'. const with parentheses is a 'type constructor'. Storage classes apply to the symbol being declared, and hence the type of the symbol. Type constructors apply to the type in the ( ). It is not ambiguous from a semantic or syntactic point of view, but it appears to be ambiguous for those coming from C++. This was discussed at length a few years ago, but no solution emerged that didn't make things much worse.
Re: const int vs. int const
On Friday, 15 August 2014 at 18:47:49 UTC, Walter Bright wrote: On 8/15/2014 10:45 AM, H. S. Teoh via Digitalmars-d wrote: It is not ambiguous from a semantic or syntactic point of view, but it appears to be ambiguous for those coming from C++. This I like this example from the C world: http://stackoverflow.com/a/5503661/1284631 But, I agree, I am a follower of the rule: const is written after and applies to everything that comes left of it.
Re: const int vs. int const
On 8/15/2014 12:06 PM, eles wrote: But, I agree, I am a follower of the rule: const is written after and applies to everything that comes left of it. That rule can never work for D. Remember, D's const is transitive.
Re: const int vs. int const
On Friday, 15 August 2014 at 19:14:10 UTC, Walter Bright wrote: On 8/15/2014 12:06 PM, eles wrote: That rule can never work for D. Remember, D's const is transitive. Thank you. I was aware. I was speaking about my C-style.
Re: const int vs. int const
On Friday, 15 August 2014 at 18:47:49 UTC, Walter Bright wrote: It is not ambiguous from a semantic or syntactic point of view, but it appears to be ambiguous for those coming from C++. This was discussed at length a few years ago, but no solution emerged that didn't make things much worse. I still think that we'd be far better off if all attributes which could apply to a function's return type were illegal on the left-hand side of the function. All allowing it on the left does is cause confusion and bugs. It's already best practice to put it those attributes on the right, because if you don't, everyone who reads the code ends up asking whether the attribute was supposed to apply to the return type, and the parens were forgotten, or whether it was supposed to apply to the function. It was my understanding that the whole reason that attributes like const or immutable are allowed on the left-hand side is because all of the attributes are allowed on both sides, and it would be inconsistent to not allow const on the left. But as it turns out, several aren't allowed on the right - https://issues.dlang.org/show_bug.cgi?id=12930 - making what we have already inconsistent - and since it's bad practice to put it on the left anyway, I think that it's well worth it to have the inconsistency of not allowing const, immutable, inout, or shared on the left-hand side. It would cost us pretty much nothing and will just avoid confusion and bugs. And IMHO, the fact that we're _already_ inconsistent with where the attributes can go makes it so that the argument that const should be allowed on the left for constistency's sake isn't particularly valid. https://issues.dlang.org/show_bug.cgi?id=12931 - Jonathan M Davis
Re: const int vs. int const
On Friday, 15 August 2014 at 18:23:47 UTC, Timon Gehr wrote: On 08/15/2014 07:18 PM, John wrote: btw, it works either way if I use auto auto const minWage = 11; //works const auto minWage = 11; //works ... auto does not serve any purpose here. The same flexibility is missing when the actual type is used. In particular, auto is not a wild-card type in that example. const minWage = 11; Yeah, aside from auto ref, auto is pretty much just a placeholder when you don't want to put the type. Arguably, it shouldn't be allowed when attributes like const or static are used, but it is unfortunately allowed and essentially ignored in those cases. Much as it first seems like auto tells the compiler to infer the type, the reality of the matter is that the compiler will infer the type unless you tell it the type and that auto is just for the cases where you don't want to use attributes and you need to indicate that you're declaring a variable rather than doing an assignment. - Jonathan M Davis
Re: const int vs. int const
On Fri, 15 Aug 2014 21:08:08 + Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: I still think that we'd be far better off if all attributes which could apply to a function's return type were illegal on the left-hand side of the function. i completely agree. even if this change will break some code, i'm still sure that it should be done. i'm constantly beaten by writing 'const FooBar func()' (ah, pun unintended ;-) and i can't understant why compiler is silent about it, while it can tell me that '1 0 must be parenthesized when next to operator ' in 'if (a1 0)'. please, make compiler emit at least warning about 'stray const/immutable/etc'! and then deprecate it, and then make compiler emit error. signature.asc Description: PGP signature
Re: const int vs. int const
On Fri, Aug 15, 2014 at 09:08:08PM +, Jonathan M Davis via Digitalmars-d wrote: On Friday, 15 August 2014 at 18:47:49 UTC, Walter Bright wrote: It is not ambiguous from a semantic or syntactic point of view, but it appears to be ambiguous for those coming from C++. This was discussed at length a few years ago, but no solution emerged that didn't make things much worse. I still think that we'd be far better off if all attributes which could apply to a function's return type were illegal on the left-hand side of the function. All allowing it on the left does is cause confusion and bugs. It's already best practice to put it those attributes on the right, because if you don't, everyone who reads the code ends up asking whether the attribute was supposed to apply to the return type, and the parens were forgotten, or whether it was supposed to apply to the function. +1. T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Re: const int vs. int const
On Friday, 15 August 2014 at 21:08:10 UTC, Jonathan M Davis wrote: I still think that we'd be far better off if all attributes which could apply to a function's return type were illegal on the left-hand side of the function. All allowing it on the left does is cause confusion and bugs. It's already best practice to put it those attributes on the right, because if you don't, everyone who reads the code ends up asking whether the attribute was supposed to apply to the return type, and the parens were forgotten, or whether it was supposed to apply to the function. Sounds like a worthwhile impromement to me. Mike
