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

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

It's a clean break and easy to fix, and eliminated a confusing ambiguity. I'm all for it.

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.

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.

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.

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

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.

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

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.