www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make const, immutable, inout, and shared illegal as function attributes

reply Martin Nowak <code dawg.eu> writes:
Kenji just proposed a slightly controversial pull request so I want to 
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a 
function.

So instead of
     const int foo();
you'd should write
     int foo() const;

Then at some future point we could apply the left hand side qualifiers 
to the return type, e.g. `const int foo();` == `const(int) foo();`

Would this affect your code?
Do you think it makes your code better or worse?
Is this just a pointless style change?
Anything else?

https://github.com/D-Programming-Language/dmd/pull/4043
Oct 09 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;

 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`

 Would this affect your code?
No. D-Scanner's style checker yells at you when you try to do this, so I've fixed all my personal code already. These checks run as part of the CI process at EMSI and the results are uploaded to our local SonarQube server. We shouldn't have any uses of the to-be-removed syntax hiding in our code.
 Do you think it makes your code better or worse?
Better. Explaining why "const int foo" is "const(int)" and "const int foo();" is "int" is not something I enjoy doing.
 Is this just a pointless style change?
No.
 Anything else?
This will be moderately difficult to imlement in dfix.
Oct 09 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Kenji just proposed a slightly controversial pull request so I want
 to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a=20
 function.
=20
 So instead of
      const int foo();
 you'd should write
      int foo() const;
=20
 Then at some future point we could apply the left hand side
 qualifiers to the return type, e.g. `const int foo();` =3D=3D `const(int)
 foo();`
=20
 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?
=20
 https://github.com/D-Programming-Language/dmd/pull/4043
i'm all for this. prefix function attributes are *VERY* confusing. i think this patch should be accepted as soon as possible. i'm already enjoying it. ;-)
Oct 09 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 9 Oct 2014 12:04:36 +0300
ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

i mean there were occasional discussions in NG about irritating
"'const int bar();' is not 'const(int) bar();'" and i've seen nobody
defending prefix attributes. it was either "i don't care" or "it's
annoying".
Oct 09 2014
prev sibling next sibling parent reply "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.
I'm all for it
 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`
I know it's not happening anytime soon, but I'm against this second idea. This will be an extra annoyance when "porting" old D code to a new version. Just removing the currently ambiguous attribute on the left should be plenty. No need to try to mimic C in this regard.
Oct 09 2014
parent Lionello Lunesu <lionello lunesu.remove.com> writes:
On 09/10/14 17:32, francesco cattoglio wrote:
 On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I want to
 reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a
 function.
I'm all for it
 Then at some future point we could apply the left hand side qualifiers
 to the return type, e.g. `const int foo();` == `const(int) foo();`
I know it's not happening anytime soon, but I'm against this second idea. This will be an extra annoyance when "porting" old D code to a new version. Just removing the currently ambiguous attribute on the left should be plenty. No need to try to mimic C in this regard.
+1
Oct 13 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;

 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`

 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
Yes, yes, yes YES ! YYYEEEEEESSSSSS !
Oct 09 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;

 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`

 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
I'm for going ahead with that. --- /Paolo
Oct 09 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:

 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;
