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

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.

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

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

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

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.

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.

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.

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

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.