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.

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.

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.

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.

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

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.

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.

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

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

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