www.digitalmars.com         C & C++   DMDScript  

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

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

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

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

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

https://github.com/D-Programming-Language/dmd/pull/4043
Oct 09 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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

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

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

 Would this affect your code?


No. D-Scanner's style checker yells at you when you try to do 
this, so I've fixed all my personal code already. These checks 
run as part of the CI process at EMSI and the results are 
uploaded to our local SonarQube server. We shouldn't have any 
uses of the to-be-removed syntax hiding in our code.


 Do you think it makes your code better or worse?


Better. Explaining why "const int foo" is "const(int)" and "const 
int foo();" is "int" is not something I enjoy doing.


 Is this just a pointless style change?


No.


 Anything else?


This will be moderately difficult to imlement in dfix.
Oct 09 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Kenji just proposed a slightly controversial pull request so I want
 to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a=20
 function.
=20
 So instead of
      const int foo();
 you'd should write
      int foo() const;
=20
 Then at some future point we could apply the left hand side
 qualifiers to the return type, e.g. `const int foo();` =3D=3D `const(int)
 foo();`
=20
 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?
=20
 https://github.com/D-Programming-Language/dmd/pull/4043


i'm all for this. prefix function attributes are *VERY* confusing. i
think this patch should be accepted as soon as possible. i'm already
enjoying it. ;-)
Oct 09 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 9 Oct 2014 12:04:36 +0300
ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

i mean there were occasional discussions in NG about irritating
"'const int bar();' is not 'const(int) bar();'" and i've seen nobody
defending prefix attributes. it was either "i don't care" or "it's
annoying".
Oct 09 2014
prev sibling next sibling parent reply "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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


I'm all for it


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


I know it's not happening anytime soon, but I'm against this 
second idea. This will be an extra annoyance when "porting" old D 
code to a new version. Just removing the currently ambiguous 
attribute on the left should be plenty. No need to try to mimic C 
in this regard.
Oct 09 2014
parent Lionello Lunesu <lionello lunesu.remove.com> writes:
On 09/10/14 17:32, francesco cattoglio wrote:

 On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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


 I'm all for it


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


 I know it's not happening anytime soon, but I'm against this second
 idea. This will be an extra annoyance when "porting" old D code to a new
 version. Just removing the currently ambiguous attribute on the left
 should be plenty. No need to try to mimic C in this regard.


+1
Oct 13 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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

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

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

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

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


Yes, yes, yes YES ! YYYEEEEEESSSSSS !
Oct 09 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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

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

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

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

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


I'm for going ahead with that.
---
/Paolo
Oct 09 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:


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

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


+1 from me.



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


In this case I think it's better to focus on the most important 
thing first.

Bye,
bearophile
Oct 09 2014
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak <code dawg.eu>:



 Would this affect your code?


Most old code, yes. I used to write all attributes on the left hand
side, but switched to right hand side some time ago. 


 Do you think it makes your code better or worse?


Probably better, although I tried to be careful with the left hand side
attributes so it shouldn't change to much.


 Is this just a pointless style change?
 Anything else?


Code will probably look nicer, but I'm not sure if it's consistent.
with const(int) it's obvious that the return value is const. With
const int abcd()  safe
this might be less obvious.

Also fixing old code manually would be very tedious.
Oct 09 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 9 Oct 2014 12:27:11 +0200
schrieb Johannes Pfau <nospam example.com>:


 Am Thu, 09 Oct 2014 10:50:44 +0200
 schrieb Martin Nowak <code dawg.eu>:
 
 

 Would this affect your code?


 Most old code, yes. I used to write all attributes on the left hand
 side, but switched to right hand side some time ago. 
 

 Do you think it makes your code better or worse?


 Probably better, although I tried to be careful with the left hand
 side attributes so it shouldn't change to much.
 

 Is this just a pointless style change?
 Anything else?


 Code will probably look nicer, but I'm not sure if it's consistent.
 with const(int) it's obvious that the return value is const. With
 const int abcd()  safe
 this might be less obvious.
 
 Also fixing old code manually would be very tedious.
 


Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
Oct 09 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:

 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)


I said that I wouldn't write dfix until Walter was willing to 
start getting rid of old syntax. Not long after that Walter made 
this https://github.com/D-Programming-Language/dmd/pull/4021

dfix is under development. You can find it here: 
https://github.com/Hackerpilot/dfix
Oct 09 2014
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/09/2014 01:10 PM, Brian Schott wrote:

 dfix is under development. You can find it here:
 https://github.com/Hackerpilot/dfix


That would make such decisions much easier :).
It doesn't appear to rewrite AST but only tokens at the moment.
How reliable is it?
Oct 09 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 9 October 2014 at 11:31:01 UTC, Martin Nowak wrote:

 It doesn't appear to rewrite AST but only tokens at the moment.


The features that are implemented so far don't need the AST. 
Others such as the function attributes and C-style arrays will 
need help from the parser.


 How reliable is it?


About four and a half. Maybe five.
Oct 09 2014
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 9 October 2014 at 11:10:47 UTC, Brian Schott wrote:

 On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau 
 wrote:

 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)


 I said that I wouldn't write dfix until Walter was willing to 
 start getting rid of old syntax. Not long after that Walter 
 made this 
 https://github.com/D-Programming-Language/dmd/pull/4021

 dfix is under development. You can find it here: 
 https://github.com/Hackerpilot/dfix


This is great news.  Even if it's not going to be packaged with 
the official compiler releases, perhaps you can start off by 
making it available on dub for any breaking syntax changes in 
dmd, such as ditching the old C-style array declaration syntax, 
so we can point users who hit it at dfix.

As for moving function attributes from the left to the right, I'm 
all for it.  I was frequently confused by what applied to what 
and picking through and figuring it out was unnecessary mental 
overhead.
Oct 09 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/9/2014 4:10 AM, Brian Schott wrote:

 On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:

 Forgot to some overall I'm for this change. I'd just like some
 automated way to fix old code ;-)


 I said that I wouldn't write dfix until Walter was willing to start getting rid
 of old syntax. Not long after that Walter made this
 https://github.com/D-Programming-Language/dmd/pull/4021

 dfix is under development. You can find it here:
 https://github.com/Hackerpilot/dfix



dfix will be a welcome addition. Glad you're working on it!
Oct 09 2014
prev sibling next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 Kenji just proposed a slightly controversial pull request so I want
 to reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a 
 function.
 
 So instead of
      const int foo();
 you'd should write
      int foo() const;
 
 Then at some future point we could apply the left hand side
 qualifiers to the return type, e.g. `const int foo();` == `const(int)
 foo();`
 
 Would this affect your code?


Yes (but I am ok with that)


 Do you think it makes your code better or worse?


Definitely better


 Is this just a pointless style change?


No


 Anything else?


Merge this ASAP, please :)
Oct 09 2014
prev sibling next sibling parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:>

 Would this affect your code?


no

 Do you think it makes your code better or worse?


no change, my code already looks like that


 Is this just a pointless style change?


no, left hand side function qualifier is just wrong IMO.


 Anything else?


Thank you guys
Oct 09 2014
parent "Sag Academy" <sagacademyjaipur gmail.com> writes:
On Thursday, 9 October 2014 at 11:24:08 UTC, Robert burner
Schadek wrote:

 On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak 
 wrote:>

 Would this affect your code?


 no

 Do you think it makes your code better or worse?


 no change, my code already looks like that


 Is this just a pointless style change?


 no, left hand side function qualifier is just wrong IMO.


 Anything else?


 Thank you guys


mostly welcome
Oct 09 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

 Would this affect your code?


I've written code before in the style:
 property pure nothrow const //<- HERE
int foo();

So anybody else using this style might be affected.

But even then, I agree. D has always been about "if it's 
ambiguous, dangerous, and can be avoided, don't make it fucking 
legal".


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


I'm not really sure about the: "Then at some future point we 
could apply the left hand side qualifiers to the return type, 
e.g. `const int foo();` ==  `const(int) foo();`"

I don't think it buys us anything, except maybe silently changing 
semantics of code that hibernated through the deprecation process.

I mean, sure, it might be a little surprising, but it's not the 
end of the world.
Oct 09 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 09/10/14 13:38, monarch_dodra via Digitalmars-d wrote:

 I'm not really sure about the: "Then at some future point we could apply the
 left hand side qualifiers to the return type, e.g. `const int foo();` ==
 `const(int) foo();`"

 I don't think it buys us anything, except maybe silently changing semantics of
 code that hibernated through the deprecation process.


Besides,

     const int foo() const
     {
         ...
     }

is fairly ambiguous syntax to my eyes.

     const(int) foo() const
     {
         ...
     }

is less so.
Oct 09 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 October 2014 at 22:29:32 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:

 On 09/10/14 13:38, monarch_dodra via Digitalmars-d wrote:

 I'm not really sure about the: "Then at some future point we 
 could apply the
 left hand side qualifiers to the return type, e.g. `const int 
 foo();` ==
 `const(int) foo();`"

 I don't think it buys us anything, except maybe silently 
 changing semantics of
 code that hibernated through the deprecation process.


 Besides,

     const int foo() const
     {
         ...
     }

 is fairly ambiguous syntax to my eyes.

     const(int) foo() const
     {
         ...
     }

 is less so.


Also

const int delegate() const dg;

Is dg const or the return type ?
Oct 09 2014
prev sibling next sibling parent "Dominikus Dittes Scherkl" writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

 Would this affect your code?


No, I always wrote it on the right.


 Do you think it makes your code better or worse?


Better.


 Is this just a pointless style change?


