On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler wrote:
> On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
>> Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
>
> The purpose of this thread wasn't to re-discuss what was already discussed.  The answer to your idea can be found in the other thread http://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org.
>  It's gonna be a long read so I'll summarize what I believe is the correct answer.
>
> The problem we are trying to solve is that the function attributes are inconsistent.  Some use @ like "@safe" and "@nogc" and some don't like "pure" and "nothrow".
>
> So one idea is to require an '@' symbol in front of all of them for the sake of consistency.  The problem with this idea is that you've now introduced inconsistency somewhere else.  Every keyword that you put an '@' symbol in front of, will be used somewhere else without an '@' symbol.  Like this:
>
> abstract class MyClass { }
> @abstract void myfunc();
>
> See the inconsistency?  You're gonna end up with alot of these types of inconsistencies. In addition, you've made the rule of when to use the '@' symbol more complex.  Before it was, "Use '@' if it is not a keyword".  Now it's, "Use '@' if it is not a keyword except when it's a function attribute".  This definition will likely be made worse since people will want to solve the newly introduced inconsistencies.  So the new definition will become, "Use '@' if it is a keyword except if it's a function attribute or a class specifier".  By the time you solve every inconsistency you'll have made every usage of every keyword use the '@' symbol.  Then the rule will be "Always use the '@' symbol".
>
> This will definitely be included on the FAQ :)  I'll reword it and modify it but I agree that people will want an explanation for this.

One can argue that it's hard to remember what is a keyword (especially in D where there are many) and easier to distinguish beetween qualifiers and attributes. But I understand legacy code is an issue and I agree that the FAQ should just state the facts.

On 1/29/15 7:03 AM, Jonathan Marler wrote:
> On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote:
>> It would be somewhere under:
>> http://wiki.dlang.org/
>>
>> Maybe Documentation => Language Design Explanation?
>
> Anyone else "for" or "against" this?  If no one protests I can create
> it, along with the FAQ from matovich and including Walters extra
> explanation about increasing redundancy.

Just do it. -- Andrei

On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
> On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler wrote:
>> On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
>>> Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
>>
>> The purpose of this thread wasn't to re-discuss what was already discussed.  The answer to your idea can be found in the other thread http://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org.
>> It's gonna be a long read so I'll summarize what I believe is the correct answer.
>>
>> The problem we are trying to solve is that the function attributes are inconsistent.  Some use @ like "@safe" and "@nogc" and some don't like "pure" and "nothrow".
>>
>> So one idea is to require an '@' symbol in front of all of them for the sake of consistency.  The problem with this idea is that you've now introduced inconsistency somewhere else.  Every keyword that you put an '@' symbol in front of, will be used somewhere else without an '@' symbol.  Like this:
>>
>> abstract class MyClass { }
>> @abstract void myfunc();
>>
>> See the inconsistency?  You're gonna end up with alot of these types of inconsistencies. In addition, you've made the rule of when to use the '@' symbol more complex.  Before it was, "Use '@' if it is not a keyword".  Now it's, "Use '@' if it is not a keyword except when it's a function attribute".  This definition will likely be made worse since people will want to solve the newly introduced inconsistencies.  So the new definition will become, "Use '@' if it is a keyword except if it's a function attribute or a class specifier".  By the time you solve every inconsistency you'll have made every usage of every keyword use the '@' symbol.  Then the rule will be "Always use the '@' symbol".
>>
>> This will definitely be included on the FAQ :)  I'll reword it and modify it but I agree that people will want an explanation for this.
>
> One can argue that it's hard to remember what is a keyword (especially in D where there are many) and easier to distinguish beetween qualifiers and attributes. But I understand legacy code is an issue and I agree that the FAQ should just state the facts.

