On 27/01/2015 10:20, Jacob Carlborg wrote:
> 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?

Those can apply to variables too. We could use built-in @attributes for functions only (https://issues.dlang.org/show_bug.cgi?id=13388#c31).

On Tuesday, 27 January 2015 at 10:47:23 UTC, ketmar wrote:
> On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Grøstad wrote:
>
>> Hey, I have gray hairs in my beard!
> me too!

Coolies! *smooch*

On Tuesday, 27 January 2015 at 10:37:37 UTC, Jacob Carlborg wrote:
> Seems overly complicated. How about the compiler just outputs new files instead.

The thing I care about is that the compiler leaves the user with no doubt as to what he should do next and how to automatically fix his programs. The actual method of doing this is trivial by comparison.

On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:
> i believe in D too, and i want it to succeed -- not only for me. that's
> why i'm writing here. i'm not attacking it for the sake of attack, and i
> deliberately took the position of outcast.

Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?

On Tue, 27 Jan 2015 16:22:17 +0000, Zach the Mystic wrote:

> On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:
>> i believe in D too, and i want it to succeed -- not only for me. that's why i'm writing here. i'm not attacking it for the sake of attack, and i deliberately took the position of outcast.
> 
> Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?

i have an answer, but sorry, i prefer to not make it public.

On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
> 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'.

abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have @ on them to avoid requiring a keyword (which is why we have @ on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart.

IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have @ and which don't, or we shouldn't mess with them.

Honestly, I just consider @ to be part of the name, and I memorized it as part of the keyword. The result is that I don't even remember ever having a problem trying to figure out which attributes had @ and which didn't. Sure, it would be nice we had a rule of thumb that we could give newbies that would tell them which to use, but so few have @ that I really don't think that it's much of a practical issue - just an aesthetic one.

I'd also point out that the compiler will give an error message telling you which attributes have @ on them you use something like @deprecated, so it's not hard at all to figure out what you did wrong. So, even if someone has trouble remembering which built-in attributes start with @, they'll figure out where they got it wrong quite quickly.

- Jonathan M Davis

On Tuesday, 27 January 2015 at 16:50:00 UTC, Jonathan M Davis wrote:
> On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
>> 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'.
>
> abstract also applies to classes, as does final. Also, if we end up adding
> any new attributes later, they're bound to have @ on them to avoid requiring
> a keyword (which is why we have @ on some of them in the first place), and
> if the new attribute applies to variables or types as well, then the
> division that you're suggesting falls apart.
>
> IMHO, if we have to search for a way to make them consistent, then there's
> no point. We're just going to end up with making things more consistent in
> one way and less in another without necessarily making it any easier for
> anyone to keep track of, so we'd just be shuffling things around. I think
> that there needs to be a clear and solid benefit to changing which
> attributes have @ and which don't, or we shouldn't mess with them.
>
> Honestly, I just consider @ to be part of the name, and I memorized it as
> part of the keyword. The result is that I don't even remember ever having a
> problem trying to figure out which attributes had @ and which didn't. Sure,
> it would be nice we had a rule of thumb that we could give newbies that
> would tell them which to use, but so few have @ that I really don't think
> that it's much of a practical issue - just an aesthetic one.
>
> I'd also point out that the compiler will give an error message telling you
> which attributes have @ on them you use something like @deprecated, so it's
> not hard at all to figure out what you did wrong. So, even if someone has
> trouble remembering which built-in attributes start with @, they'll figure
> out where they got it wrong quite quickly.
>
> - Jonathan M Davis

I share your sentiments exactly.  The only thing I would add is that I don't see why we can't just remove the '@' symbol from all language defined function attributes.  I've already proposed a way to do this that wouldn't add any more keywords and would be fairly trivial to do (see my previous posts).  However, since Walter doesn't like my idea I guess it's dead.  However, I can't figure out why he doesn't like it...so.

This issue isn't a huge deal, like you said it's not too hard to learn which ones require the '@' symbol and which ones don't, it just looks weird.  It's just too bad that my solution isn't even considered even though it would solve all these issues.

On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
> abstract also applies to classes, as does final.

Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.

> Also, if we end up adding
> any new attributes later, they're bound to have @ on them to avoid requiring
> a keyword (which is why we have @ on some of them in the first place), and
> if the new attribute applies to variables or types as well, then the
> division that you're suggesting falls apart.

It's inspired from the status quo - there are no @attributes that apply to variables. __gshared uses underscores instead of @attribute syntax. If we want to introduce a new attribute that applies to both functions and variables, use __attribute.

On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
> On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
>> abstract also applies to classes, as does final.
>
> Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
>

I think you may have missed the point.  I believe what Jonathan is saying is that if you turn abstract into @abstract then you have to consider how to solve the "abstract class" issue.  Do you change it to:

@abstract class ?

Same thing with final.  Since the same keywords are used in a lot of different contexts, if you change how it is used in one context then it's going to be inconsistent with how it's used in the other contexts (like with a function or a class).  Then if you want consistency (which is the point of why we are discussing this change in the first place) you have to change every context it is used in. If you follow through with your proposal, you'll end up putting a '@' character before almost every keyword in the language which has no benefit since the '@' symbol serves no useful purpose to the compiler in the first place (on a keyword at least).

On 27/01/2015 18:01, Jonathan Marler wrote:
> On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
>> On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
>>> abstract also applies to classes, as does final.
>>
>> Yes, but they actually only affect the *functions* belonging to the
>> class, not the variables. A class is not a variable.
>>
>
> I think you may have missed the point.  I believe what Jonathan is
> saying is that if you turn abstract into @abstract then you have to
> consider how to solve the "abstract class" issue.  Do you change it to:
>
> @abstract class ?

Yes, because it affects the class's functions, not its variable members.

> Same thing with final.  Since the same keywords are used in a lot of
> different contexts, if you change how it is used in one context then
> it's going to be inconsistent with how it's used in the other contexts
> (like with a function or a class).  Then if you want consistency (which
> is the point of why we are discussing this change in the first place)
> you have to change every context it is used in. If you follow through
> with your proposal, you'll end up putting a '@' character before almost
> every keyword in the language

In that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting @pure and @nothrow).