On Sat, 11 Oct 2014 01:13:51 +0200
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> I don't mind deprecating the syntax that nobody likes.  I mind the idea of removing it, because has the potential to break old code for no particularly good reason.
there is good reason: this syntax is confusing. if it will stay as deprecated, newcomers will have just one more question: "why it's still here?"

and about breaking old code. if this code is so old that nobody will fix it... well, one can use old compiler to build that code. but that code rot many years ago anyway: it's unmaintained. it *will* break sooner or later, there is no sane reason to trying to keep zombie alive, zombies must be destroyed.

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

Wait what? Are you saying there is a single case when this:

const T var;

is not identical to this:

const(T) var;

???

I see no point in saying const storage class exists in D2 because there is no way to observe it because of transitivity of const qualifier.

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

Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter).

I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it.

Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. @nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language.

In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer.

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

Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear.

#pleasebreakourcode

On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
> On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
>> 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;
>
> Wait what? Are you saying there is a single case when this:
>
> const T var;
>
> is not identical to this:
>
> const(T) var;

No, look at the pointer symbol.

> Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter).
>
> I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it.
>
> Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. @nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language.
>
> In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer.
>
>> 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.)
>
> Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear.

Agreed with the sentiment.

> #pleasebreakourcode

Lol.

On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
> On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
>
> Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter).

Sadly, +1

> I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it.
>
> Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. @nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language.
>
> In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer.
>
>> 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.)
>
> Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear.
>
> #pleasebreakourcode

+1 over all

Plus, I would not spend anymore one world in arguing against the reddit argumentation: it's really too much for me.

---
/Paolo

On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> I agree with that general sentiment, but doesn't this patch only deprecate
> left-hand-side function attributes?

Only some of them, others remain:

    pure int foo() { ... }

> I don't particularly mind you refusing it, but deprecation (in support of good
> stylistic practice) isn't breaking.

Deprecation means it'll be removed.

On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:

> #pleasebreakourcode

No, it's #pleasedeprecateourcode

For a change like this, with proper deprecation, there will be no broken code.

On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote:
> On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
>
>> #pleasebreakourcode
>
> No, it's #pleasedeprecateourcode
>
> For a change like this, with proper deprecation, there will be no broken code.

It does not sound as catchy :P Though I agree in statement itself

On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote:
>> Wait what? Are you saying there is a single case when this:
>>
>> const T var;
>>
>> is not identical to this:
>>
>> const(T) var;
>
> No, look at the pointer symbol.

module test;

const int**  a;
const(int**) b;

**a = 42;
Error: cannot modify const expression **a

0000000000000000 B _D4test1axPPi
0000000000000008 B _D4test1bxPPi

???

Can you give an examle of the code that actually observes the semantical difference?

https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353

There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners.
There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners.

Let's continue with the following steps.
- add RHS/LHS function qualifiers to D's style guide
- change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers)
- help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1)

Then we might revisit the topic in 6 month and see whether we have better arguments now.

On Sat, 11 Oct 2014 14:47:55 +0200
Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Then we might revisit the topic in 6 month and see whether we have better arguments now.
six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they?