https://issues.dlang.org/show_bug.cgi?id=13397

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #1 from bearophile_hugs@eml.cc ---
Contextual keywords as in C++? :-)

--

https://issues.dlang.org/show_bug.cgi?id=13397

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1394|0                           |1
        is obsolete|                            |
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1395
  --> https://issues.dlang.org/attachment.cgi?id=1395&action=edit
postfix function attributes w/o '@' (better code, allows nogc {} and nogc:)

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1396
  --> https://issues.dlang.org/attachment.cgi?id=1396&action=edit
this must compile

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #4 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1397
  --> https://issues.dlang.org/attachment.cgi?id=1397&action=edit
this must fail 3 times with "cannot use 'new' in @nogc"

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #5 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(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).

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #6 from bearophile_hugs@eml.cc ---
(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.)

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #7 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(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. ;-)

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #8 from bearophile_hugs@eml.cc ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #9 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13397

--- Comment #10 from Kenji Hara <k.hara.pg@gmail.com> ---
(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.

--