This doesn't really have to do with Legacy code.  You can always support both ways for a time and deprecate the old way.  It appears my answer did not address your idea well enough.  I'll have to put together a better explanation.  In the mean time, could you help me by giving me the gritty details of your idea.  I know others will also want an explanation for this so I'd like to include one in the FAQ so as to prevent us from explaining the same thing over and over.  You idea was to put '@' on words if they are attributes and to omit them on qualifiers.  Could you list what words are qualifiers and what words are attributes?  I don't think this idea would work but hey, maybe you'll prove me wrong, I'll admit I haven't gone through the details of what problems this idea would create.

On Thursday, 29 January 2015 at 16:13:59 UTC, Jonathan Marler wrote:
> On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
>> On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler wrote:
>>> On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
>>>> Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
>>>
>>> The purpose of this thread wasn't to re-discuss what was already discussed.  The answer to your idea can be found in the other thread http://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org.
>>> It's gonna be a long read so I'll summarize what I believe is the correct answer.
>>>
>>> The problem we are trying to solve is that the function attributes are inconsistent.  Some use @ like "@safe" and "@nogc" and some don't like "pure" and "nothrow".
>>>
>>> So one idea is to require an '@' symbol in front of all of them for the sake of consistency.  The problem with this idea is that you've now introduced inconsistency somewhere else.  Every keyword that you put an '@' symbol in front of, will be used somewhere else without an '@' symbol.  Like this:
>>>
>>> abstract class MyClass { }
>>> @abstract void myfunc();
>>>
>>> See the inconsistency?  You're gonna end up with alot of these types of inconsistencies. In addition, you've made the rule of when to use the '@' symbol more complex.  Before it was, "Use '@' if it is not a keyword".  Now it's, "Use '@' if it is not a keyword except when it's a function attribute".  This definition will likely be made worse since people will want to solve the newly introduced inconsistencies.  So the new definition will become, "Use '@' if it is a keyword except if it's a function attribute or a class specifier".  By the time you solve every inconsistency you'll have made every usage of every keyword use the '@' symbol.  Then the rule will be "Always use the '@' symbol".
>>>
>>> This will definitely be included on the FAQ :)  I'll reword it and modify it but I agree that people will want an explanation for this.
>>
>> One can argue that it's hard to remember what is a keyword (especially in D where there are many) and easier to distinguish beetween qualifiers and attributes. But I understand legacy code is an issue and I agree that the FAQ should just state the facts.
>
> This doesn't really have to do with Legacy code.  You can always support both ways for a time and deprecate the old way.  It appears my answer did not address your idea well enough.  I'll have to put together a better explanation.  In the mean time, could you help me by giving me the gritty details of your idea.  I know others will also want an explanation for this so I'd like to include one in the FAQ so as to prevent us from explaining the same thing over and over.  You idea was to put '@' on words if they are attributes and to omit them on qualifiers.  Could you list what words are qualifiers and what words are attributes?  I don't think this idea would work but hey, maybe you'll prove me wrong, I'll admit I haven't gone through the details of what problems this idea would create.