No, removing confusing style is good.
Oct 09 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
This pull request is a good thing (TM). +1 all the way.

Atila

On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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

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

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

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

 https://github.com/D-Programming-Language/dmd/pull/4043
Oct 09 2014
prev sibling next sibling parent =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d writes:
Dne 9.10.2014 v 10:50 Martin Nowak via Digitalmars-d napsal(a):

 Would this affect your code?


yes, but I understand the rationale so I don't mind


 Do you think it makes your code better or worse?


less ambiguous, so I would say better


 Is this just a pointless style change?


no

--
Martin
Oct 09 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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

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


Finally.


 Would this affect your code?


Yes, eventually, but I am willing to make the change and it is 
trivial compared to some other D2 migration related things :)


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


I believe it is much less error-prone, prefix notation is 
currently a common cause of mis-interpretation from the reader.
Oct 09 2014
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/14 4:50 AM, Martin Nowak wrote:

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

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

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

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

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


First, I'm all for the change. If it affects my code, I don't care, I'll 
fix it.

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

const {
    int foo();
}

const:
    int foo();

I'm not sure I agree with the future plan to allow const on the lhs to 
apply to the return type, but we can decide that in the future.

-Steve
Oct 09 2014
parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2014-10-09 23:17 GMT+09:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d puremagic.com>:


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

 const {
    int foo();
 }

 const:
    int foo();


My PR still allows those block or label style attributes.

Kenji Hara
Oct 09 2014
prev sibling next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
It's a clean break and easy to fix, and eliminated a confusing 
ambiguity. I'm all for it.
Oct 09 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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


+1.

Prefixed const is so often a mistaken attempt to return a const 
that when I see someone post for help in IRC about "cannot 
implicitly convert expression" I immediately look for a "this" in 
the error message because that usually means they are using 
prefixed const function attribute when they intended to return a 
const variable.

This reminds me quite a bit about Walter's explanation on FLOSS 
Weekly about why D disallows shadowing local variables. It can be 
used correctly just fine but it's so often used incorrectly that 
we're better off disallowing it completely.
Oct 09 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, October 09, 2014 10:50:44 Martin Nowak via Digitalmars-d wrote:

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

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

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

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

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


Well, since I'm the one who created the enhancement request that this is for,
I'm obviously for it. It's a change that's long past due. Allowing them on the
left only causes trouble - both in terms of bugs and confusion - and I think
that most of us would agree that it's already considered good practice to
stick them on the right rather than the left. Allowing them on the left has no
real benefit IMHO beyond avoiding code breakage, and the fix for that  is
trivial.

- Jonathan M Davis
Oct 09 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

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


Great. I support this.
Oct 09 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
 Would this affect your code?


No, but is it fixed on the ddoc side?  The last ddoc I generated had function 
attributes first, even though in the code they were on the right.  It would be 
pretty awful to have function attributes obliged to be on the right in code,
but 
still appearing on the left in documentation.


 Do you think it makes your code better or worse?


I like the style, and it certainly helps to avoid the confusion with C/C++'s 
const interpretation.


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




I like this idea less.  const(int) is explicit in a way that const int isn't.


 Anything else?


I'm not sure whether I care to _enforce_ this style rather than strongly 
encourage it, as it's a breaking change.  I'd rather deprecation of 
left-hand-side attributes, rather than illegality, if that is possible.
Oct 09 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/9/2014 1:50 AM, Martin Nowak wrote:

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


This has come up before, and has been debated at length.

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

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

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

In particular,

    const T *v;

does not mean:

    const(T)* v;

For functions, const-as-storage-class applies to the function symbol. And if it 
is misused, the compiler will very likely complain about a mismatched type.
Breaking this adds a special case inconsistency, besides breaking existing code.

(I understand that there's a lot of advocacy lately about "break my code", but 
I'm the one who bears the brunt of "you guys broke my code again, even though 
the code was correct and worked perfectly well! D sux.", besides, of course, 
those poor souls who have to go fix their code base, and I hear again about how 
D is unstable, another Reddit flame-fest about D being unsuitable because the 
designers can't make up their mind, etc.)

This endless search for the ideal syntax is consuming our time while we aren't 
working on issues that matter. (And this change will consume users' time, too, 
not just ours.)

If we're going to break things, it needs to be for something that matters. This 
doesn't make the cut.
Oct 09 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 For functions, const-as-storage-class applies to the function 
 symbol. And if it is misused, the compiler will very likely 
 complain about a mismatched type.
 Breaking this adds a special case inconsistency, besides 
 breaking existing code.


Come on that is the same bogus reason every time. const here do 
not apply to the function but to its hidden, implicit parameter. 
And that is actually a problem.

const void delegate() dg; // dg should be const, and there is no 
way to qualify the implicit parameter.

You obviously can't pretend you don't know this as:
const int foo() {}

Gives you an error because you have no this pointer to make 
const. So let's not pretend that this const actually qualify the 
function when everybody knows it doesn't.
Oct 09 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 09 Oct 2014 19:37:31 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 If we're going to break things, it needs to be for something that
 matters. This doesn't make the cut.


ah, again...

people: yes, yes, we WANT it, let's break our code and do it!
Walter: ha, shut up! this doesn't matter at all, we will not break the
code for this!
people: aaaargh! (--motivation, ++frustration)

i myself don't like this game enough to participate. there is no sense
in both implementing something and discussing something. small fixes
will be rejected due to being small, big fixes will be rejected due to
being big. and medium fixes will be rejected due to being too big for
small and too small for big. this game has no way to win.

so at least nobody will read any more rants from me about
inconsistencies in D. still a win.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
Digitalmars-d wrote:

 On Thu, 09 Oct 2014 19:37:31 -0700
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 If we're going to break things, it needs to be for something 
 that
 matters. This doesn't make the cut.


 ah, again...

 people: yes, yes, we WANT it, let's break our code and do it!
 Walter: ha, shut up! this doesn't matter at all, we will not 
 break the
 code for this!
 people: aaaargh! (--motivation, ++frustration)

 i myself don't like this game enough to participate. there is 
 no sense
 in both implementing something and discussing something. small 
 fixes
 will be rejected due to being small, big fixes will be rejected 
 due to
 being big. and medium fixes will be rejected due to being too 
 big for
 small and too small for big. this game has no way to win.

 so at least nobody will read any more rants from me about
 inconsistencies in D. still a win.


yoooohoooo!

wait.... why are you still posting? gtfo
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:10:06 UTC, market wrote:

 On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
 Digitalmars-d wrote:

 On Thu, 09 Oct 2014 19:37:31 -0700





 wait.... why are you still posting? gtfo


That kind of attitude does not help much.
Oct 10 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 15:10:05 +0000
market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 wait.... why are you still posting?


can't see any technical discussion here. and can't see me ranting about
inconsistencies in D. and can't see where i wrote that i will not rant
about attitude.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 16:44:23 UTC, ketmar via
Digitalmars-d wrote:

 On Fri, 10 Oct 2014 15:10:05 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 wait.... why are you still posting?


 can't see any technical discussion here. and can't see me 
 ranting about
 inconsistencies in D. and can't see where i wrote that i will 
 not rant
 about attitude.


please just go. please
Oct 10 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 18:14:28 +0000
market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 please just go. please


(smiles) you are funny.
Oct 10 2014
parent reply "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Digitalmars-d wrote:

 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 please just go. please


 (smiles) you are funny.


you are not. gtfo ketmar
Oct 10 2014
parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:

 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:

 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 please just go. please


 (smiles) you are funny.


 you are not. gtfo ketmar


Market, I can't tell if you're joking or not.  Either way, time for it 
to stop.
Oct 10 2014
next sibling parent "market" <dont spam.me> writes:
On Friday, 10 October 2014 at 20:26:23 UTC, Brad Roberts via
Digitalmars-d wrote:

 On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:

 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:

 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 please just go. please


 (smiles) you are funny.


 you are not. gtfo ketmar


 Market, I can't tell if you're joking or not.  Either way, time 
 for it to stop.


I am not joking! ketmar is becoming the D resident troll. And
does nothing for D aside spewing shit. ketmar must gtfo.
Oct 10 2014
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/10/14 4:25 PM, Brad Roberts via Digitalmars-d wrote:

 On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:

 On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
 Digitalmars-d wrote:

 On Fri, 10 Oct 2014 18:14:28 +0000
 market via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 please just go. please


 (smiles) you are funny.


 you are not. gtfo ketmar


 Market, I can't tell if you're joking or not.  Either way, time for it
 to stop.


Don't feed the troll, let market go away on his own.

-Steve
Oct 10 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 If we're going to break things, it needs to be for something 
 that matters. This doesn't make the cut.


I think you are wrong. This seems a worthy little breaking change.

Bye,
bearophile
Oct 10 2014
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/14 10:37 PM, Walter Bright wrote:


 For functions, const-as-storage-class applies to the function symbol.
 And if it is misused, the compiler will very likely complain about a
 mismatched type.


Can you demonstrate this? I hate to see D reject a unanimously wanted 
improvement on something that is "likely" but not defined.


 Breaking this adds a special case inconsistency, besides breaking
 existing code.


Just like if(x); is rejected inconsistently. The point is, it's WORTH 
having the inconsistency to avoid the issues that come with it.


 (I understand that there's a lot of advocacy lately about "break my
 code", but I'm the one who bears the brunt of "you guys broke my code
 again, even though the code was correct and worked perfectly well! D
 sux.", besides, of course, those poor souls who have to go fix their
 code base, and I hear again about how D is unstable, another Reddit
 flame-fest about D being unsuitable because the designers can't make up
 their mind, etc.)


You need to grow a thicker skin on Reddit I think.


 This endless search for the ideal syntax is consuming our time while we
 aren't working on issues that matter. (And this change will consume
 users' time, too, not just ours.)


This is not a new problem, not a crazy novel syntax, and the time 
consumed is already taken (PR already exists). Every time I turn around, 
someone on D is complaining that "we" shouldn't spend time doing this or 
that. But "we" are all volunteers, and while it's nice to have 
direction, if someone wants to work on something, I don't want to say 
"you can't do that, please work on X instead." It doesn't help, it 
doesn't motivate.

Really, what you are saying here is, the unanimous opinion of the 
die-hard very dedicated D community is worthless compared to the opinion 
of a hypothetical Reddit user.

-Steve
Oct 10 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 Really, what you are saying here is, the unanimous opinion of the=20
 die-hard very dedicated D community is worthless compared to the
 opinion of a hypothetical Reddit user.


second-class citizens will not run away. existing D users are
second-class citizens.
Oct 10 2014
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/10/14 9:53 AM, ketmar via Digitalmars-d wrote:

 On Fri, 10 Oct 2014 09:42:14 -0400
 Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
 wrote:


 Really, what you are saying here is, the unanimous opinion of the
 die-hard very dedicated D community is worthless compared to the
 opinion of a hypothetical Reddit user.


 second-class citizens will not run away. existing D users are
 second-class citizens.


They will and have.

-Steve
Oct 10 2014
prev sibling parent "bachmeier" <no spam.com> writes:
On Friday, 10 October 2014 at 13:42:14 UTC, Steven Schveighoffer 
wrote:


 (I understand that there's a lot of advocacy lately about 
 "break my
 code", but I'm the one who bears the brunt of "you guys broke 
 my code
 again, even though the code was correct and worked perfectly 
 well! D
 sux.", besides, of course, those poor souls who have to go fix 
 their
 code base, and I hear again about how D is unstable, another 
 Reddit
 flame-fest about D being unsuitable because the designers 
 can't make up
 their mind, etc.)


 You need to grow a thicker skin on Reddit I think.


Or read the many Reddit comments about how C++ syntax and gotchas 
suck and make everyone want to avoid the language. "There are 
only two kinds of languages: the ones people complain about and 
the ones nobody uses" is not a joke. This is no way to design a 
language.

And for all the supposed concern about breaking code, the most 
recent compiler was released with a bunch of regressions. Those 
are the code breakages that show up on Reddit, not minor changes 
that went through a proper deprecation cycle.
Oct 10 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 On 10/9/2014 1:50 AM, Martin Nowak wrote:

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


 This has come up before, and has been debated at length.

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

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

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

 In particular,

    const T *v;

 does not mean:

    const(T)* v;

 For functions, const-as-storage-class applies to the function 
 symbol. And if it is misused, the compiler will very likely 
 complain about a mismatched type.
 Breaking this adds a special case inconsistency, besides 
 breaking existing code.

 (I understand that there's a lot of advocacy lately about 
 "break my code", but I'm the one who bears the brunt of "you 
 guys broke my code again, even though the code was correct and 
 worked perfectly well! D sux.", besides, of course, those poor 
 souls who have to go fix their code base, and I hear again 
 about how D is unstable, another Reddit flame-fest about D 
 being unsuitable because the designers can't make up their 
 mind, etc.)


None of those professional complainers matter though. They'll 
always find *something* to complain about.

This is an excellent example of a breaking change that pays for 
itself within weeks. A large codebase can be converted over very 
quickly, without any thought required.
It has the *immediate* benefit that the coding style improves. It 
has the longer term benefit of removing a lot of confusion.


 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this change 
 will consume users' time, too, not just ours.)

 If we're going to break things, it needs to be for something 
 that matters. This doesn't make the cut.


No. It's a removal of one of those little friction points, that 
hurts everyone very slightly, all the time. One less thing to 
worry about, one less thing to explain, one less thing to be 
confused by.
If you have an organisation with 50 people, every one of them 
benefits slightly. In aggregate, that's a big deal.
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:13:16 UTC, Don wrote:

 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 On 10/9/2014 1:50 AM, Martin Nowak wrote:





 No. It's a removal of one of those little friction points, that 
 hurts everyone very slightly, all the time.


As, IIRC, Teoh put it once: everywhere you turn, you see 
unfinished things.
Oct 10 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 10, 2014 15:13:15 Don via Digitalmars-d wrote:

 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 (I understand that there's a lot of advocacy lately about
 "break my code", but I'm the one who bears the brunt of "you
 guys broke my code again, even though the code was correct and
 worked perfectly well! D sux.", besides, of course, those poor
 souls who have to go fix their code base, and I hear again
 about how D is unstable, another Reddit flame-fest about D
 being unsuitable because the designers can't make up their
 mind, etc.)


 None of those professional complainers matter though. They'll
 always find *something* to complain about.

 This is an excellent example of a breaking change that pays for
 itself within weeks. A large codebase can be converted over very
 quickly, without any thought required.
 It has the *immediate* benefit that the coding style improves. It
 has the longer term benefit of removing a lot of confusion.


Exactly!


 This endless search for the ideal syntax is consuming our time
 while we aren't working on issues that matter. (And this change
 will consume users' time, too, not just ours.)

 If we're going to break things, it needs to be for something
 that matters. This doesn't make the cut.


 No. It's a removal of one of those little friction points, that
 hurts everyone very slightly, all the time. One less thing to
 worry about, one less thing to explain, one less thing to be
 confused by.
 If you have an organisation with 50 people, every one of them
 benefits slightly. In aggregate, that's a big deal.


+1

- Jonathan M Davis
Oct 10 2014
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 10/10/2014 04:37 AM, Walter Bright wrote:

 On 10/9/2014 1:50 AM, Martin Nowak wrote:

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


 This has come up before, and has been debated at length.

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

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

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


That on it's own is fairly difficult to explain.


 For functions, const-as-storage-class applies to the function symbol.


What's the difference between a const symbol and a normal symbol?


 This endless search for the ideal syntax is consuming our time while we
 aren't working on issues that matter. (And this change will consume
 users' time, too, not just ours.)


Sure, programmers are obsessed with syntax discussion. Think of all the 
future time that is wasted discussing whether const on a function should 
be left or right.


 If we're going to break things, it needs to be for something that
 matters. This doesn't make the cut.


There are 3591 open issues in bugzilla and hundreds of ideas floating 
around. So there will always be a lot of unplanned things happening in 
parallel. I do agree that we should handle such proposals early on 
through DIPs rather than stopping finished work in a pull request.

We don't want to break code, but discourage the usage of LHS function 
qualifiers because they are confusing.
As this is more about stating a clear preference than deprecating the 
old syntax let me propose a compromise.

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

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

- leave the rest to linting tools like 
https://github.com/Hackerpilot/Dscanner
Oct 10 2014
next sibling parent "eles" <eles eles.com> writes:
On Friday, 10 October 2014 at 15:15:13 UTC, Martin Nowak wrote:

 On 10/10/2014 04:37 AM, Walter Bright wrote:

 On 10/9/2014 1:50 AM, Martin Nowak wrote:





 - leave the rest to linting tools like 
 https://github.com/Hackerpilot/Dscanner


I don't like it. If it is not in the language, then why bother 
with Dscanner?

C++ has a lot of lint tools. How many of them the average Joe use?

Either is in the language, either you can never give a * about it.

Why to default to a lint tool just as a lame excuse for not 
getting the language right in the first place?

PS I know it's not because of you.
Oct 10 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 8:15 AM, Martin Nowak wrote:

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

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

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


 That on it's own is fairly difficult to explain.


I can blame C++ for that, because in C++ the difference between const as
storage 
class and as type constructor is much more subtle than in D, but it has
critical 
affects.

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

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

     static T v;

? I don't think so.



 For functions, const-as-storage-class applies to the function symbol.


 What's the difference between a const symbol and a normal symbol?


A const field member, for example, didn't contribute to the size of the struct.



 We don't want to break code, but discourage the usage of LHS function
qualifiers
 because they are confusing.
 As this is more about stating a clear preference than deprecating the old
syntax
 let me propose a compromise.

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

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

 - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner


That's a good idea. I have no objections.
Oct 10 2014
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10 Oct 2014 17:35, "Walter Bright via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 10/10/2014 8:15 AM, Martin Nowak wrote:

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

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

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



 That on it's own is fairly difficult to explain.



 I can blame C++ for that, because in C++ the difference between const as


storage class and as type constructor is much more subtle than in D, but it
has critical affects.


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


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

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

     static T v;

 ? I don't think so.


Equally, static does not have a double-meaning.

Iain.



 Oct 10 2014



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:

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


I meant when perceptions about what something means are carried over from one 
language to another.



 Equally, static does not have a double-meaning.


static famously in C++ has multiple meanings :-) and does so in D as well.

Overloading keywords with more than one meaning is common practice and isn't 
necessarily bad in a programming language. In D, we overload 'this' with at 
least 3 distinct meanings.



 Oct 10 2014



 next sibling parent  "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com>  writes:


On Friday, 10 October 2014 at 20:51:53 UTC, Walter Bright wrote:

 On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:

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


 I meant when perceptions about what something means are carried 
 over from one language to another.


Yeah, but you asked for it by deliberately making D C-like. Being 
alike, but different is more confusing than just being different, 
e.g.:

"qualifier symbol : type;" would probably have been more 
intuitive.



 Oct 10 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 10 Oct 2014 13:51:54 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Overloading keywords with more than one meaning is common practice
 and isn't necessarily bad in a programming language. In D, we
 overload 'this' with at least 3 distinct meanings.


and 'enum' too.



 Oct 10 2014



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10 October 2014 21:51, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 10/10/2014 10:31 AM, Iain Buclaw via Digitalmars-d wrote:

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



 I meant when perceptions about what something means are carried over from
 one language to another.



 Equally, static does not have a double-meaning.



 static famously in C++ has multiple meanings :-) and does so in D as well.


I meant in the sense that it has a consistent meaning on its own,
there is no difference between the following declarations.

static int foo;
static int foo() { };
struct S { static int foo; }
struct S { static int foo() { } }


And it does not take much to explain the difference between static
alone versus static when paired with a second keyword.

static this() { }
static ~this() { }
static assert() { }
static if() { }
static import foo;



 Oct 10 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-10-10 19:31, Iain Buclaw via Digitalmars-d wrote:


 Equally, static does not have a double-meaning.


"static" is the most overloaded keyword there is ;)

-- 
/Jacob Carlborg



 Oct 10 2014



prev sibling  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 10/10/14 11:15 AM, Martin Nowak wrote:


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

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

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

 - leave the rest to linting tools like
 https://github.com/Hackerpilot/Dscanner


This is a case of the compiler doing the *wrong* thing when requested to 
do something else.

When I say:

const int
foo() { return 1;}

I mean I want foo to return a const int. The compiler does the *wrong* 
thing, and instead applies const to the hidden this parameter.

In most cases, the result is a confusing error message, because most of 
the time, it won't compile. But in some cases, it will compile and do 
something completely incorrect.

This is not a problem of specification, this is a problem of human 
semantics. The specification is sound, correct, and completely confusing 
to real people.

To avoid the confusion, we put the const on the right side. While not 
*completely* intuitive, it's much clearer what const applies to.

I think leaving this to a lint tool basically is as good and effective 
as doing nothing. It's not a compromise at all.

-Steve



 Oct 10 2014



 next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 10 Oct 2014 13:52:30 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 I think leaving this to a lint tool basically is as good and
 effective as doing nothing.


this *IS* doing nothing, from any POV.



 Oct 10 2014



prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Friday, 10 October 2014 at 17:52:30 UTC, Steven Schveighoffer 
wrote:

 I think leaving this to a lint tool basically is as good and 
 effective as doing nothing. It's not a compromise at all.


I agree. The only people who run lint tools are established users 
(because they are the only ones who even know they exist). 
Established users are already well aware of how to use function 
attributes correctly (and for the most part did left-hand 
attributes in old code written before the informal convention 
came about).

left-hand const is primarily a problem for new users of the 
language (particularly the large amount coming from C++). These 
users aren't running linters, they are still just trying to get 
basic projects off the ground. This issue is one of the top 
things I see new users have problems with in the D IRC channel. 
You can find new users having problems with it on Stack Overflow 
too.



 Oct 10 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/10/2014 11:11 AM, Brad Anderson wrote:

 left-hand const is primarily a problem for new users of the language
 (particularly the large amount coming from C++). These users aren't running
 linters, they are still just trying to get basic projects off the ground. This
 issue is one of the top things I see new users have problems with in the D IRC
 channel. You can find new users having problems with it on Stack Overflow too.


Const works differently in D than in C++, and this doesn't change that. First
off,

     const int foo();

returning const(int) is pointless. More likely, someone coming from C++ might
write:

     const T *foo(); // in C++ returns pointer to const T

expecting it to be:

     const(T)* foo();  // D way to return pointer to const T

and:

     const T *p;  // C++: pointer to const char
                  // D: const pointer to const char

which means different things in C++ and D. Fortunately, nearly all these issues 
quickly run afoul of the compiler's type checker, and can be as quickly 
corrected. C++ doesn't have a notion of transitive const, so the C++ syntax 
cannot be generally applied and have it mean the same thing.

At some point, the new D user needs to spend a bit of time learning the const 
system and unlearning the C++ one.



 Oct 10 2014



  parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Friday, 10 October 2014 at 21:10:14 UTC, Walter Bright wrote:

 Const works differently in D than in C++, and this doesn't 
 change that. First off,


I think it's rather unfortunate that D used keywords from C++ for 
things that work differently. const in particular but struct and 
class cause confusion and bickering too. Think of all the hours 
spent on this newsgroup arguing about logical const. If D's const 
were called something else like readonly nobody would be trying 
to shoehorn logical const into it and calls for logical const 
would have been discussed without having to pit two features 
against each other for a single spot in the language.

Another is char for utf-8 code units. So many people assume a 
char is a character when it's actually only sometimes a character 
by coincidence. If it had a different name like utf8_unit people 
would probably write more unicode correct code naturally.



 Oct 10 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/10/2014 4:04 PM, Brad Anderson wrote:

 I think it's rather unfortunate that D used keywords from C++ for things that
 work differently. const in particular but struct and class cause confusion and
 bickering too. Think of all the hours spent on this newsgroup arguing about
 logical const. If D's const were called something else like readonly nobody
 would be trying to shoehorn logical const into it and calls for logical const
 would have been discussed without having to pit two features against each other
 for a single spot in the language.


These kinds of problems always occur when transitioning from one language to 
another. I'm not trying to be dismissive, but I feel that a language has to
pick 
its battles.

BTW, C++ const constantly causes confusion even for experienced C++ programmers.



 Another is char for utf-8 code units. So many people assume a char is a
 character when it's actually only sometimes a character by coincidence. If it
 had a different name like utf8_unit people would probably write more unicode
 correct code naturally.


C++ has the same problem, only far worse, since char is used for all kinds of 
multibyte characters, and most legacy/library code assumes ASCII. Java has the 
same issue (surrogate pairs).

There are other issues:

1. integers overflow
2. floating point numbers have precision problems

Programming languages are always imperfect models, it's like the 2x4's you buy 
at the hardware store are never straight. You just learn to deal with it, 
because perfectly straight ones would be prohibitively expensive.



 Oct 12 2014



  parent reply "Sean Kelly" <sean invisibleduck.org>  writes:


On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:

 Programming languages are always imperfect models, it's like 
 the 2x4's you buy at the hardware store are never straight. You 
 just learn to deal with it, because perfectly straight ones 
 would be prohibitively expensive.


Well... some of them are straight.  If you're building something 
that's built from near full-length boards then you search for the 
straight ones.  Otherwise you just take whatever.  In fact, the 
last time I was sifting through 2x4s at Home Depot, one of the 
people working there asked me to set the warped ones aside so 
they could take them out.  I'm sure they chip them and make 
press-board or whatever out of them instead.

The other tricky thing about selecting 2x4s is that once you get 
to the center of the palette the boards tend to be damp, and so 
there's a chance that they'll be straight when you buy them but 
they'll warp as they dry.  There's kind of an art to selecting 
wood for a building project.

So I guess the point is that you use the proper materials for the 
job.  With physical jobs, the leftovers can almost always be 
repurposed or remade into something suitable for a different job. 
  So there's very little actual waste.  Competent builders can 
even use salvaged materials to create an entirely new thing.  I 
have a set of record shelves that are built from salvaged deck 
beams.  Aged wood tends to be really beautiful because colors and 
textures emerge as it ages.

What I've learned about building is that, just like programming, 
there's an established process for everything.  And building new 
structures is largely a matter of assembling the pieces and 
joining them in the proscribed manner.  So you quickly start 
thinking about projects in terms of the larger problem rather 
than the complexity of constructing an individual wall section or 
whatever.



 Oct 12 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 10/12/2014 2:14 PM, Sean Kelly wrote:

 On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:

 Programming languages are always imperfect models, it's like the 2x4's you buy
 at the hardware store are never straight. You just learn to deal with it,
 because perfectly straight ones would be prohibitively expensive.


 Well... some of them are straight.  If you're building something that's built
 from near full-length boards then you search for the straight ones.  Otherwise
 you just take whatever.  In fact, the last time I was sifting through 2x4s at
 Home Depot, one of the people working there asked me to set the warped ones
 aside so they could take them out.  I'm sure they chip them and make
press-board
 or whatever out of them instead.


It turns out that a lot of them can be bent straight if put in a structure in 
the right way. For example, triangular bracing can pull them in line. The more 
warped ones can be used for shorter sections. It's all about compensating for 
the imperfections, and a good carpenter can do that.



 So I guess the point is that you use the proper materials for the job.  With
 physical jobs, the leftovers can almost always be repurposed or remade into
 something suitable for a different job.  So there's very little actual waste.
 Competent builders can even use salvaged materials to create an entirely new
 thing.  I have a set of record shelves that are built from salvaged deck beams.
 Aged wood tends to be really beautiful because colors and textures emerge as it
 ages.


No doubt. People like salvaged wood so much they'll beat a brand new wood floor 
with chains. And, of course, people buy brand new jeans that are beaten with 
stones and deliberately ripped up.



 Oct 12 2014



prev sibling next sibling parent  Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d 
wrote:

 On 10/10/14 11:15 AM, Martin Nowak wrote:

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

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

    with an explanation what the storage class function thing does

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

 - leave the rest to linting tools like
 https://github.com/Hackerpilot/Dscanner


 This is a case of the compiler doing the *wrong* thing when requested to
 do something else.

 When I say:

 const int
 foo() { return 1;}

 I mean I want foo to return a const int. The compiler does the *wrong*
 thing, and instead applies const to the hidden this parameter.

 In most cases, the result is a confusing error message, because most of
 the time, it won't compile. But in some cases, it will compile and do
 something completely incorrect.

 This is not a problem of specification, this is a problem of human
 semantics. The specification is sound, correct, and completely confusing
 to real people.

 To avoid the confusion, we put the const on the right side. While not
 *completely* intuitive, it's much clearer what const applies to.

 I think leaving this to a lint tool basically is as good and effective
 as doing nothing. It's not a compromise at all.


Agreed.

Leaving this as-is in the language has almost no benefit. The only benefit is
to avoid having to make minor changes to any code which puts the const on the
left. But there's a definite cost in confusion and developer time. We've
already been telling people for ages to put const on the right whenever it
comes up, because putting it on the left is too confusing, and questions about
it keep popping up. There is a long term cost to allowing const on the left
and only a small, short term cost to deprecating it. This is one of those
cases where focusing on not breaking code definitely costs us more than making
the change, especially when we're going to be doing via the proper deprecation
mechanism and not by just changing it and breaking existing code.

- Jonathan M Davis



 Oct 10 2014



prev sibling  parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 10/10/2014 07:52 PM, Steven Schveighoffer wrote:

 I think leaving this to a lint tool basically is as good and effective
 as doing nothing. It's not a compromise at all.


So the goal is more to help D beginners who would add a const to the 
return type
     const int foo();
thinking it will work like
     const int x;
rather than to improve readability.

It still makes a lot sense to update all our documentation and the style 
guide. Any volunteer for the latter?

Let's talk to Brian whether dfix would be able to do the rewrite 
automatically.
https://github.com/Hackerpilot/dfix/issues/1



 Oct 10 2014



prev sibling next sibling parent reply "Yota" <yotaxp thatGoogleMailThing.com>  writes:


On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

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

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

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

 In particular,

    const T *v;

 does not mean:

    const(T)* v;


Once again, I am thoroughly confused as to why the space is put 
before the * in a language where the * is associated with the 
type, and not the identifier.  If it had been written like

const T* v;

Then it would be obvious that it means

const(T*) v;

At which point I ask, why word it such that 'const' affects the 
symbol v, and not the type T*?  And why does the former syntax 
even exist if it is more proper to use the latter?



 Oct 10 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 10/10/2014 9:28 AM, Yota wrote:

 Once again, I am thoroughly confused as to why the space is put before the * in
 a language where the * is associated with the type, and not the identifier.


In C, you can declare multiple variables like this:

     T *p, *q;

both are pointer to T. This is why conventionally the * gets put next to the 
symbol name. Such split up declarations aren't allowed in D, so conventionally 
the * gets put next to the type, as in:

     T* p, q;



 At which point I ask, why word it such that 'const' affects the symbol v, and
 not the type T*?  And why does the former syntax even exist if it is more
proper
 to use the latter?


const as storage class is useful for doing things like putting data into a read 
only segment.

The const(T) type constructor syntax is to emphasize that const in D is 
transitive, i.e. it affects everything inside the ( ). This is not true of
const 
in C++, which when used as a type constructor is left-associative, unless it is 
on the left when it becomes right-associative, which I find terribly confusing.



 Oct 10 2014



prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10/10/14 04:37, Walter Bright via Digitalmars-d wrote:

 If we're going to break things, it needs to be for something that matters. This
 doesn't make the cut.


I agree with that general sentiment, but doesn't this patch only deprecate 
left-hand-side function attributes?

I don't particularly mind you refusing it, but deprecation (in support of good 
stylistic practice) isn't breaking.



 Oct 10 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:

 I agree with that general sentiment, but doesn't this patch only deprecate
 left-hand-side function attributes?


Only some of them, others remain:

     pure int foo() { ... }


 I don't particularly mind you refusing it, but deprecation (in support of good
 stylistic practice) isn't breaking.


Deprecation means it'll be removed.



 Oct 11 2014



  parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:

 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:

 I agree with that general sentiment, but doesn't this patch only deprecate
 left-hand-side function attributes?


 Only some of them, others remain:

      pure int foo() { ... }


Not good.  If LHS function attributes are to be deprecated, it really ought to 
be all or nothing.


 I don't particularly mind you refusing it, but deprecation (in support of good
 stylistic practice) isn't breaking.


 Deprecation means it'll be removed.


Hmm, maybe I've misunderstood the deprecation process.  It was my understanding 
that, to remove a feature or function, it was necessary to deprecate it first; 
but that deprecation would not necessarily always lead to deletion.

I may be thinking too specifically of Phobos, where it's obviously much easier 
to deprecate a module without ever removing it.



 Oct 12 2014



 next sibling parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:

 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:

 I agree with that general sentiment, but doesn't this patch 
 only deprecate
 left-hand-side function attributes?


 Only some of them, others remain:

     pure int foo() { ... }


 Not good.  If LHS function attributes are to be deprecated, it 
 really ought to be all or nothing.


Not necessarily. `pure` is a real function attribute, while 
`const` applies to the implicit `this` paramater and _not_ to the 
function.



 Oct 12 2014



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:

 Deprecation means it'll be removed.


 Hmm, maybe I've misunderstood the deprecation process.  It was my understanding
 that, to remove a feature or function, it was necessary to deprecate it first;
 but that deprecation would not necessarily always lead to deletion.

 I may be thinking too specifically of Phobos, where it's obviously much easier
 to deprecate a module without ever removing it.


Deprecation is a way station on the way to removal. Warnings are not
necessarily 
headed that way.



 Oct 12 2014



 next sibling parent reply "eles" <eles215 gzk.dot>  writes:


On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:

 On 10/12/2014 2:28 AM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:

 Deprecation means it'll be removed.


 Hmm, maybe I've misunderstood the deprecation process.  It was 
 my understanding
 that, to remove a feature or function, it was necessary to 
 deprecate it first;
 but that deprecation would not necessarily always lead to 
 deletion.

 I may be thinking too specifically of Phobos, where it's 
 obviously much easier
 to deprecate a module without ever removing it.


 Deprecation is a way station on the way to removal. Warnings 
 are not necessarily headed that way.


I beg forgiveness, but I think it was a timid suggestion to clean 
up a bit Phobos...



 Oct 12 2014



  parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:

 I beg forgiveness, but I think it was a timid suggestion to 
 clean up a bit Phobos...


No.

I actually think it's a very good thing that it's possible to 
preserve old, obsolete modules in Phobos.  As long as everything 
is covered in a strict deprecation warning to let everyone 
understand it is obsolete, it's better to keep the code there for 
backwards compatibility than gratuitously remove it, because of 
the risks of breakage to old codebases.

For the same reason, I'm happy to see LHS attributes be 
deprecated, but not for support for them to be removed.



 Oct 13 2014



  parent  "eles" <eles eles.com>  writes:


On Monday, 13 October 2014 at 15:58:05 UTC, Joseph Rushton 
Wakeling wrote:

 On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote:

 I beg forgiveness, but I think it was a timid suggestion to 
 clean up a bit Phobos...




  Yes, you are right. Mea culpa, I misinterpreted.

  OTOH, there is some cleaning needed, I think, complex types 
being prime example.



 Oct 13 2014



prev sibling  parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:

 Deprecation is a way station on the way to removal. Warnings 
 are not necessarily headed that way.


Indeed, but the choice of _when_ to remove can in practice be 
quite free, no?  It would be possible to put in place this 
deprecation warning and wait for years before acting on it.



 Oct 13 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 13 October 2014 at 16:00:21 UTC, Joseph Rushton 
Wakeling wrote:

 On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:

 Deprecation is a way station on the way to removal. Warnings 
 are not necessarily headed that way.


 Indeed, but the choice of _when_ to remove can in practice be 
 quite free, no?  It would be possible to put in place this 
 deprecation warning and wait for years before acting on it.


This is one thing I'd love major versions to be used for. 
Deprecate bunch of things iteratively, remove them completely in 
D 3.xx.yy ; aggregate bunch of new deprecated things and release 
D 4.xx.yy etc.



 Oct 13 2014



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:

 On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:

 On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via 
 Digitalmars-d wrote:

 I agree with that general sentiment, but doesn't this patch 
 only deprecate
 left-hand-side function attributes?


 Only some of them, others remain:

     pure int foo() { ... }


 Not good.  If LHS function attributes are to be deprecated, it 
 really ought to be all or nothing.


No. Let me explain. In
qualifier(type) identifier();
qualifier apply to type. This is all good, as expected.

In
attribute type identifier();

attribute apply to identifier. identifier is a function here, and
it make sense to apply pure on a function.

The problem with type qualifier on a function, is that they do
not make any sense. For some reason, a type qualifier used on a
function will qualify the implicit parameter.

It is confusing the hell out of everybody as there is a thing on
which is make sense to apply the qualifier to (the return type)
and a thing where it does not make sense (the function) but for
some reason, when you apply it on the function it has a "magic"
meaning. That is the surprise effect.



 Oct 13 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 This has come up before, and has been debated at length.

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

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

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

 In particular,

    const T *v;

 does not mean:

    const(T)* v;


Wait what? Are you saying there is a single case when this:

const T var;

is not identical to this:

const(T) var;

???

I see no point in saying const storage class exists in D2 because 
there is no way to observe it because of transitivity of const 
qualifier.


 (I understand that there's a lot of advocacy lately about 
 "break my code", but I'm the one who bears the brunt of "you 
 guys broke my code again, even though the code was correct and 
 worked perfectly well! D sux.", besides, of course, those poor 
 souls who have to go fix their code base, and I hear again 
 about how D is unstable, another Reddit flame-fest about D 
 being unsuitable because the designers can't make up their 
 mind, etc.)


