On 2015-01-26 20:50, Walter Bright wrote:

> It's good to have this discussion.
>
> Previously, it's all been advocacy and "break my code" by forcing a
> change from pure => @pure.
>
> Just a few days ago on slashdot, an anonymous D user wrote:
>
>    "A horrible mix of keywords and annotation syntax for function/method
>    attributes ('const', 'pure', and 'nothrow' are all keywords, but
>    '@property', and '@nogc' are annotations)"
>
> for why he won't use D anymore.
>
> Frankly, I think that is a great bikeshedding non-issue that distracts
> us from what is important. I hope that by doing this PR, we can actually
> decide that it isn't worth it, i.e. I'd be happy to get consensus and
> revert it.

How is this change going to help when there's still a bunch of attributes that can not be prefixed with '@', immutable, const, public and so on?

-- 
/Jacob Carlborg

On Tuesday, 27 January 2015 at 09:18:19 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 27 January 2015 at 08:30:46 UTC, Jonathan Marler wrote:
>> People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point.  I'm not sure what I'm doing wrong or how this can be improved.  But this pattern seems to keep happening no matter what topic is discussed.  Not sure how to solve this...I'll think on this tomorrow.
>
> Isn't it more that one or two individuals don't get your point and keep arguing while the others got it?
>
> Anyway, the discussions on the rust dev list appears to be more educated than on the D forums, so maybe the people with a theoretical background gave up on D and was piqued by the potential given by linear typing? I think so... but they might get fed up with it eventually and in the mean time D has the opportunity to get the semantics right...
>
> From a political perspective it is better to leave the syntax as it is until the semantics of the language are frozen. If you keep changing the syntax then people will eventually be fed up with changes and it might be more difficult to push through a full redesign... Which in my opinion is needed.
>
> It is better to stay 25% flawed then eventually clean it up so that it is only 5% flawed, than to go from 25% bad to 20% bad to 15% and then people get fed up with changes and it is frozen at 15% flawed.
>
> The problem in the D community is that there is no planning. Syntax clean up should be a workgroup effort, not a metamorphic mutation process.

Interesting points.  Thanks for the response, it's a relief to hear people making sense :)

On Tue, 27 Jan 2015 11:20:41 +0100, Jacob Carlborg wrote:

> On 2015-01-26 20:50, Walter Bright wrote:
> 
>> It's good to have this discussion.
>>
>> Previously, it's all been advocacy and "break my code" by forcing a change from pure => @pure.
>>
>> Just a few days ago on slashdot, an anonymous D user wrote:
>>
>>    "A horrible mix of keywords and annotation syntax for
>>    function/method attributes ('const', 'pure', and 'nothrow' are all
>>    keywords, but '@property', and '@nogc' are annotations)"
>>
>> for why he won't use D anymore.
>>
>> Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.
> 
> How is this change going to help when there's still a bunch of attributes that can not be prefixed with '@', immutable, const, public and so on?

who cares? it's SLASHDOT USER! i doubt that he wrote anything except "helloworld" in D, but it's SLASHDOT USER! reddit and slashdot users are first-class citizens for D, and actual D users are of no importance.

On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:

> Interesting points.  Thanks for the response, it's a relief to hear people making sense :)

the funny thing is that Ola is a kind of "bad child" too. heh.

On 2015-01-27 04:54, Zach the Mystic wrote:

> It's only creepy if it doesn't work. And the compiler doesn't need to
> change the code itself - it merely needs to tell you exactly what to do
> to fix it.
>
> I've thought about this some more. The way I would do it is have the
> compiler store all files which need to be fixed. Output the list in
> another file of a different type. Have dfix be able to read that file
> and automatically fix all files listed. Or just generate a D script to
> do just that (no need for a whole different file format. Literally just
> output "dfix.d", which has all the filenames built right into the
> script, and tell the user to 'dmd -run dfix.d'. Now you have a very
> clear intermediate step between compilation and user-activated step.

Seems overly complicated. How about the compiler just outputs new files instead.

-- 
/Jacob Carlborg

On Tuesday, 27 January 2015 at 10:26:54 UTC, ketmar wrote:
> On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:
>
>> Interesting points.  Thanks for the response, it's a relief to hear
>> people making sense :)
>
> the funny thing is that Ola is a kind of "bad child" too. heh.

Hey, I have gray hairs in my beard! Show me sum respect, huh?

I was a silent D forum lurker for... 7 years or so, waiting for a mature C++ replacement. Then decided to jump in and push for more planning and GC free programming support. We have @nogc now, which is good, but that is about it.

A simple statement like "D syntax will be reworked in 2016, lets form a working group" and "we need to define goals for GC, let us form a working group" would go a long way. But that would mean giving up control. Which Andrei and Walter are not going to do, so that means capable people will keep sitting on the fence (who wants to waste their time to have their efforts vetoed?)

What is unfortunate is that the D heads keep adding features faster then the old ones can be fixed... Recently STL compatibility became an official goal and C++ exceptions... I say no more than this: I cant think of a single C++ library I would link to that would require that.

With an orderly executed plan and feature freeze D could be production ready in 2-3 years. With no plan... multiply by at least 3, so we have 6-9 more years to wait assuming the feature set now is frozen...

Nice, I have to go back to C++ now... C ya.

On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Grøstad wrote:

> Hey, I have gray hairs in my beard!
me too!

On 1/27/2015 2:14 AM, Jacob Carlborg wrote:
> You have complained that one of your old D1 projects didn't compile with the
> latest D2 compiler. How would you expect that to still compile when making
> changes like this and without those things Dicebot mentioned.

This change didn't break a single line in the libraries or the test suite.

On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
> You're right. I forgot about those two. But it's still the case that the
> number of function attributes that don't have @ on them is_far_  greater
> than the number of those that do.

But I explained that most function attributes don't only apply to functions but to variables as well:

public, protected, package, private, static, const,
immutable, inout, and deprecated

So it can be consistent that the above don't use @.

These only affect functions, not variables, so should be @attributes IMO:

final, override, abstract

These affect both:

return, ref

So if we want some kind of consistency, we can achieve it by adding @ for final, override, abstract, and removing it for 'return'.

On 26/01/2015 21:20, bearophile wrote:
> Walter Bright:
>
>> Previously, it's all been advocacy and "break my code"
>
> Breaking the code should be justified by a worth gain. This patch is of
> negative value.

It doesn't break code.