Sorry this may be my fault. I think there were only 4 qualifier in D : const, immutable, share and inout (I am not aware of this new "scope" thing). pure is a function attribute and a keyword, this is inconsistant with other built-in attributes with @ in front of them like @property or @nogc. I think (and my opinion doesn't worth much as I am not experienced as a programmer and I didnt used D very much) that it would be more consistant if we hadn't this keyword and be forced to use @pure instead. (const can be a method annotation/attribute too, so should be @const keeping const as a variable/parameter qualifier).

On 29/01/2015 15:54, Jonathan Marler wrote:
> Like this:
>
> abstract class MyClass { }
> @abstract void myfunc();
>
> See the inconsistency?  You're gonna end up with alot of these types of
> inconsistencies. In addition, you've made the rule of when to use the
> '@' symbol more complex.  Before it was, "Use '@' if it is not a
> keyword".  Now it's, "Use '@' if it is not a keyword except when it's a
> function attribute".  This definition will likely be made worse since
> people will want to solve the newly introduced inconsistencies.  So the
> new definition will become, "Use '@' if it is a keyword except if it's a
> function attribute or a class specifier".  By the time you solve every
> inconsistency you'll have made every usage of every keyword use the '@'
> symbol.  Then the rule will be "Always use the '@' symbol".

No, the idea proposed was:

@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;

const is never @const. @abstract is always @abstract. It is variables that don't use @attribute syntax. This is not something I invented, it follows on from existing uses of @attributes and __keywords already supported by dmd.

About the lists

Qualifiers : const (can be an method attribute), immutable (can
be an method attribute), inout, shared, (scope ?)

Attributes : const (can be a type qualifier), immutable (can be a
type qualifier), final (even so I don't understand why private
final is so special), pure, @nothrow, @property, @nogc,...

Neither qualifier nor attributes : abstract, override,... and
many others

Why "override" is not a method attribute...because if you remove
it you've change the "semantic" of the code..."final" doesn't
change anything if you remove it. To me, a function/method
attribute enforce a behaviour on the function but you should be
able to remove it without changing the "semantic".

On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven wrote:
> No, the idea proposed was:
>
> @safe @override const func();
> @abstract class C{}
> const var = 5;
> __gshared gvar = 4;
>
> const is never @const. @abstract is always @abstract. It is variables that don't use @attribute syntax. This is not something I invented, it follows on from existing uses of @attributes and __keywords already supported by dmd.

Nick I'm putting together the FAQ right now.  I don't quite understand this proposal.  Could you outline it for me?  I'd like to know exactly what words would require an '@' symbol. What is the criteria for when to use an '@' and when not to use one?  This current rule is (use '@' if it is not a keyword)...so what would the new rule be? Thanks.

On Thursday, 29 January 2015 at 17:50:23 UTC, matovitch wrote:
> About the lists
>
> Qualifiers : const (can be an method attribute), immutable (can
> be an method attribute), inout, shared, (scope ?)
>
> Attributes : const (can be a type qualifier), immutable (can be a
> type qualifier), final (even so I don't understand why private
> final is so special), pure, @nothrow, @property, @nogc,...
>
> Neither qualifier nor attributes : abstract, override,... and
> many others
>
> Why "override" is not a method attribute...because if you remove
> it you've change the "semantic" of the code..."final" doesn't
> change anything if you remove it. To me, a function/method
> attribute enforce a behaviour on the function but you should be
> able to remove it without changing the "semantic".

I'll need a better definition of what a qualifier/attribute is.  It's ok to use words like "qualifier" and "attribute" when discussing ideas, but I'm trying to document how this idea would really affect everything so I need a solid definition of what you mean by a qualifier and an attribute.  You said an attribute enforces a behavior on the function but you should be able to remove it without changing the "semantics".  What do you mean by semantics, because under my definition of semantics, removing a function qualifier does change the semantics.  Maybe a better definition is, removing it doesn't change the logic of the function?  Not sure.  Maybe you can come up with a better definition.  Thanks.

On Thursday, 29 January 2015 at 17:51:06 UTC, Jonathan Marler wrote:
> On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven wrote:
>> No, the idea proposed was:
>>
>> @safe @override const func();
>> @abstract class C{}
>> const var = 5;
>> __gshared gvar = 4;
>>
>> const is never @const. @abstract is always @abstract. It is variables that don't use @attribute syntax. This is not something I invented, it follows on from existing uses of @attributes and __keywords already supported by dmd.
>
> Nick I'm putting together the FAQ right now.  I don't quite understand this proposal.  Could you outline it for me?  I'd like to know exactly what words would require an '@' symbol. What is the criteria for when to use an '@' and when not to use one?  This current rule is (use '@' if it is not a keyword)...so what would the new rule be? Thanks.

Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there).

On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote:
> Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there).

Post is up.  I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand.  It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas.  However, since time is a finite resource, I think having a wiki we can point people to is a great compromise.  I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki.

This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language.  I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute.