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 ?

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.

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!

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.

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

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

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.

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

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

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