On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:
>> Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.
>
> Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake.
>
> Maintain yer own parse.c like everybody else!!!
>
> That's what ketmar and I do. It is known as Free Software Freedom.

Lol, you guys are hilarious.  There's D1, D2 and now DOla and DKetmar!

On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote:
> For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially.

That explains why new languages make ";" optional, or wait...

Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go?

Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.

On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
> However my complaint is not about the change itself (though I personally
> disagree with Don reasoning in that issue, it is a delicate matter) but about
> the fact that it is again done as a casual PR and our breaking change culture
> does not seem to change : it is still all or nothing approach. No automatic
> migration tools, no easily found rationale / explanation, no posts in D.announce
> - just an ordinary commit. No wonder any of more notable change is considered
> that scary.

I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change.  It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit).

BTW what is @return meant to achieve?  I realize I'm not familiar with this attribute.

On Wednesday, 28 January 2015 at 22:58:02 UTC, Joseph Rushton Wakeling wrote:
> On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
>> However my complaint is not about the change itself (though I personally
>> disagree with Don reasoning in that issue, it is a delicate matter) but about
>> the fact that it is again done as a casual PR and our breaking change culture
>> does not seem to change : it is still all or nothing approach. No automatic
>> migration tools, no easily found rationale / explanation, no posts in D.announce
>> - just an ordinary commit. No wonder any of more notable change is considered
>> that scary.
>
> I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change.  It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit).

I haven't said it is a breaking change on its own - but that doesn't mean it is any considerably better migration-wise.

> BTW what is @return meant to achieve?  I realize I'm not familiar with this attribute.

http://wiki.dlang.org/DIP25

On 2015-01-28 at 23:27, Walter Bright wrote:
> Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program.

I'm quite sure I have read this very same thing not so long ago. :)

On 29/01/15 00:06, Dicebot via Digitalmars-d wrote:
> I haven't said it is a breaking change on its own - but that doesn't mean it is
> any considerably better migration-wise.

Yea, you're right, this isn't about whether the feature is good or not (personally, I find Don's case for it persuasive) -- it's about having a well-signposted procedure for changing the language.

>> BTW what is @return meant to achieve?  I realize I'm not familiar with this
>> attribute.
>
> http://wiki.dlang.org/DIP25

Oh, of course.  Though it feels a bit weird, the possibility to write,

    @safe ref int identity(@return ref int x) { return x; }

On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:

> I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.

yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)

i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.

On Wed, 28 Jan 2015 22:39:01 +0000, Jonathan Marler wrote:

> On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:
>>> Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.
>>
>> Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake.
>>
>> Maintain yer own parse.c like everybody else!!!
>>
>> That's what ketmar and I do. It is known as Free Software Freedom.
> 
> Lol, you guys are hilarious.  There's D1, D2 and now DOla and DKetmar!

not "DKetmar", it's titled "Aliced". ;-)

On 1/28/15 3:14 PM, FG wrote:
> On 2015-01-28 at 23:27, Walter Bright wrote:
>> Good language design has redundancy in it. Often people see the
>> redundancy, and advocate removing it as noise. But the redundancy has
>> a valuable purpose - diagnosing of errors, and offering suggestions
>> for fixing the errors. If there was no redundancy in the language,
>> every random sequence of bytes would be a valid program.
>
> I'm quite sure I have read this very same thing not so long ago. :)

We should add that stuff and what Jonathan wrote to the FAQ on the wiki. -- Andrei

On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
> On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:
>
>> I think a keyword is a keyword is a keyword. If it's a keyword to the
>> right it should be one everywhere. How is somethign that's a built-in
>> attribute one place and an identifier in another not context sensitive.
>
> yep. that is "slave to the machine" approach. i don't really care how
> hard machine should work to understand what i want. ;-)
>
> i.e. i can't see why i have to deal with problems of compiler/tool/editor
> author. it's easy -- at least in this case -- for human to see where
> keywords are keywords. machine can see that too with some analysis. yet
> somehow situation is horribly reversed: instead of machine helping me to
> do what i want, that's me who must obey the machine orders and do the
> work that machine can do for me.

That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer.

I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. Honestly, pretty anything except C# tooling suck in comparison.

The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?