On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:
> immutable, inout, and deprecated all don't have @. So, most function
> attributes _don't_ have @ on them, and we just added @ to some of them,
> making things even _less_ consistent. In fact, priore to this, @safe,
> @trusted, @system, and @property were the _only_ function attributes with @
> on them. So, if we really wanted to improve consistency IMHO, we'd get rid
> of @ from everything that's built-in and leave it for user-defined
> attributes, but that would break existing code too.

I agree  that you need to let "@" act as some kind of mnemonic and therefore assign meaning to it.

One meaning would be to only use "@" with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining).

Besides it would be easy to change the parser so that terms can be reused as symbols if the grammar stays sound. I think that is true for most function attributes anyway.

2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d < digitalmars-d@puremagic.com>:

> Jonathan M Davis:
>
>  Personally, I'd much prefer that we not make this change. It's just
>> shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.
>>
>
> So far I agree with Jonathan.
>
> Bye,
> bearophile
>

Me too. At best it is just a cosmetic change, and will introduce huge code style confusion.

We should revert it quickly.

Kenji Hara

On Monday, 26 January 2015 at 13:57:13 UTC, Kenji Hara wrote:
> 2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d <
> digitalmars-d@puremagic.com>:
>
>> Jonathan M Davis:
>>
>>  Personally, I'd much prefer that we not make this change. It's just
>>> shuffling things around in an attempt to make them more consistent while
>>> actually making them _less_ consistent.
>>>
>>
>> So far I agree with Jonathan.
>>
>> Bye,
>> bearophile
>>
>
> Me too. At best it is just a cosmetic change, and will introduce huge code
> style confusion.
>
> We should revert it quickly.
>
> Kenji Hara

Yes we should, it does not fix anything

On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
> One meaning would be to only use "@" with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining).

All of the existing @ affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had @ and which didn't.

- Jonathan M Davis

2015-01-27 0:07 GMT+09:00 Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
> > One meaning would be to only use "@" with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining).
>
> All of the existing @ affect the type of the function. It's attributes like
> public or static which don't, and those still affect aspects of compilation
> and can easily cause compilation errors. There are not currently any
> attributes which are simply hints to the compiler, and the ones which
> affect
> the safety checks are _definitely_ part of the type of the function. So, I
> don't think that that particular distinction would work, even if we could
> freely rearrange which attributes had @ and which didn't.
>

Additional note: UDA can be attached to symbols only.

void foo() @uda {}
// __traits(getAttributes, foo) == (uda)
// pragma(msg, typeof(foo)); prints void(), no @uda

void function() @uda fp;
// Error: user defined attributes cannot appear as postfixes

Kenji Hara

On Monday, 26 January 2015 at 15:07:24 UTC, Jonathan M Davis wrote:
> On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
> function. So, I
> don't think that that particular distinction would work, even if we could
> freely rearrange which attributes had @ and which didn't.

I personally agree that it would be better to remove "@" like you suggested and leave it for UDAs. Interpreting D code is hard for tools without a library anyway, so I think the current approach is unwarranted, and would rather see a more complicated grammar and parser in favour of usability. D could provide an official parser/semantic analysis library available for tools (like clang).

The visual noise in D2 is too high IMO, and the reuse of keywords/symbols for unrelated functionality makes usability/legibility/reading comprehension worse.  I think this alone is enough to prevent mainstream adoption.

Other languages compensate by having constructs that allow you do use "keywords" for fieldnames in records. It is a better strategic move to favour good syntactical usability/legibility over parsing complexity. Clean context independent mapping between syntax and semantics is important.

Besides, D really needs to allow the use of common nouns like "body" in structs (e.g. to implement the HTML DOM)... so a more wholesome approach to rethinking the D syntax would be welcome.

The D syntax needs rethinking as a whole, not in bits and pieces. If you are gonna break, make it clean, and make the language easy to learn.

I agree with Jonathan's points, this solution doesn't seem like an improvement.   If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes for sake of consistency.  However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...).

Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords?  Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords.

I understand that doing this may be fairly complicated.  This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.

On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
> I agree with Jonathan's points, this solution doesn't seem like an improvement.   If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes for sake of consistency.  However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...).
>
> Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords?  Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords.
>
> I understand that doing this may be fairly complicated.  This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.

You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.

On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
> In theory, the increased consistency is welcome, but the increased visual
> noise definitely is not.  And if we leave in pure and nothrow without @,
> then we're going to have code out there doing both, which adds to the
> confusion, and if we deprecate pure and nothrow without @, then we'll be
> forced to change pretty much every D program in existence.

Only if the deprecation became an error.

> But It's not like this really improves consistency all that much anyway,
> because public, protected, package, private, final, override, static, const,
> immutable, inout, and deprecated all don't have @.

Most of those also apply to variable members. pure, nothrow, return only apply to functions.

I like this change, but it might be better if final, override and inout gained @attribute syntax too. Then it would have more consistency.

Also the inverted-attribute option then doesn't need !ugly !sigils - @impure vs @pure, @throw vs @nothrow, etc.

> In fact, priore to this, @safe,
> @trusted, @system, and @property were the_only_  function attributes with @
> on them.

There's also @disable and more recently, @nogc.

On 26/01/2015 17:07, Nick Treleaven wrote:
> and inout gained @attribute syntax too

Actually inout can apply to local variables, so it shouldn't have a '@' by my logic.