Reddit users are not the ones who invest into this language. If 
this attitude won't change it is only a matter of time until you 
start losing existing corporate users deciding to go with other 
language or a fork instead (likely latter).

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

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

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


 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this change 
 will consume users' time, too, not just ours.)


Hardly anything matters more than that. Issues like that consume 
our time continiously for years, accumulating in wasted days 
weeks of worker time. Compared with time needed to adjust even 
several MLOC project gain is clear.

#pleasebreakourcode



 Oct 10 2014



 next sibling parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 This has come up before, and has been debated at length.

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

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

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

 In particular,

   const T *v;

 does not mean:

   const(T)* v;


 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;


No, look at the pointer symbol.


 Reddit users are not the ones who invest into this language. If 
 this attitude won't change it is only a matter of time until 
 you start losing existing corporate users deciding to go with 
 other language or a fork instead (likely latter).

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

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

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


 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this 
 change will consume users' time, too, not just ours.)


 Hardly anything matters more than that. Issues like that 
 consume our time continiously for years, accumulating in wasted 
 days weeks of worker time. Compared with time needed to adjust 
 even several MLOC project gain is clear.


Agreed with the sentiment.


 #pleasebreakourcode


Lol.



 Oct 11 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:

 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;


 No, look at the pointer symbol.


module test;

const int**  a;
const(int**) b;

**a = 42;
Error: cannot modify const expression **a

0000000000000000 B _D4test1axPPi
0000000000000008 B _D4test1bxPPi

???

Can you give an examle of the code that actually observes the 
semantical difference?



 Oct 11 2014



  parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:

 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra 
 wrote:

 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;


 No, look at the pointer symbol.


 module test;

 const int**  a;
 const(int**) b;


The original code you quoted was "const(T)* v;" where the "*" was 
*outside* of the parens.


 **a = 42;
 Error: cannot modify const expression **a

 0000000000000000 B _D4test1axPPi
 0000000000000008 B _D4test1bxPPi

 ???

 Can you give an examle of the code that actually observes the 
 semantical difference?


I cannot. I was trying to prove that there isn't, after you made 
the statement "Wait what? Are you saying there is a single case 
when this is not identical to this".



 Oct 11 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:

 On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:

 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra 
 wrote:

 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;


 No, look at the pointer symbol.


 module test;

 const int**  a;
 const(int**) b;


 The original code you quoted was "const(T)* v;" where the "*" 
 was *outside* of the parens.


There was no * in my quote, only `const(T)` vs `const T` (with 
any compound T)

The fact that const T* means const(T*) does not indicate that 
const is a storage class but simply a parsing rule. Walter has 
made a statement that there is a const storage class that is 
distinct from const qualified. I want example.



 Oct 11 2014



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 10/11/2014 11:17 PM, Dicebot wrote:

 On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote:

 On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote:

 On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:

 Wait what? Are you saying there is a single case when this:

 const T var;

 is not identical to this:

 const(T) var;


 No, look at the pointer symbol.


 module test;

 const int**  a;
 const(int**) b;


 The original code you quoted was "const(T)* v;" where the "*" was
 *outside* of the parens.


 There was no * in my quote, only `const(T)` vs `const T` (with any
 compound T)

 The fact that const T* means const(T*) does not indicate that const is a
 storage class but simply a parsing rule. Walter has made a statement
 that there is a const storage class that is distinct from const
 qualified. I want example.


As far as I understand, this is a compiler implementation detail.



 Oct 12 2014



prev sibling next sibling parent  "Paolo Invernizzi" <paolo.invernizzi no.address>  writes:


On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

 On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:

 Reddit users are not the ones who invest into this language. If 
 this attitude won't change it is only a matter of time until 
 you start losing existing corporate users deciding to go with 
 other language or a fork instead (likely latter).


Sadly, +1


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

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

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


 This endless search for the ideal syntax is consuming our time 
 while we aren't working on issues that matter. (And this 
 change will consume users' time, too, not just ours.)


 Hardly anything matters more than that. Issues like that 
 consume our time continiously for years, accumulating in wasted 
 days weeks of worker time. Compared with time needed to adjust 
 even several MLOC project gain is clear.

 #pleasebreakourcode


+1 over all

Plus, I would not spend anymore one world in arguing against the 
reddit argumentation: it's really too much for me.

---
/Paolo



 Oct 11 2014



prev sibling next sibling parent reply "bachmeier" <no spam.net>  writes:


On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:


 #pleasebreakourcode


No, it's #pleasedeprecateourcode

For a change like this, with proper deprecation, there will be no 
broken code.



 Oct 11 2014



 next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote:

 On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:


 #pleasebreakourcode


 No, it's #pleasedeprecateourcode

 For a change like this, with proper deprecation, there will be 
 no broken code.


It does not sound as catchy :P Though I agree in statement itself



 Oct 11 2014



prev sibling  parent  Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10/11/2014 3:18 AM, bachmeier via Digitalmars-d wrote:

 On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:


 #pleasebreakourcode


 No, it's #pleasedeprecateourcode

 For a change like this, with proper deprecation, there will be no broken
 code.


Yes, there will be.  That there's a period of transition helps reduce 
it, but to believe that all code everywhere is upgraded during that 
transition is... wishful thinking.

That said, I'm still in favor of this change.  Please, remove the human 
confusion, there's enough of it already and this one is easy to fix.



 Oct 11 2014



prev sibling next sibling parent  Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 11/10/14 06:11, Dicebot via Digitalmars-d wrote:

 Reddit users are not the ones who invest into this language. If this attitude
 won't change it is only a matter of time until you start losing existing
 corporate users deciding to go with other language or a fork instead (likely
 latter).

 ...

 #pleasebreakourcode


You propose ignoring Teh Internetz and try to enlist a Twitter hashtag to that 
end? ;-)



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

 ...

 Hardly anything matters more than that. Issues like that consume our time
 continiously for years, accumulating in wasted days weeks of worker time.
 Compared with time needed to adjust even several MLOC project gain is clear.


I don't think this message can be over-emphasized enough.  By far the major 
difficulty of programming effectively (in any circumstances, but particularly
in 
a corporate environment) is having to deal with quirks and special cases in a 
language and its libraries where "the right thing" and "the obvious thing"
diverge.

Such quirks don't just lead to more frequent programmer error, they also lead
to 
uglier and less easily maintained codebases, which almost always has a 
multiplicative effect in terms of the overall quirkiness the developer has to 
deal with.  It's a LOT of lost time.

By contrast, when a language and/or library successfully conflates "the easy 
thing" and "the right thing", the effect is multiplicative in the other 
direction -- as a programmer, it helps you learn and implement good design 
patterns that carry all the way up the software stack.  I'm firmly of the
belief 
that D's successes in this respect not only made it easier for me to program, 
they made me a better programmer.

D2 is, for the most part, excellent in this respect, but it could and should be 
even better.  Well-managed, well-documented and well-publicized breaking
changes 
in support of usability and correctness are desirable, not something to be
avoided.



 Oct 12 2014



prev sibling  parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d wrote:

 D2 is, for the most part, excellent in this respect, but it could and should be
 even better.  Well-managed, well-documented and well-publicized breaking
changes
 in support of usability and correctness are desirable, not something to be
avoided.


I should add here -- I recognize the basic problem that faces any language when 
you have newcomers (or potential corporate adopters) downloading the latest 
compiler, downloading some codebase of interest to them, and finding that it 
doesn't build because of a backwards-incompatible change.  Even when that
change 
was 100% justified, you risk being seen as unstable, untrustworthy, etc., and 
many people are not patient enough to stick around to hear that justification.

Now, that said, I think it's helpful to try and change the conversation from, 
"Break/don't break" to, "What would be the circumstances under which it could
be 
feasible to make these desirable breaking changes?"

The original version of this email had some thoughts on that, but to be honest, 
I'd rather just ask the question, without making any assumptions about what the 
answer could or should be.



 Oct 12 2014



  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d 
 wrote:

 D2 is, for the most part, excellent in this respect, but it 
 could and should be
 even better.  Well-managed, well-documented and 
 well-publicized breaking changes
 in support of usability and correctness are desirable, not 
 something to be avoided.


 I should add here -- I recognize the basic problem that faces 
 any language when you have newcomers (or potential corporate 
 adopters) downloading the latest compiler, downloading some 
 codebase of interest to them, and finding that it doesn't build 
 because of a backwards-incompatible change.  Even when that 
 change was 100% justified, you risk being seen as unstable, 
 untrustworthy, etc., and many people are not patient enough to 
 stick around to hear that justification.


I used to think that this was a valid point w.r.t. rejecting 
changes. Over the last year of actually trying to get work done 
in D, I've changed my tune somewhat:

At this stage, almost every release will break any project that 
has a decent sized code-base, *without considering any language 
changes or regressions*!

Fixing *any* rejects-valid or accepts-invalid bug can break 
peoples code.[1]
Adding a new symbol in phobos can break peoples code.

The only way of getting meaningful stability is to slow down a 
lot. If we're going to keep moving fast (even just fixing bugs), 
then it is unavoidable that we will break people's code. We can 
afford a little more breakage on top of the inevitable (and 
undeniably necessary) pile - even for quite minor gains - as long 
as they are changes that can be easily managed by project 
maintainers.[2]


The only argument that's left is: "I don't mind you breaking my 
code by fixing bugs in the implementation, but I do mind when 
it's for cleaning/changing the language/phobos". In light of 
recent comments from heavyweight users saying "please break my 
code in the name of improving the language and libraries", I 
don't think it holds much water.

[1] The "code that was already broken" is often dodgy. What 
constitutes broken code? There's a lot of very fragile code out 
there that is doing it's job just fine, in the limited 
circumstances it's used.

