digitalmars.D - Make const, immutable, inout, and shared illegal as function attributes
- Martin Nowak (15/15) Oct 09 2014 Kenji just proposed a slightly controversial pull request so I want to
- Brian Schott (10/25) Oct 09 2014 No. D-Scanner's style checker yells at you when you try to do
- ketmar via Digitalmars-d (5/25) Oct 09 2014 i'm all for this. prefix function attributes are *VERY* confusing. i
- ketmar via Digitalmars-d (6/6) Oct 09 2014 On Thu, 9 Oct 2014 12:04:36 +0300
- francesco cattoglio (7/14) Oct 09 2014 I know it's not happening anytime soon, but I'm against this
- Lionello Lunesu (2/14) Oct 13 2014 +1
- deadalnix (2/18) Oct 09 2014 Yes, yes, yes YES ! YYYEEEEEESSSSSS !
- Paolo Invernizzi (4/20) Oct 09 2014 I'm for going ahead with that.
- bearophile (6/17) Oct 09 2014 In this case I think it's better to focus on the most important
- Johannes Pfau (11/15) Oct 09 2014 Most old code, yes. I used to write all attributes on the left hand
- Johannes Pfau (4/25) Oct 09 2014 Forgot to some overall I'm for this change. I'd just like some
- Brian Schott (6/8) Oct 09 2014 I said that I wouldn't write dfix until Walter was willing to
- Martin Nowak (4/6) Oct 09 2014 That would make such decisions much easier :).
- Brian Schott (5/7) Oct 09 2014 The features that are implemented so far don't need the AST.
- Joakim (10/20) Oct 09 2014 This is great news. Even if it's not going to be packaged with
- Walter Bright (2/10) Oct 09 2014 dfix will be a welcome addition. Glad you're working on it!
- Daniel Kozak via Digitalmars-d (6/24) Oct 09 2014 Yes (but I am ok with that)
- Robert burner Schadek (5/9) Oct 09 2014 no change, my code already looks like that
- Sag Academy (3/13) Oct 09 2014 mostly welcome
- monarch_dodra (15/19) Oct 09 2014 I've written code before in the style:
- Joseph Rushton Wakeling via Digitalmars-d (12/17) Oct 09 2014 Besides,
- deadalnix (5/26) Oct 09 2014 Also
- Dominikus Dittes Scherkl (4/7) Oct 09 2014 Better.
- Atila Neves (3/19) Oct 09 2014 This pull request is a good thing (TM). +1 all the way.
- =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d (6/9) Oct 09 2014 less ambiguous, so I would say better
- Dicebot (6/17) Oct 09 2014 Yes, eventually, but I am willing to make the change and it is
- Steven Schveighoffer (12/27) Oct 09 2014 First, I'm all for the change. If it affects my code, I don't care, I'll...
- Kenji Hara via Digitalmars-d (4/10) Oct 09 2014 My PR still allows those block or label style attributes.
- Sean Kelly (2/2) Oct 09 2014 It's a clean break and easy to fix, and eliminated a confusing
- Brad Anderson (12/16) Oct 09 2014 +1.
- Jonathan M Davis via Digitalmars-d (9/24) Oct 09 2014 Well, since I'm the one who created the enhancement request that this is...
- Gary Willoughby (2/6) Oct 09 2014 Great. I support this.
- Joseph Rushton Wakeling via Digitalmars-d (10/15) Oct 09 2014 No, but is it fixed on the ddoc side? The last ddoc I generated had fun...
- Walter Bright (24/27) Oct 09 2014 This has come up before, and has been debated at length.
- deadalnix (11/16) Oct 09 2014 Come on that is the same bogus reason every time. const here do
- ketmar via Digitalmars-d (14/16) Oct 10 2014 ah, again...
- market (4/27) Oct 10 2014 yoooohoooo!
- eles (2/6) Oct 10 2014 That kind of attitude does not help much.
- ketmar via Digitalmars-d (5/6) Oct 10 2014 can't see any technical discussion here. and can't see me ranting about
- market (3/11) Oct 10 2014 please just go. please
- ketmar via Digitalmars-d (3/4) Oct 10 2014 (smiles) you are funny.
- market (3/7) Oct 10 2014 you are not. gtfo ketmar
- Brad Roberts via Digitalmars-d (3/11) Oct 10 2014 Market, I can't tell if you're joking or not. Either way, time for it
- market (4/16) Oct 10 2014 I am not joking! ketmar is becoming the D resident troll. And
- Steven Schveighoffer (3/15) Oct 10 2014 Don't feed the troll, let market go away on his own.
- bearophile (4/6) Oct 10 2014 I think you are wrong. This seems a worthy little breaking change.
- Steven Schveighoffer (17/32) Oct 10 2014 Can you demonstrate this? I hate to see D reject a unanimously wanted
- ketmar via Digitalmars-d (5/8) Oct 10 2014 On Fri, 10 Oct 2014 09:42:14 -0400
- Steven Schveighoffer (3/11) Oct 10 2014 They will and have.
- bachmeier (11/25) Oct 10 2014 Or read the many Reddit comments about how C++ syntax and gotchas
- Don (14/48) Oct 10 2014 None of those professional complainers matter though. They'll
- eles (3/7) Oct 10 2014 As, IIRC, Teoh put it once: everywhere you turn, you see
- Jonathan M Davis via Digitalmars-d (4/32) Oct 10 2014 +1
- Martin Nowak (19/36) Oct 10 2014 What's the difference between a const symbol and a normal symbol?
- eles (8/12) Oct 10 2014 I don't like it. If it is not in the language, then why bother
- Walter Bright (10/27) Oct 10 2014 I can blame C++ for that, because in C++ the difference between const as...
- Iain Buclaw via Digitalmars-d (7/23) Oct 10 2014 storage class and as type constructor is much more subtle than in D, but...
- Walter Bright (7/9) Oct 10 2014 I meant when perceptions about what something means are carried over fro...
- Ola Fosheim Grostad (6/10) Oct 10 2014 Yeah, but you asked for it by deliberately making D C-like. Being
- ketmar via Digitalmars-d (3/6) Oct 10 2014 and 'enum' too.
- Iain Buclaw via Digitalmars-d (15/22) Oct 10 2014 I meant in the sense that it has a consistent meaning on its own,
- Jacob Carlborg (4/5) Oct 10 2014 "static" is the most overloaded keyword there is ;)
- Steven Schveighoffer (19/26) Oct 10 2014 This is a case of the compiler doing the *wrong* thing when requested to...
- ketmar via Digitalmars-d (4/6) Oct 10 2014 On Fri, 10 Oct 2014 13:52:30 -0400
- Brad Anderson (15/17) Oct 10 2014 I agree. The only people who run lint tools are established users
- Walter Bright (16/21) Oct 10 2014 Const works differently in D than in C++, and this doesn't change that. ...
- Brad Anderson (13/15) Oct 10 2014 I think it's rather unfortunate that D used keywords from C++ for
- Walter Bright (14/25) Oct 12 2014 These kinds of problems always occur when transitioning from one languag...
- Sean Kelly (28/32) Oct 12 2014 Well... some of them are straight. If you're building something
- Walter Bright (8/26) Oct 12 2014 It turns out that a lot of them can be bent straight if put in a structu...
- Jonathan M Davis via Digitalmars-d (14/43) Oct 10 2014 Agreed.
- Martin Nowak (12/14) Oct 10 2014 So the goal is more to help D beginners who would add a const to the
- Yota (10/19) Oct 10 2014 Once again, I am thoroughly confused as to why the space is put
- Walter Bright (13/18) Oct 10 2014 In C, you can declare multiple variables like this:
- Joseph Rushton Wakeling via Digitalmars-d (5/7) Oct 10 2014 I agree with that general sentiment, but doesn't this patch only depreca...
- Walter Bright (4/8) Oct 11 2014 Only some of them, others remain:
- Joseph Rushton Wakeling via Digitalmars-d (8/16) Oct 12 2014 Not good. If LHS function attributes are to be deprecated, it really ou...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (5/17) Oct 12 2014 Not necessarily. `pure` is a real function attribute, while
- Walter Bright (3/9) Oct 12 2014 Deprecation is a way station on the way to removal. Warnings are not nec...
- eles (3/19) Oct 12 2014 I beg forgiveness, but I think it was a timid suggestion to clean
- Joseph Rushton Wakeling (10/12) Oct 13 2014 No.
- eles (5/8) Oct 13 2014 Yes, you are right. Mea culpa, I misinterpreted.
- Joseph Rushton Wakeling (4/6) Oct 13 2014 Indeed, but the choice of _when_ to remove can in practice be
- Dicebot (6/12) Oct 13 2014 This is one thing I'd love major versions to be used for.
- deadalnix (17/29) Oct 13 2014 No. Let me explain. In
- Dicebot (34/55) Oct 10 2014 Wait what? Are you saying there is a single case when this:
- monarch_dodra (4/55) Oct 11 2014 Agreed with the sentiment.
- Dicebot (11/19) Oct 11 2014 module test;
- monarch_dodra (6/27) Oct 11 2014 The original code you quoted was "const(T)* v;" where the "*" was
- Dicebot (7/26) Oct 11 2014 There was no * in my quote, only `const(T)` vs `const T` (with
- Timon Gehr (2/28) Oct 12 2014 As far as I understand, this is a compiler implementation detail.
- Paolo Invernizzi (7/37) Oct 11 2014 +1 over all
- bachmeier (4/5) Oct 11 2014 No, it's #pleasedeprecateourcode
- Dicebot (2/7) Oct 11 2014 It does not sound as catchy :P Though I agree in statement itself
- Brad Roberts via Digitalmars-d (6/11) Oct 11 2014 Yes, there will be. That there's a period of transition helps reduce
- Joseph Rushton Wakeling via Digitalmars-d (20/34) Oct 12 2014 You propose ignoring Teh Internetz and try to enlist a Twitter hashtag t...
- Joseph Rushton Wakeling via Digitalmars-d (13/16) Oct 12 2014 I should add here -- I recognize the basic problem that faces any langua...
- John Colvin (36/52) Oct 13 2014 I used to think that this was a valid point w.r.t. rejecting
- Joseph Rushton Wakeling (7/13) Oct 13 2014 Well, in this case we don't necessarily need to break anyone's
- Daniel Murphy (6/10) Oct 14 2014 There is nothing stopping you from not supporting @nogc until your oldes...
- John Colvin (8/22) Oct 14 2014 Good point.
- Marco Leise (15/34) Oct 10 2014 I write my function signatures like this now and I'm fine with
- ketmar via Digitalmars-d (5/9) Oct 10 2014 On Fri, 10 Oct 2014 00:25:07 +0200
- Wyatt (6/9) Oct 10 2014 On the balance, neither.
- Iain Buclaw via Digitalmars-d (9/21) Oct 10 2014 reach out for more people to discuss it's tradeoffs.
- Daniel Murphy (3/4) Oct 10 2014 The existing behavior would be great to have if we were deliberately try...
- ketmar via Digitalmars-d (4/6) Oct 10 2014 suddenly, i starting to believe that we should not deprecate prefix
- Joseph Rushton Wakeling via Digitalmars-d (2/4) Oct 10 2014 It's not the "immediately" I'm worried about, it's the "eventually".
- ketmar via Digitalmars-d (7/11) Oct 10 2014 On Sat, 11 Oct 2014 00:49:14 +0200
- Joseph Rushton Wakeling via Digitalmars-d (7/11) Oct 10 2014 I don't mind deprecating the syntax that nobody likes. I mind the idea ...
- ketmar via Digitalmars-d (11/14) Oct 10 2014 On Sat, 11 Oct 2014 01:13:51 +0200
- Martin Nowak (13/13) Oct 11 2014 https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-587...
- ketmar via Digitalmars-d (4/6) Oct 11 2014 six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok,
- ketmar gtfo (3/11) Oct 11 2014 gtfo ketmar
- ketmar gtfo gtfo (2/14) Oct 11 2014 gtfo ketmar gtfo
- Dicebot (3/17) Oct 11 2014 Sounds good but what is the benefit over just having deprecation
- Jonathan M Davis via Digitalmars-d (26/40) Oct 11 2014 This has been being brought up for years. I wouldn't expect 6 months to ...
- bearophile (11/13) Oct 11 2014 Consistency is a good thing to have, but if adhering to it causes
- ketmar via Digitalmars-d (6/12) Oct 11 2014 and it's not a goal, it's just a nice way to say "i don't want this".
- Martin Nowak (2/11) Oct 12 2014 Automatic code rewriting is what might make syntax deprecations
- Jonathan M Davis via Digitalmars-d (17/28) Oct 12 2014 Perhaps, but this change is so straightforward that I would expect that ...
- Martin Nowak (13/27) Oct 12 2014 The main counterargument against this change is that it's yet
- deadalnix (8/23) Oct 13 2014 I'm sorry, but that won't cut it. People have been asking for
- deadalnix (4/33) Oct 13 2014 The right path forward seems to be deprecating now, but not
- Jonathan M Davis via Digitalmars-d (7/9) Oct 13 2014 I don't know that we need to wait for dfix, but we never remove deprecat...
- Daniel Murphy (4/11) Oct 14 2014 And even without dfix, non-trivial year-old code rarely compiles with th...
- Regan Heath (5/18) Oct 15 2014 +1
- Regan Heath (8/12) Oct 15 2014 Better.
- HaraldZealot (4/9) Oct 18 2014 Better. More clear
- eles (2/6) Oct 19 2014 Would this change make you to write more code in D?
- Regan Heath (16/22) Oct 20 2014 No. The blockers for me are:
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
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
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/4043i'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
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
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 itThen 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
On 09/10/14 17:32, francesco cattoglio wrote:On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:+1Kenji 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 itThen 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 13 2014
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/4043Yes, yes, yes YES ! YYYEEEEEESSSSSS !
Oct 09 2014
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/4043I'm for going ahead with that. --- /Paolo
Oct 09 2014
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
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
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>:Forgot to some overall I'm for this change. I'd just like some automated way to fix old code ;-)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
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
On 10/09/2014 01:10 PM, Brian Schott wrote:dfix is under development. You can find it here: https://github.com/Hackerpilot/dfixThat 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
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
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: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.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
On 10/9/2014 4:10 AM, Brian Schott wrote:On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:dfix will be a welcome addition. Glad you're working on it!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
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 betterIs this just a pointless style change?NoAnything else?Merge this ASAP, please :)
Oct 09 2014
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:>Would this affect your code?noDo you think it makes your code better or worse?no change, my code already looks like thatIs this just a pointless style change?no, left hand side function qualifier is just wrong IMO.Anything else?Thank you guys
Oct 09 2014
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:>mostly welcomeWould this affect your code?noDo you think it makes your code better or worse?no change, my code already looks like thatIs this just a pointless style change?no, left hand side function qualifier is just wrong IMO.Anything else?Thank you guys
Oct 09 2014
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
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
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:Also const int delegate() const dg; Is dg const or the return type ?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
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
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
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 mindDo you think it makes your code better or worse?less ambiguous, so I would say betterIs this just a pointless style change?no -- Martin
Oct 09 2014
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
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/4043First, 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
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
It's a clean break and easy to fix, and eliminated a confusing ambiguity. I'm all for it.
Oct 09 2014
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
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/4043Well, 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
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
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.I like this idea less. const(int) is explicit in a way that const int isn't.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();`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
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
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
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
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:yoooohoooo! wait.... why are you still posting? gtfoIf 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
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 -0700wait.... why are you still posting? gtfoThat kind of attitude does not help much.
Oct 10 2014
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
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:please just go. pleasewait.... 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
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
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:you are not. gtfo ketmarplease just go. please(smiles) you are funny.
Oct 10 2014
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:Market, I can't tell if you're joking or not. Either way, time for it to stop.On Fri, 10 Oct 2014 18:14:28 +0000 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:you are not. gtfo ketmarplease just go. please(smiles) you are funny.
Oct 10 2014
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:I am not joking! ketmar is becoming the D resident troll. And does nothing for D aside spewing shit. ketmar must gtfo.On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote:Market, I can't tell if you're joking or not. Either way, time for it to stop.On Fri, 10 Oct 2014 18:14:28 +0000 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:you are not. gtfo ketmarplease just go. please(smiles) you are funny.
Oct 10 2014
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:Don't feed the troll, let market go away on his own. -SteveOn Friday, 10 October 2014 at 19:14:50 UTC, ketmar via Digitalmars-d wrote:Market, I can't tell if you're joking or not. Either way, time for it to stop.On Fri, 10 Oct 2014 18:14:28 +0000 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:you are not. gtfo ketmarplease just go. please(smiles) you are funny.
Oct 10 2014
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
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
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
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:They will and have. -SteveReally, 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.
Oct 10 2014
On Friday, 10 October 2014 at 13:42:14 UTC, Steven Schveighoffer wrote: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.(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.
Oct 10 2014
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:On 10/9/2014 1:50 AM, Martin Nowak wrote: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.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.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
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
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:Exactly!(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.+1 - Jonathan M DavisThis 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
On 10/10/2014 04:37 AM, Walter Bright wrote:On 10/9/2014 1:50 AM, Martin Nowak wrote:That on it's own is fairly difficult to explain.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 vFor 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
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/DscannerI 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
On 10/10/2014 8:15 AM, Martin Nowak wrote: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.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 vThat on it's own is fairly difficult to explain.A const field member, for example, didn't contribute to the size of the struct.For functions, const-as-storage-class applies to the function symbol.What's the difference between a const symbol and a normal symbol?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/DscannerThat's a good idea. I have no objections.
Oct 10 2014
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:storage class and as type constructor is much more subtle than in D, but it has critical affects.I can blame C++ for that, because in C++ the difference between const asconst 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 vThat on it's own is fairly difficult to explain.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
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
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: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.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.
Oct 10 2014
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
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: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;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.
Oct 10 2014
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
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/DscannerThis 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
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
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
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
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
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
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
On 10/12/2014 2:14 PM, Sean Kelly wrote:On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote: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.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.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
On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d wrote:On 10/10/14 11:15 AM, Martin Nowak wrote: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 DavisAs 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/DscannerThis 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.
Oct 10 2014
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
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
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
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
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
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:Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.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() { ... }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.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 12 2014
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:Not necessarily. `pure` is a real function attribute, while `const` applies to the implicit `this` paramater and _not_ to the function.On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.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() { ... }
Oct 12 2014
On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.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
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:I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.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
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
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:Yes, you are right. Mea culpa, I misinterpreted. OTOH, there is some cleaning needed, I think, complex types being prime example.I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos...
Oct 13 2014
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
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: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.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
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: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.On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:Not good. If LHS function attributes are to be deprecated, it really ought to be all or nothing.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() { ... }
Oct 13 2014
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
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:No, look at the pointer symbol.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;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.Agreed with the sentiment.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.#pleasebreakourcodeLol.
Oct 11 2014
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote: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?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.
Oct 11 2014
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:The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.module test; const int** a; const(int**) b;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.**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
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: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.On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.module test; const int** a; const(int**) b;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.
Oct 11 2014
On 10/11/2014 11:17 PM, Dicebot wrote:On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:As far as I understand, this is a compiler implementation detail.On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote: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.On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:The original code you quoted was "const(T)* v;" where the "*" was *outside* of the parens.module test; const int** a; const(int**) b;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.
Oct 12 2014
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, +1I 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.+1 over all Plus, I would not spend anymore one world in arguing against the reddit argumentation: it's really too much for me. --- /PaoloThis 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 11 2014
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:#pleasebreakourcodeNo, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Oct 11 2014
On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote:On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:It does not sound as catchy :P Though I agree in statement itself#pleasebreakourcodeNo, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Oct 11 2014
On 10/11/2014 3:18 AM, bachmeier via Digitalmars-d wrote:On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: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.#pleasebreakourcodeNo, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Oct 11 2014
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). ... #pleasebreakourcodeYou 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
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
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: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 :)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.
Oct 13 2014
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
"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
On Tuesday, 14 October 2014 at 16:11:34 UTC, Daniel Murphy wrote:"John Colvin" wrote in message news:ljjtmnnckwzenvhawawx forum.dlang.org...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.[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.Yes, that's a more concrete example, thanks.
Oct 14 2014
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/4043I 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
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
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
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 toreach out for more people to discuss it's tradeoffs.It's about deprecating function qualifiers on the left hand side of afunction.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 tothe 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/4043You 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
"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
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
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
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: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.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
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
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
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
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
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:gtfo ketmarThen 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?
Oct 11 2014
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:gtfo ketmar gtfoOn Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:gtfo ketmarThen 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?
Oct 11 2014
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
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
Jonathan M Davis:and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it isConsistency 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
On Sat, 11 Oct 2014 22:41:50 +0000 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:Jonathan M Davis: =20and 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.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
Oct 11 2014
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
On Sunday, October 12, 2014 21:17:29 Martin Nowak 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 DavisThis 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
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.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.it's for a practice that we've already been discouraging for some time nowNever 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
On Sunday, 12 October 2014 at 23:25:57 UTC, Martin Nowak wrote: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".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.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.
Oct 13 2014
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 DavisThe right path forward seems to be deprecating now, but not removing before dfix can do something good about it.
Oct 13 2014
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
"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
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
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
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:NoWould this affect your code?Better. More clearDo you think it makes your code better or worse?NoIs this just a pointless style change?
Oct 18 2014
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 change make you to write more code in D?Would this affect your code?Probably, but I have no D code of any size to care about.
Oct 19 2014
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:No. The blockers for me are: 1- We're not likely to use D here at work any time soon. We're writing 2- For my own projects I typically write windows GUI programs and D is no 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/On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> wrote:Would this change make you to write more code in D?Would this affect your code?Probably, but I have no D code of any size to care about.
Oct 20 2014