+1 from me.
 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`
In this case I think it's better to focus on the most important thing first. Bye, bearophile
Oct 09 2014
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak <code dawg.eu>:


 Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand side, but switched to right hand side some time ago.
 Do you think it makes your code better or worse?
Probably better, although I tried to be careful with the left hand side attributes so it shouldn't change to much.
 Is this just a pointless style change?
 Anything else?
Code will probably look nicer, but I'm not sure if it's consistent. with const(int) it's obvious that the return value is const. With const int abcd() safe this might be less obvious. Also fixing old code manually would be very tedious.
Oct 09 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 9 Oct 2014 12:27:11 +0200
schrieb Johannes Pfau <nospam example.com>:

 Am Thu, 09 Oct 2014 10:50:44 +0200
 schrieb Martin Nowak <code dawg.eu>:
 
 
 Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand side, but switched to right hand side some time ago.
 Do you think it makes your code better or worse?
Probably better, although I tried to be careful with the left hand side attributes so it shouldn't change to much.
 Is this just a pointless style change?
 Anything else?
Code will probably look nicer, but I'm not sure if it's consistent. with const(int) it's obvious that the return value is const. With const int abcd() safe this might be less obvious. Also fixing old code manually would be very tedious.
Forgot to some overall I'm for this change. I'd just like some automated way to fix old code ;-)
Oct 09 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:
 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to start getting rid of old syntax. Not long after that Walter made this https://github.com/D-Programming-Language/dmd/pull/4021 dfix is under development. You can find it here: https://github.com/Hackerpilot/dfix
Oct 09 2014
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/09/2014 01:10 PM, Brian Schott wrote:
 dfix is under development. You can find it here:
 https://github.com/Hackerpilot/dfix
That would make such decisions much easier :). It doesn't appear to rewrite AST but only tokens at the moment. How reliable is it?
Oct 09 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 11:31:01 UTC, Martin Nowak wrote:
 It doesn't appear to rewrite AST but only tokens at the moment.
The features that are implemented so far don't need the AST. Others such as the function attributes and C-style arrays will need help from the parser.
 How reliable is it?
About four and a half. Maybe five.
Oct 09 2014
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 9 October 2014 at 11:10:47 UTC, Brian Schott wrote:
 On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau 
 wrote:
 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to start getting rid of old syntax. Not long after that Walter made this https://github.com/D-Programming-Language/dmd/pull/4021 dfix is under development. You can find it here: https://github.com/Hackerpilot/dfix
This is great news. Even if it's not going to be packaged with the official compiler releases, perhaps you can start off by making it available on dub for any breaking syntax changes in dmd, such as ditching the old C-style array declaration syntax, so we can point users who hit it at dfix. As for moving function attributes from the left to the right, I'm all for it. I was frequently confused by what applied to what and picking through and figuring it out was unnecessary mental overhead.
Oct 09 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/9/2014 4:10 AM, Brian Schott wrote:
 On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:
 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to start getting rid of old syntax. Not long after that Walter made this https://github.com/D-Programming-Language/dmd/pull/4021 dfix is under development. You can find it here: https://github.com/Hackerpilot/dfix
dfix will be a welcome addition. Glad you're working on it!
Oct 09 2014
prev sibling next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> napsáno:

 Kenji just proposed a slightly controversial pull request so I want
 to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a 
 function.
 
 So instead of
      const int foo();
 you'd should write
      int foo() const;
 
 Then at some future point we could apply the left hand side
 qualifiers to the return type, e.g. `const int foo();` == `const(int)
 foo();`
 
 Would this affect your code?
Yes (but I am ok with that)
 Do you think it makes your code better or worse?
Definitely better
 Is this just a pointless style change?
No
 Anything else?
Merge this ASAP, please :)
Oct 09 2014
prev sibling next sibling parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:>
 Would this affect your code?
no
 Do you think it makes your code better or worse?
no change, my code already looks like that
 Is this just a pointless style change?
no, left hand side function qualifier is just wrong IMO.
 Anything else?
Thank you guys
Oct 09 2014
parent "Sag Academy" <sagacademyjaipur gmail.com> writes:
On Thursday, 9 October 2014 at 11:24:08 UTC, Robert burner
Schadek wrote:
 On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak 
 wrote:>
 Would this affect your code?
no
 Do you think it makes your code better or worse?
no change, my code already looks like that
 Is this just a pointless style change?
no, left hand side function qualifier is just wrong IMO.
 Anything else?
Thank you guys
mostly welcome
Oct 09 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Would this affect your code?
I've written code before in the style: property pure nothrow const //<- HERE int foo(); So anybody else using this style might be affected. But even then, I agree. D has always been about "if it's ambiguous, dangerous, and can be avoided, don't make it fucking legal".
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?
I'm not really sure about the: "Then at some future point we could apply the left hand side qualifiers to the return type, e.g. `const int foo();` == `const(int) foo();`" I don't think it buys us anything, except maybe silently changing semantics of code that hibernated through the deprecation process. I mean, sure, it might be a little surprising, but it's not the end of the world.
Oct 09 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 09/10/14 13:38, monarch_dodra via Digitalmars-d wrote:
 I'm not really sure about the: "Then at some future point we could apply the
 left hand side qualifiers to the return type, e.g. `const int foo();` ==
 `const(int) foo();`"

 I don't think it buys us anything, except maybe silently changing semantics of
 code that hibernated through the deprecation process.
Besides, const int foo() const { ... } is fairly ambiguous syntax to my eyes. const(int) foo() const { ... } is less so.
Oct 09 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 October 2014 at 22:29:32 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
 On 09/10/14 13:38, monarch_dodra via Digitalmars-d wrote:
 I'm not really sure about the: "Then at some future point we 
 could apply the
 left hand side qualifiers to the return type, e.g. `const int 
 foo();` ==
 `const(int) foo();`"

 I don't think it buys us anything, except maybe silently 
 changing semantics of
 code that hibernated through the deprecation process.
Besides, const int foo() const { ... } is fairly ambiguous syntax to my eyes. const(int) foo() const { ... } is less so.
Also const int delegate() const dg; Is dg const or the return type ?
Oct 09 2014
prev sibling next sibling parent "Dominikus Dittes Scherkl" writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Would this affect your code?
No, I always wrote it on the right.
 Do you think it makes your code better or worse?
Better.
 Is this just a pointless style change?
No, removing confusing style is good.
Oct 09 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
This pull request is a good thing (TM). +1 all the way.

Atila

On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;

 Then at some future point we could apply the left hand side 
 qualifiers to the return type, e.g. `const int foo();` == 
 `const(int) foo();`

 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
Oct 09 2014
prev sibling next sibling parent =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d writes:
Dne 9.10.2014 v 10:50 Martin Nowak via Digitalmars-d napsal(a):
 Would this affect your code?
yes, but I understand the rationale so I don't mind
 Do you think it makes your code better or worse?
less ambiguous, so I would say better
 Is this just a pointless style change?
no -- Martin
Oct 09 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.

 So instead of
     const int foo();
 you'd should write
     int foo() const;
Finally.
 Would this affect your code?
Yes, eventually, but I am willing to make the change and it is trivial compared to some other D2 migration related things :)
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
I believe it is much less error-prone, prefix notation is currently a common cause of mis-interpretation from the reader.
Oct 09 2014
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/14 4:50 AM, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I want to
 reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a
 function.

 So instead of
      const int foo();
 you'd should write
      int foo() const;

 Then at some future point we could apply the left hand side qualifiers
 to the return type, e.g. `const int foo();` == `const(int) foo();`

 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
First, I'm all for the change. If it affects my code, I don't care, I'll fix it. Just one point to make, this will still work, right?: const { int foo(); } const: int foo(); I'm not sure I agree with the future plan to allow const on the lhs to apply to the return type, but we can decide that in the future. -Steve
Oct 09 2014
parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2014-10-09 23:17 GMT+09:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d puremagic.com>:

 Just one point to make, this will still work, right?:

 const {
    int foo();
 }

 const:
    int foo();
My PR still allows those block or label style attributes. Kenji Hara
Oct 09 2014
prev sibling next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
It's a clean break and easy to fix, and eliminated a confusing 
ambiguity. I'm all for it.
Oct 09 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.
+1. Prefixed const is so often a mistaken attempt to return a const that when I see someone post for help in IRC about "cannot implicitly convert expression" I immediately look for a "this" in the error message because that usually means they are using prefixed const function attribute when they intended to return a const variable. This reminds me quite a bit about Walter's explanation on FLOSS Weekly about why D disallows shadowing local variables. It can be used correctly just fine but it's so often used incorrectly that we're better off disallowing it completely.
Oct 09 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, October 09, 2014 10:50:44 Martin Nowak via Digitalmars-d wrote:
 Kenji just proposed a slightly controversial pull request so I want to
 reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a
 function.

 So instead of
      const int foo();
 you'd should write
      int foo() const;

 Then at some future point we could apply the left hand side qualifiers
 to the return type, e.g. `const int foo();` == `const(int) foo();`

 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
Well, since I'm the one who created the enhancement request that this is for, I'm obviously for it. It's a change that's long past due. Allowing them on the left only causes trouble - both in terms of bugs and confusion - and I think that most of us would agree that it's already considered good practice to stick them on the right rather than the left. Allowing them on the left has no real benefit IMHO beyond avoiding code breakage, and the fix for that is trivial. - Jonathan M Davis
Oct 09 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.
Great. I support this.
Oct 09 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
 Would this affect your code?
No, but is it fixed on the ddoc side? The last ddoc I generated had function attributes first, even though in the code they were on the right. It would be pretty awful to have function attributes obliged to be on the right in code, but still appearing on the left in documentation.
 Do you think it makes your code better or worse?
I like the style, and it certainly helps to avoid the confusion with C/C++'s const interpretation.
 Then at some future point we could apply the left hand side qualifiers to the
 return type, e.g. `const int foo();` == `const(int) foo();`
I like this idea less. const(int) is explicit in a way that const int isn't.
 Anything else?
I'm not sure whether I care to _enforce_ this style rather than strongly encourage it, as it's a breaking change. I'd rather deprecation of left-hand-side attributes, rather than illegality, if that is possible.
Oct 09 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/9/2014 1:50 AM, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I want to reach
out
 for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a function.
This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; For functions, const-as-storage-class applies to the function symbol. And if it is misused, the compiler will very likely complain about a mismatched type. Breaking this adds a special case inconsistency, besides breaking existing code. (I understand that there's a lot of advocacy lately about "break my code", but I'm the one who bears the brunt of "you guys broke my code again, even though the code was correct and worked perfectly well! D sux.", besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.) This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) If we're going to break things, it needs to be for something that matters. This doesn't make the cut.
Oct 09 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 For functions, const-as-storage-class applies to the function 
 symbol. And if it is misused, the compiler will very likely 
 complain about a mismatched type.
 Breaking this adds a special case inconsistency, besides 
 breaking existing code.
Come on that is the same bogus reason every time. const here do not apply to the function but to its hidden, implicit parameter. And that is actually a problem. const void delegate() dg; // dg should be const, and there is no way to qualify the implicit parameter. You obviously can't pretend you don't know this as: const int foo() {} Gives you an error because you have no this pointer to make const. So let's not pretend that this const actually qualify the function when everybody knows it doesn't.
Oct 09 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 09 Oct 2014 19:37:31 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 If we're going to break things, it needs to be for something that
 matters. This doesn't make the cut.
ah, again... people: yes, yes, we WANT it, let's break our code and do it! Walter: ha, shut up! this doesn't matter at all, we will not break the code for this! people: aaaargh! (--motivation, ++frustration) i myself don't like this game enough to participate. there is no sense in both implementing something and discussing something. small fixes will be rejected due to being small, big fixes will be rejected due to being big. and medium fixes will be rejected due to being too big for small and too small for big. this game has no way to win. so at least nobody will read any more rants from me about inconsistencies in D. still a win.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
Digitalmars-d wrote:
 On Thu, 09 Oct 2014 19:37:31 -0700
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 If we're going to break things, it needs to be for something 
 that
 matters. This doesn't make the cut.
ah, again... people: yes, yes, we WANT it, let's break our code and do it! Walter: ha, shut up! this doesn't matter at all, we will not break the code for this! people: aaaargh! (--motivation, ++frustration) i myself don't like this game enough to participate. there is no sense in both implementing something and discussing something. small fixes will be rejected due to being small, big fixes will be rejected due to being big. and medium fixes will be rejected due to being too big for small and too small for big. this game has no way to win. so at least nobody will read any more rants from me about inconsistencies in D. still a win.
yoooohoooo! wait.... why are you still posting? gtfo
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:10:06 UTC, market wrote:
 On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
 Digitalmars-d wrote:
 On Thu, 09 Oct 2014 19:37:31 -0700
 wait.... why are you still posting? gtfo
That kind of attitude does not help much.
Oct 10 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 15:10:05 +0000
market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 wait.... why are you still posting?
can't see any technical discussion here. and can't see me ranting about inconsistencies in D. and can't see where i wrote that i will not rant about attitude.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 16:44:23 UTC, ketmar via
Digitalmars-d wrote:
 On Fri, 10 Oct 2014 15:10:05 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 wait.... why are you still posting?
can't see any technical discussion here. and can't see me ranting about inconsistencies in D. and can't see where i wrote that i will not rant about attitude.
please just go. please
Oct 10 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 18:14:28 +0000
market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 please just go. please
(smiles) you are funny.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Digitalmars-d wrote:
 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 please just go. please
(smiles) you are funny.
you are not. gtfo ketmar
Oct 10 2014
parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:
 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:
 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 please just go. please
(smiles) you are funny.
you are not. gtfo ketmar
Market, I can't tell if you're joking or not. Either way, time for it to stop.
Oct 10 2014
next sibling parent "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 20:26:23 UTC, Brad Roberts via
Digitalmars-d wrote:
 On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:
 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:
 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 please just go. please
(smiles) you are funny.
you are not. gtfo ketmar
Market, I can't tell if you're joking or not. Either way, time for it to stop.
I am not joking! ketmar is becoming the D resident troll. And does nothing for D aside spewing shit. ketmar must gtfo.
Oct 10 2014
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/10/14 4:25 PM, Brad Roberts via Digitalmars-d wrote:
 On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:
 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:
 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 please just go. please
(smiles) you are funny.
you are not. gtfo ketmar
Market, I can't tell if you're joking or not. Either way, time for it to stop.
Don't feed the troll, let market go away on his own. -Steve
Oct 10 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 If we're going to break things, it needs to be for something 
 that matters. This doesn't make the cut.
I think you are wrong. This seems a worthy little breaking change. Bye, bearophile
Oct 10 2014
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/14 10:37 PM, Walter Bright wrote:

 For functions, const-as-storage-class applies to the function symbol.
 And if it is misused, the compiler will very likely complain about a
 mismatched type.
Can you demonstrate this? I hate to see D reject a unanimously wanted improvement on something that is "likely" but not defined.
 Breaking this adds a special case inconsistency, besides breaking
 existing code.
Just like if(x); is rejected inconsistently. The point is, it's WORTH having the inconsistency to avoid the issues that come with it.
 (I understand that there's a lot of advocacy lately about "break my
 code", but I'm the one who bears the brunt of "you guys broke my code
 again, even though the code was correct and worked perfectly well! D
 sux.", besides, of course, those poor souls who have to go fix their
 code base, and I hear again about how D is unstable, another Reddit
 flame-fest about D being unsuitable because the designers can't make up
 their mind, etc.)
You need to grow a thicker skin on Reddit I think.
 This endless search for the ideal syntax is consuming our time while we
 aren't working on issues that matter. (And this change will consume
 users' time, too, not just ours.)
This is not a new problem, not a crazy novel syntax, and the time consumed is already taken (PR already exists). Every time I turn around, someone on D is complaining that "we" shouldn't spend time doing this or that. But "we" are all volunteers, and while it's nice to have direction, if someone wants to work on something, I don't want to say "you can't do that, please work on X instead." It doesn't help, it doesn't motivate. Really, what you are saying here is, the unanimous opinion of the die-hard very dedicated D community is worthless compared to the opinion of a hypothetical Reddit user. -Steve
Oct 10 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 Really, what you are saying here is, the unanimous opinion of the=20
 die-hard very dedicated D community is worthless compared to the
 opinion of a hypothetical Reddit user.
second-class citizens will not run away. existing D users are second-class citizens.
Oct 10 2014
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/10/14 9:53 AM, ketmar via Digitalmars-d wrote:
 On Fri, 10 Oct 2014 09:42:14 -0400
 Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
 wrote:

 Really, what you are saying here is, the unanimous opinion of the
 die-hard very dedicated D community is worthless compared to the
 opinion of a hypothetical Reddit user.
second-class citizens will not run away. existing D users are second-class citizens.
They will and have. -Steve
Oct 10 2014
prev sibling parent "bachmeier" <no spam.com> writes:
On Friday, 10 October 2014 at 13:42:14 UTC, Steven Schveighoffer 
wrote:

 (I understand that there's a lot of advocacy lately about 
 "break my
 code", but I'm the one who bears the brunt of "you guys broke 
 my code
 again, even though the code was correct and worked perfectly 
 well! D
 sux.", besides, of course, those poor souls who have to go fix 
 their
 code base, and I hear again about how D is unstable, another 
 Reddit
 flame-fest about D being unsuitable because the designers 
 can't make up
 their mind, etc.)
You need to grow a thicker skin on Reddit I think.
Or read the many Reddit comments about how C++ syntax and gotchas suck and make everyone want to avoid the language. "There are only two kinds of languages: the ones people complain about and the ones nobody uses" is not a joke. This is no way to design a language. And for all the supposed concern about breaking code, the most recent compiler was released with a bunch of regressions. Those are the code breakages that show up on Reddit, not minor changes that went through a proper deprecation cycle.
Oct 10 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 On 10/9/2014 1:50 AM, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I 
 want to reach out
 for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand 
 side of a function.
This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; For functions, const-as-storage-class applies to the function symbol. And if it is misused, the compiler will very likely complain about a mismatched type. Breaking this adds a special case inconsistency, besides breaking existing code. (I understand that there's a lot of advocacy lately about "break my code", but I'm the one who bears the brunt of "you guys broke my code again, even though the code was correct and worked perfectly well! D sux.", besides, of course, those poor souls who have to go fix their code base, and I hear again about how D is unstable, another Reddit flame-fest about D being unsuitable because the designers can't make up their mind, etc.)
None of those professional complainers matter though. They'll always find *something* to complain about. This is an excellent example of a breaking change that pays for itself within weeks. A large codebase can be converted over very quickly, without any thought required. It has the *immediate* benefit that the coding style improves. It has the longer term benefit of removing a lot of confusion.
 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this change 
 will consume users' time, too, not just ours.)

 If we're going to break things, it needs to be for something 
 that matters. This doesn't make the cut.
No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time. One less thing to worry about, one less thing to explain, one less thing to be confused by. If you have an organisation with 50 people, every one of them benefits slightly. In aggregate, that's a big deal.
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:13:16 UTC, Don wrote:
 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 On 10/9/2014 1:50 AM, Martin Nowak wrote:
 No. It's a removal of one of those little friction points, that 
 hurts everyone very slightly, all the time.
As, IIRC, Teoh put it once: everywhere you turn, you see unfinished things.
Oct 10 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 10, 2014 15:13:15 Don via Digitalmars-d wrote:
 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 (I understand that there's a lot of advocacy lately about
 "break my code", but I'm the one who bears the brunt of "you
 guys broke my code again, even though the code was correct and
 worked perfectly well! D sux.", besides, of course, those poor
 souls who have to go fix their code base, and I hear again
 about how D is unstable, another Reddit flame-fest about D
 being unsuitable because the designers can't make up their
 mind, etc.)
None of those professional complainers matter though. They'll always find *something* to complain about. This is an excellent example of a breaking change that pays for itself within weeks. A large codebase can be converted over very quickly, without any thought required. It has the *immediate* benefit that the coding style improves. It has the longer term benefit of removing a lot of confusion.
Exactly!
 This endless search for the ideal syntax is consuming our time
 while we aren't working on issues that matter. (And this change
 will consume users' time, too, not just ours.)

 If we're going to break things, it needs to be for something
 that matters. This doesn't make the cut.
No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time. One less thing to worry about, one less thing to explain, one less thing to be confused by. If you have an organisation with 50 people, every one of them benefits slightly. In aggregate, that's a big deal.
+1 - Jonathan M Davis
Oct 10 2014
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/10/2014 04:37 AM, Walter Bright wrote:
 On 10/9/2014 1:50 AM, Martin Nowak wrote:
 Kenji just proposed a slightly controversial pull request so I want to
 reach out
 for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a
 function.
This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v
That on it's own is fairly difficult to explain.
 For functions, const-as-storage-class applies to the function symbol.
What's the difference between a const symbol and a normal symbol?
 This endless search for the ideal syntax is consuming our time while we
 aren't working on issues that matter. (And this change will consume
 users' time, too, not just ours.)
Sure, programmers are obsessed with syntax discussion. Think of all the future time that is wasted discussing whether const on a function should be left or right.
 If we're going to break things, it needs to be for something that
 matters. This doesn't make the cut.
There are 3591 open issues in bugzilla and hundreds of ideas floating around. So there will always be a lot of unplanned things happening in parallel. I do agree that we should handle such proposals early on through DIPs rather than stopping finished work in a pull request. We don't want to break code, but discourage the usage of LHS function qualifiers because they are confusing. As this is more about stating a clear preference than deprecating the old syntax let me propose a compromise. - adding RHS rule to D's style guide http://dlang.org/dstyle.html with an explanation what the storage class function thing does - change any dmd formatting code to RHS and change our documentation - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:15:13 UTC, Martin Nowak wrote:
 On 10/10/2014 04:37 AM, Walter Bright wrote:
 On 10/9/2014 1:50 AM, Martin Nowak wrote:
 - leave the rest to linting tools like 
 https://github.com/Hackerpilot/Dscanner
I don't like it. If it is not in the language, then why bother with Dscanner? C++ has a lot of lint tools. How many of them the average Joe use? Either is in the language, either you can never give a * about it. Why to default to a lint tool just as a lame excuse for not getting the language right in the first place? PS I know it's not because of you.
Oct 10 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 8:15 AM, Martin Nowak wrote:
 const is used both as a storage class and as a type constructor, and is
 distinguished by the grammar:

     const(T) v; // type constructor, it affects the type T

     const T v;  // storage class, affects the symbol v and the type of v
That on it's own is fairly difficult to explain.
I can blame C++ for that, because in C++ the difference between const as storage class and as type constructor is much more subtle than in D, but it has critical affects. This problem is why we chose the const(T) syntax for type construction. As for "what is a storage class" is there any confusion about: static T v; ? I don't think so.
 For functions, const-as-storage-class applies to the function symbol.
What's the difference between a const symbol and a normal symbol?
A const field member, for example, didn't contribute to the size of the struct.
 We don't want to break code, but discourage the usage of LHS function
qualifiers
 because they are confusing.
 As this is more about stating a clear preference than deprecating the old
syntax
 let me propose a compromise.

 - adding RHS rule to D's style guide http://dlang.org/dstyle.html
    with an explanation what the storage class function thing does

 - change any dmd formatting code to RHS and change our documentation

 - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner
That's a good idea. I have no objections.
Oct 10 2014
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10 Oct 2014 17:35, "Walter Bright via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 On 10/10/2014 8:15 AM, Martin Nowak wrote:
 const is used both as a storage class and as a type constructor, and is
 distinguished by the grammar:

     const(T) v; // type constructor, it affects the type T

     const T v;  // storage class, affects the symbol v and the type of v
That on it's own is fairly difficult to explain.
I can blame C++ for that, because in C++ the difference between const as
storage class and as type constructor is much more subtle than in D, but it has critical affects.

You shouldn't be blaming C++ for mistakes that D made.

 This problem is why we chose the const(T) syntax for type construction.

 As for "what is a storage class" is there any confusion about:

     static T v;

 ? I don't think so.
Equally, static does not have a double-meaning. Iain.
Oct 10 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:
 You shouldn't be blaming C++ for mistakes that D made.
I meant when perceptions about what something means are carried over from one language to another.
 Equally, static does not have a double-meaning.
static famously in C++ has multiple meanings :-) and does so in D as well. Overloading keywords with more than one meaning is common practice and isn't necessarily bad in a programming language. In D, we overload 'this' with at least 3 distinct meanings.
Oct 10 2014
next sibling parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 10 October 2014 at 20:51:53 UTC, Walter Bright wrote:
 On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:
 You shouldn't be blaming C++ for mistakes that D made.
I meant when perceptions about what something means are carried over from one language to another.
Yeah, but you asked for it by deliberately making D C-like. Being alike, but different is more confusing than just being different, e.g.: "qualifier symbol : type;" would probably have been more intuitive.
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 13:51:54 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Overloading keywords with more than one meaning is common practice
 and isn't necessarily bad in a programming language. In D, we
 overload 'this' with at least 3 distinct meanings.
and 'enum' too.
Oct 10 2014
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10 October 2014 21:51, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:
 You shouldn't be blaming C++ for mistakes that D made.
I meant when perceptions about what something means are carried over from one language to another.
 Equally, static does not have a double-meaning.
static famously in C++ has multiple meanings :-) and does so in D as well.
I meant in the sense that it has a consistent meaning on its own, there is no difference between the following declarations. static int foo; static int foo() { }; struct S { static int foo; } struct S { static int foo() { } } And it does not take much to explain the difference between static alone versus static when paired with a second keyword. static this() { } static ~this() { } static assert() { } static if() { } static import foo;
Oct 10 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-10-10 19:31, Iain Buclaw via Digitalmars-d wrote:

 Equally, static does not have a double-meaning.
"static" is the most overloaded keyword there is ;) -- /Jacob Carlborg
Oct 10 2014
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/10/14 11:15 AM, Martin Nowak wrote:

 As this is more about stating a clear preference than deprecating the
 old syntax let me propose a compromise.

 - adding RHS rule to D's style guide http://dlang.org/dstyle.html
    with an explanation what the storage class function thing does

 - change any dmd formatting code to RHS and change our documentation

 - leave the rest to linting tools like
 https://github.com/Hackerpilot/Dscanner
This is a case of the compiler doing the *wrong* thing when requested to do something else. When I say: const int foo() { return 1;} I mean I want foo to return a const int. The compiler does the *wrong* thing, and instead applies const to the hidden this parameter. In most cases, the result is a confusing error message, because most of the time, it won't compile. But in some cases, it will compile and do something completely incorrect. This is not a problem of specification, this is a problem of human semantics. The specification is sound, correct, and completely confusing to real people. To avoid the confusion, we put the const on the right side. While not *completely* intuitive, it's much clearer what const applies to. I think leaving this to a lint tool basically is as good and effective as doing nothing. It's not a compromise at all. -Steve
Oct 10 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 13:52:30 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I think leaving this to a lint tool basically is as good and
 effective as doing nothing.
this *IS* doing nothing, from any POV.
Oct 10 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 10 October 2014 at 17:52:30 UTC, Steven Schveighoffer 
wrote:
 I think leaving this to a lint tool basically is as good and 
 effective as doing nothing. It's not a compromise at all.
I agree. The only people who run lint tools are established users (because they are the only ones who even know they exist). Established users are already well aware of how to use function attributes correctly (and for the most part did left-hand attributes in old code written before the informal convention came about). left-hand const is primarily a problem for new users of the language (particularly the large amount coming from C++). These users aren't running linters, they are still just trying to get basic projects off the ground. This issue is one of the top things I see new users have problems with in the D IRC channel. You can find new users having problems with it on Stack Overflow too.
Oct 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 11:11 AM, Brad Anderson wrote:
 left-hand const is primarily a problem for new users of the language
 (particularly the large amount coming from C++). These users aren't running
 linters, they are still just trying to get basic projects off the ground. This
 issue is one of the top things I see new users have problems with in the D IRC
 channel. You can find new users having problems with it on Stack Overflow too.
Const works differently in D than in C++, and this doesn't change that. First off, const int foo(); returning const(int) is pointless. More likely, someone coming from C++ might write: const T *foo(); // in C++ returns pointer to const T expecting it to be: const(T)* foo(); // D way to return pointer to const T and: const T *p; // C++: pointer to const char // D: const pointer to const char which means different things in C++ and D. Fortunately, nearly all these issues quickly run afoul of the compiler's type checker, and can be as quickly corrected. C++ doesn't have a notion of transitive const, so the C++ syntax cannot be generally applied and have it mean the same thing. At some point, the new D user needs to spend a bit of time learning the const system and unlearning the C++ one.
Oct 10 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 10 October 2014 at 21:10:14 UTC, Walter Bright wrote:
 Const works differently in D than in C++, and this doesn't 
 change that. First off,
I think it's rather unfortunate that D used keywords from C++ for things that work differently. const in particular but struct and class cause confusion and bickering too. Think of all the hours spent on this newsgroup arguing about logical const. If D's const were called something else like readonly nobody would be trying to shoehorn logical const into it and calls for logical const would have been discussed without having to pit two features against each other for a single spot in the language. Another is char for utf-8 code units. So many people assume a char is a character when it's actually only sometimes a character by coincidence. If it had a different name like utf8_unit people would probably write more unicode correct code naturally.
Oct 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 4:04 PM, Brad Anderson wrote:
 I think it's rather unfortunate that D used keywords from C++ for things that
 work differently. const in particular but struct and class cause confusion and
 bickering too. Think of all the hours spent on this newsgroup arguing about
 logical const. If D's const were called something else like readonly nobody
 would be trying to shoehorn logical const into it and calls for logical const
 would have been discussed without having to pit two features against each other
 for a single spot in the language.
These kinds of problems always occur when transitioning from one language to another. I'm not trying to be dismissive, but I feel that a language has to pick its battles. BTW, C++ const constantly causes confusion even for experienced C++ programmers.
 Another is char for utf-8 code units. So many people assume a char is a
 character when it's actually only sometimes a character by coincidence. If it
 had a different name like utf8_unit people would probably write more unicode
 correct code naturally.
C++ has the same problem, only far worse, since char is used for all kinds of multibyte characters, and most legacy/library code assumes ASCII. Java has the same issue (surrogate pairs). There are other issues: 1. integers overflow 2. floating point numbers have precision problems Programming languages are always imperfect models, it's like the 2x4's you buy at the hardware store are never straight. You just learn to deal with it, because perfectly straight ones would be prohibitively expensive.
Oct 12 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:
 Programming languages are always imperfect models, it's like 
 the 2x4's you buy at the hardware store are never straight. You 
 just learn to deal with it, because perfectly straight ones 
 would be prohibitively expensive.
Well... some of them are straight. If you're building something that's built from near full-length boards then you search for the straight ones. Otherwise you just take whatever. In fact, the last time I was sifting through 2x4s at Home Depot, one of the people working there asked me to set the warped ones aside so they could take them out. I'm sure they chip them and make press-board or whatever out of them instead. The other tricky thing about selecting 2x4s is that once you get to the center of the palette the boards tend to be damp, and so there's a chance that they'll be straight when you buy them but they'll warp as they dry. There's kind of an art to selecting wood for a building project. So I guess the point is that you use the proper materials for the job. With physical jobs, the leftovers can almost always be repurposed or remade into something suitable for a different job. So there's very little actual waste. Competent builders can even use salvaged materials to create an entirely new thing. I have a set of record shelves that are built from salvaged deck beams. Aged wood tends to be really beautiful because colors and textures emerge as it ages. What I've learned about building is that, just like programming, there's an established process for everything. And building new structures is largely a matter of assembling the pieces and joining them in the proscribed manner. So you quickly start thinking about projects in terms of the larger problem rather than the complexity of constructing an individual wall section or whatever.
Oct 12 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2014 2:14 PM, Sean Kelly wrote:
 On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:
 Programming languages are always imperfect models, it's like the 2x4's you buy
 at the hardware store are never straight. You just learn to deal with it,
 because perfectly straight ones would be prohibitively expensive.
Well... some of them are straight. If you're building something that's built from near full-length boards then you search for the straight ones. Otherwise you just take whatever. In fact, the last time I was sifting through 2x4s at Home Depot, one of the people working there asked me to set the warped ones aside so they could take them out. I'm sure they chip them and make press-board or whatever out of them instead.
It turns out that a lot of them can be bent straight if put in a structure in the right way. For example, triangular bracing can pull them in line. The more warped ones can be used for shorter sections. It's all about compensating for the imperfections, and a good carpenter can do that.
 So I guess the point is that you use the proper materials for the job.  With
 physical jobs, the leftovers can almost always be repurposed or remade into
 something suitable for a different job.  So there's very little actual waste.
 Competent builders can even use salvaged materials to create an entirely new
 thing.  I have a set of record shelves that are built from salvaged deck beams.
 Aged wood tends to be really beautiful because colors and textures emerge as it
 ages.
No doubt. People like salvaged wood so much they'll beat a brand new wood floor with chains. And, of course, people buy brand new jeans that are beaten with stones and deliberately ripped up.
Oct 12 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d 
wrote:
 On 10/10/14 11:15 AM, Martin Nowak wrote:
 As this is more about stating a clear preference than deprecating the
 old syntax let me propose a compromise.

 - adding RHS rule to D's style guide http://dlang.org/dstyle.html

    with an explanation what the storage class function thing does

 - change any dmd formatting code to RHS and change our documentation

 - leave the rest to linting tools like
 https://github.com/Hackerpilot/Dscanner
This is a case of the compiler doing the *wrong* thing when requested to do something else. When I say: const int foo() { return 1;} I mean I want foo to return a const int. The compiler does the *wrong* thing, and instead applies const to the hidden this parameter. In most cases, the result is a confusing error message, because most of the time, it won't compile. But in some cases, it will compile and do something completely incorrect. This is not a problem of specification, this is a problem of human semantics. The specification is sound, correct, and completely confusing to real people. To avoid the confusion, we put the const on the right side. While not *completely* intuitive, it's much clearer what const applies to. I think leaving this to a lint tool basically is as good and effective as doing nothing. It's not a compromise at all.
Agreed. Leaving this as-is in the language has almost no benefit. The only benefit is to avoid having to make minor changes to any code which puts the const on the left. But there's a definite cost in confusion and developer time. We've already been telling people for ages to put const on the right whenever it comes up, because putting it on the left is too confusing, and questions about it keep popping up. There is a long term cost to allowing const on the left and only a small, short term cost to deprecating it. This is one of those cases where focusing on not breaking code definitely costs us more than making the change, especially when we're going to be doing via the proper deprecation mechanism and not by just changing it and breaking existing code. - Jonathan M Davis
Oct 10 2014
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 10/10/2014 07:52 PM, Steven Schveighoffer wrote:
 I think leaving this to a lint tool basically is as good and effective
 as doing nothing. It's not a compromise at all.
So the goal is more to help D beginners who would add a const to the return type const int foo(); thinking it will work like const int x; rather than to improve readability. It still makes a lot sense to update all our documentation and the style guide. Any volunteer for the latter? Let's talk to Brian whether dfix would be able to do the rewrite automatically. https://github.com/Hackerpilot/dfix/issues/1
Oct 10 2014
prev sibling next sibling parent reply "Yota" <yotaxp thatGoogleMailThing.com> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 const is used both as a storage class and as a type 
 constructor, and is distinguished by the grammar:

    const(T) v; // type constructor, it affects the type T

    const T v;  // storage class, affects the symbol v and the 
 type of v

 In particular,

    const T *v;

 does not mean:

    const(T)* v;
Once again, I am thoroughly confused as to why the space is put before the * in a language where the * is associated with the type, and not the identifier. If it had been written like const T* v; Then it would be obvious that it means const(T*) v; At which point I ask, why word it such that 'const' affects the symbol v, and not the type T*? And why does the former syntax even exist if it is more proper to use the latter?
Oct 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 9:28 AM, Yota wrote:
 Once again, I am thoroughly confused as to why the space is put before the * in
 a language where the * is associated with the type, and not the identifier.
In C, you can declare multiple variables like this: T *p, *q; both are pointer to T. This is why conventionally the * gets put next to the symbol name. Such split up declarations aren't allowed in D, so conventionally the * gets put next to the type, as in: T* p, q;
 At which point I ask, why word it such that 'const' affects the symbol v, and
 not the type T*?  And why does the former syntax even exist if it is more
proper
 to use the latter?
const as storage class is useful for doing things like putting data into a read only segment. The const(T) type constructor syntax is to emphasize that const in D is transitive, i.e. it affects everything inside the ( ). This is not true of const in C++, which when used as a type constructor is left-associative, unless it is on the left when it becomes right-associative, which I find terribly confusing.
Oct 10 2014
prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/10/14 04:37, Walter Bright via Digitalmars-d wrote:
 If we're going to break things, it needs to be for something that matters. This
 doesn't make the cut.
I agree with that general sentiment, but doesn't this patch only deprecate left-hand-side function attributes? I don't particularly mind you refusing it, but deprecation (in support of good stylistic practice) isn't breaking.
Oct 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
 I agree with that general sentiment, but doesn't this patch only deprecate
 left-hand-side function attributes?
Only some of them, others remain: pure int foo() { ... }
 I don't particularly mind you refusing it, but deprecation (in support of good
 stylistic practice) isn't breaking.
Deprecation means it'll be removed.
Oct 11 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:
 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
 I agree with that general sentiment, but doesn't this patch only deprecate
 left-hand-side function attributes?
Only some of them, others remain: pure int foo() { ... }
Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.
 I don't particularly mind you refusing it, but deprecation (in support of good
 stylistic practice) isn't breaking.
Deprecation means it'll be removed.
Hmm, maybe I've misunderstood the deprecation process. It was my understanding that, to remove a feature or function, it was necessary to deprecate it first; but that deprecation would not necessarily always lead to deletion. I may be thinking too specifically of Phobos, where it's obviously much easier to deprecate a module without ever removing it.
Oct 12 2014
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:
 On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:
 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:
 I agree with that general sentiment, but doesn't this patch 
 only deprecate
 left-hand-side function attributes?
Only some of them, others remain: pure int foo() { ... }
Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.
Not necessarily. `pure` is a real function attribute, while `const` applies to the implicit `this` paramater and _not_ to the function.
Oct 12 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
 Deprecation means it'll be removed.
Hmm, maybe I've misunderstood the deprecation process. It was my understanding that, to remove a feature or function, it was necessary to deprecate it first; but that deprecation would not necessarily always lead to deletion. I may be thinking too specifically of Phobos, where it's obviously much easier to deprecate a module without ever removing it.
Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.
Oct 12 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
 On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:
 Deprecation means it'll be removed.
Hmm, maybe I've misunderstood the deprecation process. It was my understanding that, to remove a feature or function, it was necessary to deprecate it first; but that deprecation would not necessarily always lead to deletion. I may be thinking too specifically of Phobos, where it's obviously much easier to deprecate a module without ever removing it.
Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.
I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...
Oct 12 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:
 I beg forgiveness, but I think it was a timid suggestion to 
 clean up a bit Phobos...
No. I actually think it's a very good thing that it's possible to preserve old, obsolete modules in Phobos. As long as everything is covered in a strict deprecation warning to let everyone understand it is obsolete, it's better to keep the code there for backwards compatibility than gratuitously remove it, because of the risks of breakage to old codebases. For the same reason, I'm happy to see LHS attributes be deprecated, but not for support for them to be removed.
Oct 13 2014
parent "eles" <eles eles.com> writes:
On Monday, 13 October 2014 at 15:58:05 UTC, Joseph Rushton 
Wakeling wrote:
 On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:
 I beg forgiveness, but I think it was a timid suggestion to 
 clean up a bit Phobos...
Yes, you are right. Mea culpa, I misinterpreted. OTOH, there is some cleaning needed, I think, complex types being prime example.
Oct 13 2014
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
 Deprecation is a way station on the way to removal. Warnings 
 are not necessarily headed that way.
Indeed, but the choice of _when_ to remove can in practice be quite free, no? It would be possible to put in place this deprecation warning and wait for years before acting on it.
Oct 13 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 13 October 2014 at 16:00:21 UTC, Joseph Rushton 
Wakeling wrote:
 On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
 Deprecation is a way station on the way to removal. Warnings 
 are not necessarily headed that way.
Indeed, but the choice of _when_ to remove can in practice be quite free, no? It would be possible to put in place this deprecation warning and wait for years before acting on it.
This is one thing I'd love major versions to be used for. Deprecate bunch of things iteratively, remove them completely in D 3.xx.yy ; aggregate bunch of new deprecated things and release D 4.xx.yy etc.
Oct 13 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
 On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:
 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:
 I agree with that general sentiment, but doesn't this patch 
 only deprecate
 left-hand-side function attributes?
Only some of them, others remain: pure int foo() { ... }
Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.
No. Let me explain. In qualifier(type) identifier(); qualifier apply to type. This is all good, as expected. In attribute type identifier(); attribute apply to identifier. identifier is a function here, and it make sense to apply pure on a function. The problem with type qualifier on a function, is that they do not make any sense. For some reason, a type qualifier used on a function will qualify the implicit parameter. It is confusing the hell out of everybody as there is a thing on which is make sense to apply the qualifier to (the return type) and a thing where it does not make sense (the function) but for some reason, when you apply it on the function it has a "magic" meaning. That is the surprise effect.
Oct 13 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 This has come up before, and has been debated at length.

 const is used both as a storage class and as a type 
 constructor, and is distinguished by the grammar:

    const(T) v; // type constructor, it affects the type T

    const T v;  // storage class, affects the symbol v and the 
 type of v

 In particular,

    const T *v;

 does not mean:

    const(T)* v;
Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var; ??? I see no point in saying const storage class exists in D2 because there is no way to observe it because of transitivity of const qualifier.
 (I understand that there's a lot of advocacy lately about 
 "break my code", but I'm the one who bears the brunt of "you 
 guys broke my code again, even though the code was correct and 
 worked perfectly well! D sux.", besides, of course, those poor 
 souls who have to go fix their code base, and I hear again 
 about how D is unstable, another Reddit flame-fest about D 
 being unsuitable because the designers can't make up their 
 mind, etc.)
Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter). I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it. Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language. In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer.
 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this change 
 will consume users' time, too, not just ours.)
Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear. #pleasebreakourcode
Oct 10 2014
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
 This has come up before, and has been debated at length.

 const is used both as a storage class and as a type 
 constructor, and is distinguished by the grammar:

   const(T) v; // type constructor, it affects the type T

   const T v;  // storage class, affects the symbol v and the 
 type of v

 In particular,

   const T *v;

 does not mean:

   const(T)* v;
Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var;
No, look at the pointer symbol.
 Reddit users are not the ones who invest into this language. If 
 this attitude won't change it is only a matter of time until 
 you start losing existing corporate users deciding to go with 
 other language or a fork instead (likely latter).

 I am very serious. Being a D user pretty much by definition 
 implies someone willing to risk and experiment with programming 
 tools to get a business edge. If costs of maintaing own fork 
 become lower than regular losses from maintenance overhead from 
 language quirks it becomes simple pragmatical solution. There 
 is nothing personal about it.

 Consistency and being robust in preventing programmer mistakes 
 is single most important feature in the long term.  nogc, C++ 
 support, any declared feature - it all means nothing with a 
 simple necessity to not waste money fighting the language.

 In that sense proposed change is _very_ beneficial in ROI 
 terms. It forces trivial code base adjustment that results in 
 preventing very common mistake rarely obvious for a newbies. 
 This means a very real money gains in terms of training and 
 daily mantenance overhead. Something I don't care much in a 
 personal projects but will damn appreciate as one caring for 
 success of my employer.

 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this 
 change will consume users' time, too, not just ours.)
Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear.
Agreed with the sentiment.
 #pleasebreakourcode
Lol.
Oct 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:
 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;
No, look at the pointer symbol.
module test; const int** a; const(int**) b; **a = 42; Error: cannot modify const expression **a 0000000000000000 B _D4test1axPPi 0000000000000008 B _D4test1bxPPi ??? Can you give an examle of the code that actually observes the semantical difference?
Oct 11 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:
 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra 
 wrote:
 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;
No, look at the pointer symbol.
module test; const int** a; const(int**) b;
The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.
 **a = 42;
 Error: cannot modify const expression **a

 0000000000000000 B _D4test1axPPi
 0000000000000008 B _D4test1bxPPi

 ???

 Can you give an examle of the code that actually observes the 
 semantical difference?
I cannot. I was trying to prove that there isn't, after you made the statement "Wait what? Are you saying there is a single case when this is not identical to this".
Oct 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:
 On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:
 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra 
 wrote:
 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;
No, look at the pointer symbol.
module test; const int** a; const(int**) b;
The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.
There was no * in my quote, only `const(T)` vs `const T` (with any compound T) The fact that const T* means const(T*) does not indicate that const is a storage class but simply a parsing rule. Walter has made a statement that there is a const storage class that is distinct from const qualified. I want example.
Oct 11 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/11/2014 11:17 PM, Dicebot wrote:
 On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:
 On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:
 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:
 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;
No, look at the pointer symbol.
module test; const int** a; const(int**) b;
The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.
There was no * in my quote, only `const(T)` vs `const T` (with any compound T) The fact that const T* means const(T*) does not indicate that const is a storage class but simply a parsing rule. Walter has made a statement that there is a const storage class that is distinct from const qualified. I want example.
As far as I understand, this is a compiler implementation detail.
Oct 12 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 Reddit users are not the ones who invest into this language. If 
 this attitude won't change it is only a matter of time until 
 you start losing existing corporate users deciding to go with 
 other language or a fork instead (likely latter).
Sadly, +1
 I am very serious. Being a D user pretty much by definition 
 implies someone willing to risk and experiment with programming 
 tools to get a business edge. If costs of maintaing own fork 
 become lower than regular losses from maintenance overhead from 
 language quirks it becomes simple pragmatical solution. There 
 is nothing personal about it.

 Consistency and being robust in preventing programmer mistakes 
 is single most important feature in the long term.  nogc, C++ 
 support, any declared feature - it all means nothing with a 
 simple necessity to not waste money fighting the language.

 In that sense proposed change is _very_ beneficial in ROI 
 terms. It forces trivial code base adjustment that results in 
 preventing very common mistake rarely obvious for a newbies. 
 This means a very real money gains in terms of training and 
 daily mantenance overhead. Something I don't care much in a 
 personal projects but will damn appreciate as one caring for 
 success of my employer.

 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this 
 change will consume users' time, too, not just ours.)
Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear. #pleasebreakourcode
+1 over all Plus, I would not spend anymore one world in arguing against the reddit argumentation: it's really too much for me. --- /Paolo
Oct 11 2014
prev sibling next sibling parent reply "bachmeier" <no spam.net> writes:
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

 #pleasebreakourcode
No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Oct 11 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote:
 On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

 #pleasebreakourcode
No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
It does not sound as catchy :P Though I agree in statement itself
Oct 11 2014
prev sibling parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/11/2014 3:18 AM, bachmeier via Digitalmars-d wrote:
 On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

 #pleasebreakourcode
No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Yes, there will be. That there's a period of transition helps reduce it, but to believe that all code everywhere is upgraded during that transition is... wishful thinking. That said, I'm still in favor of this change. Please, remove the human confusion, there's enough of it already and this one is easy to fix.
Oct 11 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/10/14 06:11, Dicebot via Digitalmars-d wrote:
 Reddit users are not the ones who invest into this language. If this attitude
 won't change it is only a matter of time until you start losing existing
 corporate users deciding to go with other language or a fork instead (likely
 latter).

 ...

 #pleasebreakourcode
You propose ignoring Teh Internetz and try to enlist a Twitter hashtag to that end? ;-)
 Consistency and being robust in preventing programmer mistakes is single most
 important feature in the long term.  nogc, C++ support, any declared feature
 - it all means nothing with a simple necessity to not waste money fighting
 the language.

 ...

 Hardly anything matters more than that. Issues like that consume our time
 continiously for years, accumulating in wasted days weeks of worker time.
 Compared with time needed to adjust even several MLOC project gain is clear.
I don't think this message can be over-emphasized enough. By far the major difficulty of programming effectively (in any circumstances, but particularly in a corporate environment) is having to deal with quirks and special cases in a language and its libraries where "the right thing" and "the obvious thing" diverge. Such quirks don't just lead to more frequent programmer error, they also lead to uglier and less easily maintained codebases, which almost always has a multiplicative effect in terms of the overall quirkiness the developer has to deal with. It's a LOT of lost time. By contrast, when a language and/or library successfully conflates "the easy thing" and "the right thing", the effect is multiplicative in the other direction -- as a programmer, it helps you learn and implement good design patterns that carry all the way up the software stack. I'm firmly of the belief that D's successes in this respect not only made it easier for me to program, they made me a better programmer. D2 is, for the most part, excellent in this respect, but it could and should be even better. Well-managed, well-documented and well-publicized breaking changes in support of usability and correctness are desirable, not something to be avoided.
Oct 12 2014
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d wrote:
 D2 is, for the most part, excellent in this respect, but it could and should be
 even better.  Well-managed, well-documented and well-publicized breaking
changes
 in support of usability and correctness are desirable, not something to be
avoided.
I should add here -- I recognize the basic problem that faces any language when you have newcomers (or potential corporate adopters) downloading the latest compiler, downloading some codebase of interest to them, and finding that it doesn't build because of a backwards-incompatible change. Even when that change was 100% justified, you risk being seen as unstable, untrustworthy, etc., and many people are not patient enough to stick around to hear that justification. Now, that said, I think it's helpful to try and change the conversation from, "Break/don't break" to, "What would be the circumstances under which it could be feasible to make these desirable breaking changes?" The original version of this email had some thoughts on that, but to be honest, I'd rather just ask the question, without making any assumptions about what the answer could or should be.
Oct 12 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:
 On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d 
 wrote:
 D2 is, for the most part, excellent in this respect, but it 
 could and should be
 even better.  Well-managed, well-documented and 
 well-publicized breaking changes
 in support of usability and correctness are desirable, not 
 something to be avoided.
I should add here -- I recognize the basic problem that faces any language when you have newcomers (or potential corporate adopters) downloading the latest compiler, downloading some codebase of interest to them, and finding that it doesn't build because of a backwards-incompatible change. Even when that change was 100% justified, you risk being seen as unstable, untrustworthy, etc., and many people are not patient enough to stick around to hear that justification.
I used to think that this was a valid point w.r.t. rejecting changes. Over the last year of actually trying to get work done in D, I've changed my tune somewhat: At this stage, almost every release will break any project that has a decent sized code-base, *without considering any language changes or regressions*! Fixing *any* rejects-valid or accepts-invalid bug can break peoples code.[1] Adding a new symbol in phobos can break peoples code. The only way of getting meaningful stability is to slow down a lot. If we're going to keep moving fast (even just fixing bugs), then it is unavoidable that we will break people's code. We can afford a little more breakage on top of the inevitable (and undeniably necessary) pile - even for quite minor gains - as long as they are changes that can be easily managed by project maintainers.[2] The only argument that's left is: "I don't mind you breaking my code by fixing bugs in the implementation, but I do mind when it's for cleaning/changing the language/phobos". In light of recent comments from heavyweight users saying "please break my code in the name of improving the language and libraries", I don't think it holds much water. [1] The "code that was already broken" is often dodgy. What constitutes broken code? There's a lot of very fragile code out there that is doing it's job just fine, in the limited circumstances it's used. [2] By easily managed I don't mean sed-able, or even tooling-fixable. For me it pivots on being able to maintain one code-base that will compile with multiple compiler versions. An example where this fails: nogc, being an attribute, isn't aliasable, meaning you can't version it out neatly. #PleaseBreakMyCode but also #PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWit AVarietyOfCompilers Hmm, not so catchy :)
Oct 13 2014
next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 13 October 2014 at 17:15:34 UTC, John Colvin wrote:
 The only argument that's left is: "I don't mind you breaking my 
 code by fixing bugs in the implementation, but I do mind when 
 it's for cleaning/changing the language/phobos". In light of 
 recent comments from heavyweight users saying "please break my 
 code in the name of improving the language and libraries", I 
 don't think it holds much water.
Well, in this case we don't necessarily need to break anyone's code, it would be possible to stop at deprecation. But generally speaking, I agree with you, which is why I was hoping to move the debate to, "What are the circumstances under which these breaks are possible," rather than "Should we/shouldn't we".
Oct 13 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"John Colvin"  wrote in message news:ljjtmnnckwzenvhawawx forum.dlang.org...

 [2] By easily managed I don't mean sed-able, or even tooling-fixable. For 
 me it pivots on being able to maintain one code-base that will compile 
 with multiple compiler versions. An example where this fails:  nogc, being 
 an attribute, isn't aliasable, meaning you can't version it out neatly.
There is nothing stopping you from not supporting nogc until your oldest supported dmd version has it. I agree with your requirement, but this is not a good example of it. A better example would be requiring nothrow annotations on inline asm blocks, because the old code won't compile with newer dmds and the new code won't compile with older ones.
Oct 14 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 14 October 2014 at 16:11:34 UTC, Daniel Murphy wrote:
 "John Colvin"  wrote in message 
 news:ljjtmnnckwzenvhawawx forum.dlang.org...

 [2] By easily managed I don't mean sed-able, or even 
 tooling-fixable. For me it pivots on being able to maintain 
 one code-base that will compile with multiple compiler 
 versions. An example where this fails:  nogc, being an 
 attribute, isn't aliasable, meaning you can't version it out 
 neatly.
There is nothing stopping you from not supporting nogc until your oldest supported dmd version has it.
Good point. It would be nice to be able to take advantage of new features though, whilst maintaining backward compatibility. Also, a 3rd party project could make nogc a requirement, meaning I have to choose between compatibility with older compilers or with that 3rd party code. Alias-able attributes would help a lot.
 I agree with your requirement, but this is not a good example 
 of it.  A better example would be requiring nothrow annotations 
 on inline asm blocks, because the old code won't compile with 
 newer dmds and the new code won't compile with older ones.
Yes, that's a more concrete example, thanks.
Oct 14 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak <code dawg.eu>:

 Kenji just proposed a slightly controversial pull request so I want to 
 reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a 
 function.
 
 So instead of
      const int foo();
 you'd should write
      int foo() const;
 
 Then at some future point we could apply the left hand side qualifiers 
 to the return type, e.g. `const int foo();` == `const(int) foo();`
 
 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?
 
 https://github.com/D-Programming-Language/dmd/pull/4043
I write my function signatures like this now and I'm fine with the change: safe pure nothrow nogc [<1] final override property ref [<2] int foo() shared const [<3] { ... } [1] Attributes that hint the compiler by narrowing down allowed language features. [2] Visibility and behavioral attributes. [3] Modifiers for implicit `this`. -- Marco
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 00:25:07 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I'm not sure whether I care to _enforce_ this style rather than
 strongly encourage it, as it's a breaking change.  I'd rather
 deprecation of left-hand-side attributes, rather than illegality, if
 that is possible.
the patch does exactly that: compiler emits deprecation warnings on prefix attributes. nobody plans to break things immediately. ;-)
Oct 10 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
 Would this affect your code?
I'll live.
 Do you think it makes your code better or worse?
On the balance, neither.
 Is this just a pointless style change?
Changes that mitigate patterns of human error are _never_ pointless. -Wyatt
Oct 10 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9 Oct 2014 09:55, "Martin Nowak via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a
function.
 So instead of
     const int foo();
 you'd should write
     int foo() const;

 Then at some future point we could apply the left hand side qualifiers to
the return type, e.g. `const int foo();` == `const(int) foo();`
 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?

 https://github.com/D-Programming-Language/dmd/pull/4043
You have my full support in this. What we should first focus on it the path of least resistance to making this happen. Preferably sooner rather than later. Iain.
Oct 10 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message news:m15i9c$51b$1 digitalmars.com...

      const int foo();
The existing behavior would be great to have if we were deliberately trying to trip up all programmers coming from C++. Kill it with fire.
Oct 10 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 11 Oct 2014 05:19:05 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 The existing behavior would be great to have if we were deliberately
 trying to trip up all programmers coming from C++.
suddenly, i starting to believe that we should not deprecate prefix attributes...
Oct 10 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/10/14 09:45, ketmar via Digitalmars-d wrote:
 the patch does exactly that: compiler emits deprecation warnings on
 prefix attributes. nobody plans to break things immediately. ;-)
It's not the "immediately" I'm worried about, it's the "eventually".
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 11 Oct 2014 00:49:14 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 On 10/10/14 09:45, ketmar via Digitalmars-d wrote:
 the patch does exactly that: compiler emits deprecation warnings on
 prefix attributes. nobody plans to break things immediately. ;-)
It's not the "immediately" I'm worried about, it's the "eventually".
i can't see why we should keep the syntax that nobody likes. this will just confuse newcomers. that was the argument against adding " " to "nothrow" and "pure" (and keeping the old syntax simultaneously). if it works there, it should work here too.
Oct 10 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/10/14 00:58, ketmar via Digitalmars-d wrote:
 i can't see why we should keep the syntax that nobody likes. this will
 just confuse newcomers. that was the argument against adding " " to
 "nothrow" and "pure" (and keeping the old syntax simultaneously). if it
 works there, it should work here too.
I don't mind deprecating the syntax that nobody likes. I mind the idea of removing it, because has the potential to break old code for no particularly good reason. BTW I repeat, as far as I can tell, Ddoc will always place the attributes on the left of the function. That needs to be fixed if the proposed patch is to go through.
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 11 Oct 2014 01:13:51 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I don't mind deprecating the syntax that nobody likes.  I mind the
 idea of removing it, because has the potential to break old code for
 no particularly good reason.
there is good reason: this syntax is confusing. if it will stay as deprecated, newcomers will have just one more question: "why it's still here?" and about breaking old code. if this code is so old that nobody will fix it... well, one can use old compiler to build that code. but that code rot many years ago anyway: it's unmaintained. it *will* break sooner or later, there is no sane reason to trying to keep zombie alive, zombies must be destroyed.
Oct 10 2014
prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353

There has been a broad support for this on the newsgroup discussion 
because this regularly confuses beginners.
There are also some arguments against it (particularly by Walter) saying 
that this change will put too much work on D code owners.

Let's continue with the following steps.
- add RHS/LHS function qualifiers to D's style guide
- change all code formatting (like dmd's headergen and ddoc to use RHS 
qualifiers)
- help Brian to get dfix up and running 
(https://github.com/Hackerpilot/dfix/issues/1)

Then we might revisit the topic in 6 month and see whether we have 
better arguments now.
Oct 11 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 11 Oct 2014 14:47:55 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Then we might revisit the topic in 6 month and see whether we have=20
 better arguments now.
six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they?
Oct 11 2014
parent reply "ketmar gtfo" <dont spam.me> writes:
On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
Digitalmars-d wrote:
 On Sat, 11 Oct 2014 14:47:55 +0200
 Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.
six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they?
gtfo ketmar
Oct 11 2014
parent "ketmar gtfo gtfo" <jsutarandominboxforastupidjoke gmail.com> writes:
On Saturday, 11 October 2014 at 15:17:36 UTC, ketmar gtfo wrote:
 On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
 Digitalmars-d wrote:
 On Sat, 11 Oct 2014 14:47:55 +0200
 Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.
six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they?
gtfo ketmar
gtfo ketmar gtfo
Oct 11 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 12:48:03 UTC, Martin Nowak wrote:
 https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353

 There has been a broad support for this on the newsgroup 
 discussion because this regularly confuses beginners.
 There are also some arguments against it (particularly by 
 Walter) saying that this change will put too much work on D 
 code owners.

 Let's continue with the following steps.
 - add RHS/LHS function qualifiers to D's style guide
 - change all code formatting (like dmd's headergen and ddoc to 
 use RHS qualifiers)
 - help Brian to get dfix up and running 
 (https://github.com/Hackerpilot/dfix/issues/1)

 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.
Sounds good but what is the benefit over just having deprecation period 6 months longer?
Oct 11 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, October 11, 2014 14:47:55 Martin Nowak via Digitalmars-d wrote:
 https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-5874835
 3

 There has been a broad support for this on the newsgroup discussion
 because this regularly confuses beginners.
 There are also some arguments against it (particularly by Walter) saying
 that this change will put too much work on D code owners.

 Let's continue with the following steps.
 - add RHS/LHS function qualifiers to D's style guide
 - change all code formatting (like dmd's headergen and ddoc to use RHS
 qualifiers)
 - help Brian to get dfix up and running
 (https://github.com/Hackerpilot/dfix/issues/1)

 Then we might revisit the topic in 6 month and see whether we have
 better arguments now.
This has been being brought up for years. I wouldn't expect 6 months to change anything. If we want to delay it until dmd's headergen and ddoc are fixed and put a note in the changelog on the next release that it's going to be deprecated rather than deprecating it immediately, we can do that, but I don't think for a second that the arguments are going to change. Many of us have been complaining about this for years, and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is (which I strongly dispute). As far as I can tell, Walter is the only real obstacle to this. Almost no one else ever seems to think that having const function modifiers on the left is a good idea. And now that someone has finally implemented the change, I really think that we need to get it merged. Honestly, I think that delaying making the change just increases how much harm the problem is causing, because it's around that much longer, confusing that many more folks. As far as popular opinion goes, it's quite clear that almost everyone posting here thinks that it should be changed. The only one who seems to really need to be convinced is Walter, and apparently, no one knows how to do that. I can see delaying making the changes until the dmd headergen is fixed being needed so that the compiler isn't generating code that it then prints a deprecation message for, and it would be nice if the ddoc generation were fixed ASAP as well, but if that's the case, I think that that just means that those should be fixed ASAP so that const function qualifiers on the left can be deprecated ASAP. I see no need to continue to discuss whether we should do this beyond someone miraculously coming up with a way to convince Walter. - Jonathan M Davis
Oct 11 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 and it's primarily been Walter who hasn't wanted it on the
 grounds that it's more consistent as it is
Consistency is a good thing to have, but if adhering to it causes bugs and troubles, and if the symmetry breakage causes readable compile-time errors, then it's often a good idea to do it. D language contains plenty of situations where this happens (and arguably few more cases should be added, like the sbyte/ubyte pair of names breaking the consistency of name/uname naming scheme for the other integral types, to avoid people think all the time that a byte is unsigned). Bye, bearophile
Oct 11 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 11 Oct 2014 22:41:50 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Jonathan M Davis:
=20
 and it's primarily been Walter who hasn't wanted it on the
 grounds that it's more consistent as it is
=20 Consistency is a good thing to have
and it's not a goal, it's just a nice way to say "i don't want this". see " safe", " trusted", "pure" and "nothrow", for example. i can hardly say that it's consistent. "breaking consistency" rising up only if there is nothing else to say against something.
Oct 11 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
 This has been being brought up for years. I wouldn't expect 6 
 months to change
 anything. If we want to delay it until dmd's headergen and ddoc 
 are fixed and
 put a note in the changelog on the next release that it's going 
 to be
 deprecated rather than deprecating it immediately, we can do 
 that, but I don't
 think for a second that the arguments are going to change.
Automatic code rewriting is what might make syntax deprecations more feasible in 6 month.
Oct 12 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, October 12, 2014 21:17:29 Martin Nowak via Digitalmars-d wrote:
 This has been being brought up for years. I wouldn't expect 6
 months to change
 anything. If we want to delay it until dmd's headergen and ddoc
 are fixed and
 put a note in the changelog on the next release that it's going
 to be
 deprecated rather than deprecating it immediately, we can do
 that, but I don't
 think for a second that the arguments are going to change.
Automatic code rewriting is what might make syntax deprecations more feasible in 6 month.
Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time. And since it'll be generating deprecation messages - not errors - and it's for a practice that we've already been discouraging for some time now, I don't think that waiting for dfix buys us much. I totally agree that it would be nice to have, but I don't see it as a showstopper at all. The only significant problem I see is dmd's headergen, because if that's putting const on the left, then it'll generate code that will then be warned about, which would definitely be bad. The ddoc generation should be fixed to, but that can be done later, because the semantics won't have changed; it's just that if you do it in your own code, you'll get a deprecation message. I'd very much like to see this change made sooner rather than later. I think that it continues to harm us as long as it isn't changed, and the change really doesn't cost much even if your whole codebase needs to be updated, because it's very simple and straightforward. - Jonathan M Davis
Oct 12 2014
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
 Automatic code rewriting is what might make syntax deprecations
 more feasible in 6 month.
Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time.
The main counterargument against this change is that it's yet another change that require people to rewrite their code. Also the pull simply deprecates certain code, but for good acceptance we also need to educate D users why we're doing this change and must make updating code as painless as possible. A tool like dfix will become more important with every line of D code that is written. Too often we're only looking at phobos.
 it's for a practice that we've already been discouraging for 
 some time now
Never heard of it before. If this were common knowledge, as in every D beginner would stumble over that information, it would solve half of the problem. I'd still welcome if someone updated the style guide.
 I see is dmd's headergen, because if that's putting const on 
 the left, then
 it'll generate code that will then be warned about, which would 
 definitely be
 bad. The ddoc generation should be fixed to, but that can be 
 done later,
Obviously we should fix all of our own code and explain people why they should update theirs before we start deprecating it.
Oct 12 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 October 2014 at 23:25:57 UTC, Martin Nowak wrote:
 Automatic code rewriting is what might make syntax 
 deprecations
 more feasible in 6 month.
Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time.
The main counterargument against this change is that it's yet another change that require people to rewrite their code. Also the pull simply deprecates certain code, but for good acceptance we also need to educate D users why we're doing this change and must make updating code as painless as possible. A tool like dfix will become more important with every line of D code that is written. Too often we're only looking at phobos.
I'm sorry, but that won't cut it. People have been asking for this change since like forever. This whole problem could be gone by now, and at the time there was no release that won't make you rewrite your code anyway. No it is like, "we didn't made the change at the time for bad reason, and now we don't want to make the change because we made a bad decision at the time and change is more costly now".
Oct 13 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 October 2014 at 21:51:33 UTC, Jonathan M Davis via
Digitalmars-d wrote:
 Perhaps, but this change is so straightforward that I would 
 expect that even a
 very large codebase could be updated in a very short space of 
 time. And since
 it'll be generating deprecation messages - not errors - and 
 it's for a
 practice that we've already been discouraging for some time 
 now, I don't think
 that waiting for dfix buys us much. I totally agree that it 
 would be nice to
 have, but I don't see it as a showstopper at all. The only 
 significant problem
 I see is dmd's headergen, because if that's putting const on 
 the left, then
 it'll generate code that will then be warned about, which would 
 definitely be
 bad. The ddoc generation should be fixed to, but that can be 
 done later,
 because the semantics won't have changed; it's just that if you 
 do it in your
 own code, you'll get a deprecation message.

 I'd very much like to see this change made sooner rather than 
 later. I think
 that it continues to harm us as long as it isn't changed, and 
 the change
 really doesn't cost much even if your whole codebase needs to 
 be updated,
 because it's very simple and straightforward.

 - Jonathan M Davis
The right path forward seems to be deprecating now, but not removing before dfix can do something good about it.
Oct 13 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, October 13, 2014 19:59:13 deadalnix via Digitalmars-d wrote:
 The right path forward seems to be deprecating now, but not
 removing before dfix can do something good about it.
I don't know that we need to wait for dfix, but we never remove deprecated stuff from the language very quickly anyway. So, I expect that it'll be around for at least a year or two before we look at actually removing it, so dfix will presumably be able to take care of it long before we're looking to remove it anyway. - Jonathan M Davis
Oct 13 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.768.1413233509.9932.digitalmars-d puremagic.com...

 I don't know that we need to wait for dfix, but we never remove deprecated
 stuff from the language very quickly anyway. So, I expect that it'll be 
 around
 for at least a year or two before we look at actually removing it, so dfix
 will presumably be able to take care of it long before we're looking to 
 remove
 it anyway.
And even without dfix, non-trivial year-old code rarely compiles with the latest frontend.
Oct 14 2014
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Sat, 11 Oct 2014 13:47:55 +0100, Martin Nowak  
<code+news.digitalmars dawg.eu> wrote:

 https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353

 There has been a broad support for this on the newsgroup discussion  
 because this regularly confuses beginners.
 There are also some arguments against it (particularly by Walter) saying  
 that this change will put too much work on D code owners.

 Let's continue with the following steps.
 - add RHS/LHS function qualifiers to D's style guide
 - change all code formatting (like dmd's headergen and ddoc to use RHS  
 qualifiers)
 - help Brian to get dfix up and running  
 (https://github.com/Hackerpilot/dfix/issues/1)

 Then we might revisit the topic in 6 month and see whether we have  
 better arguments now.
+1 -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2014
prev sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> wrote:
 Would this affect your code?
Probably, but I have no D code of any size to care about.
 Do you think it makes your code better or worse?
Better.
 Is this just a pointless style change?
Nope.
 Anything else?
Only what you said in summary to this thread (I am waay late to this party) Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 15 2014
next sibling parent "HaraldZealot" <harald_zealot tut.by> writes:
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> 
 wrote:
 Would this affect your code?
No
 Do you think it makes your code better or worse?
Better. More clear
 Is this just a pointless style change?
No
Oct 18 2014
prev sibling parent reply "eles" <eles215 gzk.dot> writes:
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> 
 wrote:
 Would this affect your code?
Probably, but I have no D code of any size to care about.
Would this change make you to write more code in D?
Oct 19 2014
parent "Regan Heath" <regan netmail.co.nz> writes:
On Sun, 19 Oct 2014 10:06:31 +0100, eles <eles215 gzk.dot> wrote:

 On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> wrote:
 Would this affect your code?
Probably, but I have no D code of any size to care about.
Would this change make you to write more code in D?
No. The blockers for me are: 1- We're not likely to use D here at work any time soon. We're writing new stuff in C#/Java and we maintain legacy C/C++. 2- For my own projects I typically write windows GUI programs and D is no where near C# for this. 3- Last time I tried to write anything non-GUI of a substantial nature I was annoyed by the fact that I could not mixin virtual methods (which I know is a tough problem and waaay down the priority list if at all). It's a silly reason to be put off, I know, it was just disappointing and enough to put the brakes on and I just drifted off after that. 4- TBH I don't have enough free time or motivation to do more, it's not you (D) it's me :P R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 20 2014