Bug 13397 – allow postfix function attributes like 'safe', 'system' and so on without '@'

Created attachment 1394 postfix function attributes w/o '@' this is another attempt to introduce some consistency in UDA-like and keyword function attributes. instead of allowing '@' everywhere (as in bug #13388) this patch allows omiting '@' in postfix attributes, yet not turning them into keywords (so one still can use variable names like 'system'). i.e. this is now valid: void foo () system nogc { … }

Contextual keywords as in C++? :-)

Created attachment 1395 postfix function attributes w/o '@' (better code, allows nogc {} and nogc:)

Created attachment 1396 this must compile

Created attachment 1397 this must fail 3 times with "cannot use 'new' in @nogc"

(In reply to bearophile_hugs from comment #1) > Contextual keywords as in C++? :-) why not? ;-) it works, it looks nice, it doesn't breaking any existing code. and it looks much cleaner than other way around (i.e. with '@' before each attr).

(In reply to Ketmar Dark from comment #5) > (In reply to bearophile_hugs from comment #1) > > Contextual keywords as in C++? :-) > > why not? ;-) Because it introduces complexity and the return of investment is minimal. (In my opinion it's better to focus on problems of D/Phobos that fix functionality holes, or add commonly useful functionality, or fix significant bugs. There is not lack of all of them in Bugzilla.)

(In reply to bearophile_hugs from comment #6) > Because it introduces complexity and the return of investment is minimal. i don't think that making language slightly more human-friendly is of no value. i don't like modern trend of making compiler to dictate user what to do when compiler is perfectly able to cope with that issues itself. why should i remember when i must put that '@' before attribute? there is no ambiguity introduced by this patch, yet the patch allows me to forget what function attributes are so special that they don't need '@' once and forever. yes, this can introduce some complexity to syntax highlighters, but i don't care: i believe that computer should make my life easier, not vice versa. if this means more work for computer… ok, that's why we made computers, right? we can't fix C/C++, but if D can be made human-friendlier with a trivial and non-breaking change… why not? > (In my opinion it's better to focus on problems of D/Phobos that fix > functionality holes, or add commonly useful functionality, or fix > significant bugs. There is not lack of all of them in Bugzilla.) playing with parser is easy, and other tasks requires a lot deeper code understaning. i'm doing what i can now. ;-)

(In reply to Ketmar Dark from comment #7) > i don't think that making language slightly more human-friendly is > why should i remember when i must put that '@' before attribute? Adding contextual keywords to D is an increase in complexity for users too. I think that remembering where to put the @ is simpler for the user.

(In reply to bearophile_hugs from comment #8) > (In reply to Ketmar Dark from comment #7) > Adding contextual keywords to D is an increase in complexity for users too. aren't existing '@'-attributes are kind of contextual keywords too? besides, things like '@safe' can be easily misunderstood as 'real' UDAs. so compiler tend to ignore almost all UDAs except some special ones? but why? there is no logic behind this execept that "we don't want to add more keywords to the language". yet there is perfectly clear context for 'system', 'safe', etc: postfix function attribute declaration. the only thing that will break is delegate decls, i.e.: void foo (void delegate bar() safe) this will declare nameless arg instead of declaring arg with name 'safe'. yet i believe that there is no production/library code that using attr names as variable names anyway. and this can be fixed by allowing such decl: void foo ((void delegate bar() safe) safe) yes, it's ugly, but the alternative is yet another syntax for function attributes, smth. like: void foo (void delegate bar() [safe] safe) ah. do not want. > I think that remembering where to put the @ is simpler for the user. i believe that user should not even think about this. people kept asking me why they must write '@safe', but not '@pure'. and in what module '@safe' UDA is defined. i'm ok with any decision: either 'all @' or 'nothing @', but the current state of things is inconsistent and hard to explain to newcomers.

(In reply to Ketmar Dark from comment #2) > Created attachment 1395 [details] > postfix function attributes w/o '@' (better code, allows nogc {} and nogc:) Combination of prefix attribute and contextual keyword feature will cause ambiguity. struct nogc {} nogc foo() { return *(new nogc()); } // func must not be @nogc I think just only postfix cases should be accepted.

(In reply to Kenji Hara from comment #10) > Combination of prefix attribute and contextual keyword feature will cause > ambiguity. > I think just only postfix cases should be accepted. and my patch description clearly says that it's only for "postfix function attributes". ;-) i strongly believe that we should deprecate and kill prefix attributes anyway. one thing i did wrong is supporting for `nogc {}` and `nogc:` — i should check for '{' and ':' before deciding if 'nogc' is identifier or attribute. have to fix my patch.

Created attachment 1398 postfix function attributes w/o '@' (better code, allows nogc {} and nogc:) fixed patch. now Kenji's sample is OK.

Created attachment 1399 postfix function attributes w/o '@' (better code, allows nogc {} and nogc:) fixed patch yet again. forgot to change Parser::skipAttributes().

Such language changes need to be proposed through the DIP process: https://github.com/dlang/DIPs Bugzilla is not the correct place for language enhancements. Without a DIP, this patch will not be accepted, so there's no point in keeping this issue open.