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?

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

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

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".

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.

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

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

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

> 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

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.

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.

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.