[2] By easily managed I don't mean sed-able, or even 
tooling-fixable. For me it pivots on being able to maintain one 
code-base that will compile with multiple compiler versions. An 
example where this fails:  nogc, being an attribute, isn't 
aliasable, meaning you can't version it out neatly.

#PleaseBreakMyCode but also 
#PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWit
AVarietyOfCompilers 
    Hmm, not so catchy :)



 Oct 13 2014



 next sibling parent  "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Monday, 13 October 2014 at 17:15:34 UTC, John Colvin wrote:

 The only argument that's left is: "I don't mind you breaking my 
 code by fixing bugs in the implementation, but I do mind when 
 it's for cleaning/changing the language/phobos". In light of 
 recent comments from heavyweight users saying "please break my 
 code in the name of improving the language and libraries", I 
 don't think it holds much water.


Well, in this case we don't necessarily need to break anyone's 
code, it would be possible to stop at deprecation.

But generally speaking, I agree with you, which is why I was 
hoping to move the debate to, "What are the circumstances under 
which these breaks are possible," rather than "Should 
we/shouldn't we".



 Oct 13 2014



prev sibling  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"John Colvin"  wrote in message news:ljjtmnnckwzenvhawawx forum.dlang.org...


 [2] By easily managed I don't mean sed-able, or even tooling-fixable. For 
 me it pivots on being able to maintain one code-base that will compile 
 with multiple compiler versions. An example where this fails:  nogc, being 
 an attribute, isn't aliasable, meaning you can't version it out neatly.


There is nothing stopping you from not supporting  nogc until your oldest 
supported dmd version has it.  I agree with your requirement, but this is 
not a good example of it.  A better example would be requiring nothrow 
annotations on inline asm blocks, because the old code won't compile with 
newer dmds and the new code won't compile with older ones. 



 Oct 14 2014



  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Tuesday, 14 October 2014 at 16:11:34 UTC, Daniel Murphy wrote:

 "John Colvin"  wrote in message 
 news:ljjtmnnckwzenvhawawx forum.dlang.org...


 [2] By easily managed I don't mean sed-able, or even 
 tooling-fixable. For me it pivots on being able to maintain 
 one code-base that will compile with multiple compiler 
 versions. An example where this fails:  nogc, being an 
 attribute, isn't aliasable, meaning you can't version it out 
 neatly.


 There is nothing stopping you from not supporting  nogc until 
 your oldest supported dmd version has it.


Good point.

It would be nice to be able to take advantage of new features 
though, whilst maintaining backward compatibility. Also, a 3rd 
party project could make  nogc a requirement, meaning I have to 
choose between compatibility with older compilers or with that 
3rd party code. Alias-able attributes would help a lot.


 I agree with your requirement, but this is not a good example 
 of it.  A better example would be requiring nothrow annotations 
 on inline asm blocks, because the old code won't compile with 
 newer dmds and the new code won't compile with older ones.


Yes, that's a more concrete example, thanks.



 Oct 14 2014



prev sibling next sibling parent  Marco Leise <Marco.Leise gmx.de>  writes:


Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak <code dawg.eu>:


 Kenji just proposed a slightly controversial pull request so I want to 
 reach out for more people to discuss it's tradeoffs.
 It's about deprecating function qualifiers on the left hand side of a 
 function.
 
 So instead of
      const int foo();
 you'd should write
      int foo() const;
 
 Then at some future point we could apply the left hand side qualifiers 
 to the return type, e.g. `const int foo();` == `const(int) foo();`
 
 Would this affect your code?
 Do you think it makes your code better or worse?
 Is this just a pointless style change?
 Anything else?
 
 https://github.com/D-Programming-Language/dmd/pull/4043


I write my function signatures like this now and I'm fine with
the change:

 safe pure nothrow  nogc [<1]
final override  property ref [<2] int foo() shared const [<3]
{
   ...
}

[1] Attributes that hint the compiler by narrowing down
    allowed language features.
[2] Visibility and behavioral attributes.
[3] Modifiers for implicit `this`.

-- 
Marco



 Oct 10 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 10 Oct 2014 00:25:07 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 I'm not sure whether I care to _enforce_ this style rather than
 strongly encourage it, as it's a breaking change.  I'd rather
 deprecation of left-hand-side attributes, rather than illegality, if
 that is possible.


the patch does exactly that: compiler emits deprecation warnings on
prefix attributes. nobody plans to break things immediately. ;-)



 Oct 10 2014



prev sibling next sibling parent  "Wyatt" <wyatt.epp gmail.com>  writes:


On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

 Would this affect your code?


I'll live.


 Do you think it makes your code better or worse?


On the balance, neither.


 Is this just a pointless style change?


Changes that mitigate patterns of human error are _never_ 
pointless.

-Wyatt



 Oct 10 2014



prev sibling next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 Oct 2014 09:55, "Martin Nowak via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 Kenji just proposed a slightly controversial pull request so I want to


reach out for more people to discuss it's tradeoffs.

 It's about deprecating function qualifiers on the left hand side of a


function.

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

 Then at some future point we could apply the left hand side qualifiers to


the return type, e.g. `const int foo();` == `const(int) foo();`

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

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


You have my full support in this.  What we should first focus on it the
path of least resistance to making this happen.  Preferably sooner rather
than later.

Iain.



 Oct 10 2014



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Martin Nowak"  wrote in message news:m15i9c$51b$1 digitalmars.com...


      const int foo();


The existing behavior would be great to have if we were deliberately trying 
to trip up all programmers coming from C++.  Kill it with fire. 



 Oct 10 2014



  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 11 Oct 2014 05:19:05 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 The existing behavior would be great to have if we were deliberately
 trying to trip up all programmers coming from C++.


suddenly, i starting to believe that we should not deprecate prefix
attributes...



 Oct 10 2014



prev sibling next sibling parent  Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10/10/14 09:45, ketmar via Digitalmars-d wrote:

 the patch does exactly that: compiler emits deprecation warnings on
 prefix attributes. nobody plans to break things immediately. ;-)


It's not the "immediately" I'm worried about, it's the "eventually".



 Oct 10 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 11 Oct 2014 00:49:14 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 On 10/10/14 09:45, ketmar via Digitalmars-d wrote:

 the patch does exactly that: compiler emits deprecation warnings on
 prefix attributes. nobody plans to break things immediately. ;-)


 It's not the "immediately" I'm worried about, it's the "eventually".


i can't see why we should keep the syntax that nobody likes. this will
just confuse newcomers. that was the argument against adding " " to
"nothrow" and "pure" (and keeping the old syntax simultaneously). if it
works there, it should work here too.



 Oct 10 2014



prev sibling next sibling parent  Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 11/10/14 00:58, ketmar via Digitalmars-d wrote:

 i can't see why we should keep the syntax that nobody likes. this will
 just confuse newcomers. that was the argument against adding " " to
 "nothrow" and "pure" (and keeping the old syntax simultaneously). if it
 works there, it should work here too.


I don't mind deprecating the syntax that nobody likes.  I mind the idea of 
removing it, because has the potential to break old code for no particularly 
good reason.

BTW I repeat, as far as I can tell, Ddoc will always place the attributes on
the 
left of the function.  That needs to be fixed if the proposed patch is to go 
through.



 Oct 10 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 11 Oct 2014 01:13:51 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>
wrote:


 I don't mind deprecating the syntax that nobody likes.  I mind the
 idea of removing it, because has the potential to break old code for
 no particularly good reason.


there is good reason: this syntax is confusing. if it will stay as
deprecated, newcomers will have just one more question: "why it's still
here?"

and about breaking old code. if this code is so old that nobody will
fix it... well, one can use old compiler to build that code. but that
code rot many years ago anyway: it's unmaintained. it *will* break
sooner or later, there is no sane reason to trying to keep zombie
alive, zombies must be destroyed.



 Oct 10 2014



prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


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

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

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

Then we might revisit the topic in 6 month and see whether we have 
better arguments now.



 Oct 11 2014



 next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 11 Oct 2014 14:47:55 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Then we might revisit the topic in 6 month and see whether we have=20
 better arguments now.


six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok,
at least reddit users will be happy. they will, aren't they?



 Oct 11 2014



  parent reply "ketmar gtfo" <dont spam.me>  writes:


On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
Digitalmars-d wrote:

 On Sat, 11 Oct 2014 14:47:55 +0200
 Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.


 six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably 
 not... ok,
 at least reddit users will be happy. they will, aren't they?


gtfo ketmar



 Oct 11 2014



  parent  "ketmar gtfo gtfo" <jsutarandominboxforastupidjoke gmail.com>  writes:


On Saturday, 11 October 2014 at 15:17:36 UTC, ketmar gtfo wrote:

 On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via
 Digitalmars-d wrote:

 On Sat, 11 Oct 2014 14:47:55 +0200
 Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.


 six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably 
 not... ok,
 at least reddit users will be happy. they will, aren't they?


 gtfo ketmar


gtfo ketmar gtfo



 Oct 11 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Saturday, 11 October 2014 at 12:48:03 UTC, Martin Nowak wrote:

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

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

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

 Then we might revisit the topic in 6 month and see whether we 
 have better arguments now.


Sounds good but what is the benefit over just having deprecation 
period 6 months longer?



 Oct 11 2014



prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Saturday, October 11, 2014 14:47:55 Martin Nowak via Digitalmars-d wrote:

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

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

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

 Then we might revisit the topic in 6 month and see whether we have
 better arguments now.


