On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> 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.
second-class citizens will not run away. existing D users are second-class citizens.

On 10/10/14 9:53 AM, ketmar via Digitalmars-d wrote:
> On Fri, 10 Oct 2014 09:42:14 -0400
> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> 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.
> second-class citizens will not run away. existing D users are
> second-class citizens.

They will and have.

-Steve

On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
Digitalmars-d wrote:
> 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.

yoooohoooo!

wait.... why are you still posting? gtfo

On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
> 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.)

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.

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

On 10/10/2014 04:37 AM, Walter Bright wrote:
> 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

That on it's own is fairly difficult to explain.

> For functions, const-as-storage-class applies to the function symbol.

What's the difference between a const symbol and a normal symbol?

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

Sure, programmers are obsessed with syntax discussion. Think of all the future time that is wasted discussing whether const on a function should be left or right.

> If we're going to break things, it needs to be for something that
> matters. This doesn't make the cut.

There are 3591 open issues in bugzilla and hundreds of ideas floating around. So there will always be a lot of unplanned things happening in parallel. I do agree that we should handle such proposals early on through DIPs rather than stopping finished work in a pull request.

We don't want to break code, but discourage the usage of LHS function qualifiers because they are confusing.
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

On Friday, 10 October 2014 at 15:10:06 UTC, market wrote:
> On Friday, 10 October 2014 at 07:53:05 UTC, ketmar via
> Digitalmars-d wrote:
>> On Thu, 09 Oct 2014 19:37:31 -0700

>
> wait.... why are you still posting? gtfo

That kind of attitude does not help much.

On Friday, 10 October 2014 at 15:15:13 UTC, Martin Nowak wrote:
> On 10/10/2014 04:37 AM, Walter Bright wrote:
>> On 10/9/2014 1:50 AM, Martin Nowak wrote:

> - leave the rest to linting tools like https://github.com/Hackerpilot/Dscanner

I don't like it. If it is not in the language, then why bother with Dscanner?

C++ has a lot of lint tools. How many of them the average Joe use?

Either is in the language, either you can never give a * about it.

Why to default to a lint tool just as a lame excuse for not getting the language right in the first place?

PS I know it's not because of you.

On Friday, 10 October 2014 at 15:13:16 UTC, Don wrote:
> On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
>> On 10/9/2014 1:50 AM, Martin Nowak wrote:

> No. It's a removal of one of those little friction points, that hurts everyone very slightly, all the time.

As, IIRC, Teoh put it once: everywhere you turn, you see unfinished things.

On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright 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
>
> In particular,
>
>    const T *v;
>
> does not mean:
>
>    const(T)* v;

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.  If it had been written like

const T* v;

Then it would be obvious that it means

const(T*) v;

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?

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.

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.


>> For functions, const-as-storage-class applies to the function symbol.
>
> What's the difference between a const symbol and a normal symbol?

A const field member, for example, didn't contribute to the size of the struct.


> We don't want to break code, but discourage the usage of LHS function qualifiers
> because they are confusing.
> 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

That's a good idea. I have no objections.