This has been being brought up for years. I wouldn't expect 6 months to change
anything. If we want to delay it until dmd's headergen and ddoc are fixed and
put a note in the changelog on the next release that it's going to be
deprecated rather than deprecating it immediately, we can do that, but I don't
think for a second that the arguments are going to change. Many of us have
been complaining about this for years, and it's primarily been Walter who
hasn't wanted it on the grounds that it's more consistent as it is (which I
strongly dispute). As far as I can tell, Walter is the only real obstacle to
this. Almost no one else ever seems to think that having const function
modifiers on the left is a good idea. And now that someone has finally
implemented the change, I really think that we need to get it merged.

Honestly, I think that delaying making the change just increases how much harm
the problem is causing, because it's around that much longer, confusing that
many more folks. As far as popular opinion goes, it's quite clear that almost
everyone posting here thinks that it should be changed. The only one who seems
to really need to be convinced is Walter, and apparently, no one knows how to
do that.

I can see delaying making the changes until the dmd headergen is fixed being
needed so that the compiler isn't generating code that it then prints a
deprecation message for, and it would be nice if the ddoc generation were
fixed ASAP as well, but if that's the case, I think that that just means that
those should be fixed ASAP so that const function qualifiers on the left can
be deprecated ASAP. I see no need to continue to discuss whether we should do
this beyond someone miraculously coming up with a way to convince Walter.

- Jonathan M Davis



 Oct 11 2014



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Jonathan M Davis:


 and it's primarily been Walter who hasn't wanted it on the
 grounds that it's more consistent as it is


Consistency is a good thing to have, but if adhering to it causes 
bugs and troubles, and if the symmetry breakage causes readable 
compile-time errors, then it's often a good idea to do it. D 
language contains plenty of situations where this happens (and 
arguably few more cases should be added, like the sbyte/ubyte 
pair of names breaking the consistency of name/uname naming 
scheme for the other integral types, to avoid people think all 
the time that a byte is unsigned).

Bye,
bearophile



 Oct 11 2014



  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 11 Oct 2014 22:41:50 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jonathan M Davis:
=20

 and it's primarily been Walter who hasn't wanted it on the
 grounds that it's more consistent as it is


=20
 Consistency is a good thing to have


and it's not a goal, it's just a nice way to say "i don't want this".
see " safe", " trusted", "pure" and "nothrow", for example. i can
hardly say that it's consistent. "breaking consistency" rising up only
if there is nothing else to say against something.



 Oct 11 2014



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


 This has been being brought up for years. I wouldn't expect 6 
 months to change
 anything. If we want to delay it until dmd's headergen and ddoc 
 are fixed and
 put a note in the changelog on the next release that it's going 
 to be
 deprecated rather than deprecating it immediately, we can do 
 that, but I don't
 think for a second that the arguments are going to change.


Automatic code rewriting is what might make syntax deprecations 
more feasible in 6 month.



 Oct 12 2014



  parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sunday, October 12, 2014 21:17:29 Martin Nowak via Digitalmars-d wrote:

 This has been being brought up for years. I wouldn't expect 6
 months to change
 anything. If we want to delay it until dmd's headergen and ddoc
 are fixed and
 put a note in the changelog on the next release that it's going
 to be
 deprecated rather than deprecating it immediately, we can do
 that, but I don't
 think for a second that the arguments are going to change.


 Automatic code rewriting is what might make syntax deprecations
 more feasible in 6 month.


Perhaps, but this change is so straightforward that I would expect that even a
very large codebase could be updated in a very short space of time. And since
it'll be generating deprecation messages - not errors - and it's for a
practice that we've already been discouraging for some time now, I don't think
that waiting for dfix buys us much. I totally agree that it would be nice to
have, but I don't see it as a showstopper at all. The only significant problem
I see is dmd's headergen, because if that's putting const on the left, then
it'll generate code that will then be warned about, which would definitely be
bad. The ddoc generation should be fixed to, but that can be done later,
because the semantics won't have changed; it's just that if you do it in your
own code, you'll get a deprecation message.

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

- Jonathan M Davis



 Oct 12 2014



 next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


 Automatic code rewriting is what might make syntax deprecations
 more feasible in 6 month.


 Perhaps, but this change is so straightforward that I would 
 expect that even a
 very large codebase could be updated in a very short space of 
 time.


The main counterargument against this change is that it's yet 
another change that require people to rewrite their code.
Also the pull simply deprecates certain code, but for good 
acceptance we also need to educate D users why we're doing this 
change and must make updating code as painless as possible. A 
tool like dfix will become more important with every line of D 
code that is written. Too often we're only looking at phobos.


 it's for a practice that we've already been discouraging for 
 some time now


Never heard of it before. If this were common knowledge, as in 
every D beginner would stumble over that information, it would 
solve half of the problem.
I'd still welcome if someone updated the style guide.


 I see is dmd's headergen, because if that's putting const on 
 the left, then
 it'll generate code that will then be warned about, which would 
 definitely be
 bad. The ddoc generation should be fixed to, but that can be 
 done later,


Obviously we should fix all of our own code and explain people 
why they should update theirs before we start deprecating it.



 Oct 12 2014



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 12 October 2014 at 23:25:57 UTC, Martin Nowak wrote:

 Automatic code rewriting is what might make syntax 
 deprecations
 more feasible in 6 month.


 Perhaps, but this change is so straightforward that I would 
 expect that even a
 very large codebase could be updated in a very short space of 
 time.


 The main counterargument against this change is that it's yet 
 another change that require people to rewrite their code.
 Also the pull simply deprecates certain code, but for good 
 acceptance we also need to educate D users why we're doing this 
 change and must make updating code as painless as possible. A 
 tool like dfix will become more important with every line of D 
 code that is written. Too often we're only looking at phobos.


I'm sorry, but that won't cut it. People have been asking for
this change since like forever. This whole problem could be gone
by now, and at the time there was no release that won't make you
rewrite your code anyway.

No it is like, "we didn't made the change at the time for bad
reason, and now we don't want to make the change because we made
a bad decision at the time and change is more costly now".



 Oct 13 2014



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 12 October 2014 at 21:51:33 UTC, Jonathan M Davis via
Digitalmars-d wrote:

 Perhaps, but this change is so straightforward that I would 
 expect that even a
 very large codebase could be updated in a very short space of 
 time. And since
 it'll be generating deprecation messages - not errors - and 
 it's for a
 practice that we've already been discouraging for some time 
 now, I don't think
 that waiting for dfix buys us much. I totally agree that it 
 would be nice to
 have, but I don't see it as a showstopper at all. The only 
 significant problem
 I see is dmd's headergen, because if that's putting const on 
 the left, then
 it'll generate code that will then be warned about, which would 
 definitely be
 bad. The ddoc generation should be fixed to, but that can be 
 done later,
 because the semantics won't have changed; it's just that if you 
 do it in your
 own code, you'll get a deprecation message.

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

 - Jonathan M Davis


The right path forward seems to be deprecating now, but not
removing before dfix can do something good about it.



 Oct 13 2014



  parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Monday, October 13, 2014 19:59:13 deadalnix via Digitalmars-d wrote:

 The right path forward seems to be deprecating now, but not
 removing before dfix can do something good about it.


I don't know that we need to wait for dfix, but we never remove deprecated
stuff from the language very quickly anyway. So, I expect that it'll be around
for at least a year or two before we look at actually removing it, so dfix
will presumably be able to take care of it long before we're looking to remove
it anyway.

- Jonathan M Davis



 Oct 13 2014



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.768.1413233509.9932.digitalmars-d puremagic.com...


 I don't know that we need to wait for dfix, but we never remove deprecated
 stuff from the language very quickly anyway. So, I expect that it'll be 
 around
 for at least a year or two before we look at actually removing it, so dfix
 will presumably be able to take care of it long before we're looking to 
 remove
 it anyway.


And even without dfix, non-trivial year-old code rarely compiles with the 
latest frontend. 



 Oct 14 2014



prev sibling  parent  "Regan Heath" <regan netmail.co.nz>  writes:


On Sat, 11 Oct 2014 13:47:55 +0100, Martin Nowak  
<code+news.digitalmars dawg.eu> wrote:


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

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

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

 Then we might revisit the topic in 6 month and see whether we have  
 better arguments now.


+1

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Oct 15 2014



prev sibling  parent reply "Regan Heath" <regan netmail.co.nz>  writes:


On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> wrote:

 Would this affect your code?


Probably, but I have no D code of any size to care about.


 Do you think it makes your code better or worse?


Better.


 Is this just a pointless style change?


Nope.


 Anything else?


Only what you said in summary to this thread (I am waay late to this party)

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Oct 15 2014



 next sibling parent  "HaraldZealot" <harald_zealot tut.by>  writes:


On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:

 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> 
 wrote:

 Would this affect your code?




No

 Do you think it makes your code better or worse?




Better. More clear

 Is this just a pointless style change?




No



 Oct 18 2014



prev sibling  parent reply "eles" <eles215 gzk.dot>  writes:


On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:

 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> 
 wrote:

 Would this affect your code?


 Probably, but I have no D code of any size to care about.


Would this change make you to write more code in D?



 Oct 19 2014



  parent  "Regan Heath" <regan netmail.co.nz>  writes:


On Sun, 19 Oct 2014 10:06:31 +0100, eles <eles215 gzk.dot> wrote:


 On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:

 On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code dawg.eu> wrote:

 Would this affect your code?


 Probably, but I have no D code of any size to care about.


 Would this change make you to write more code in D?


No.  The blockers for me are:

1- We're not likely to use D here at work any time soon.  We're writing  


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/



 Oct 20 2014