accept @pure @nothrow @return attributes

Jonathan Marler via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 28 13:46:42 PST 2015


On Wednesday, 28 January 2015 at 21:37:02 UTC, Daniel Kozak wrote:
> Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 
> 19:33 +0000:
>> On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak 
>> wrote:
>> >> I would think the reason would be it could make the grammar 
>> >> ambiguous.  That's why I proposed it only be valid on the 
>> >> right hand side of the function to guarantee it doesn't 
>> >> introduce any ambiguity.  Other then that, I don't see any 
>> >> reason why it's a bad thing.  It doesn't make the syntax 
>> >> more complicated, it doesn't maker it harder to parse, I 
>> >> just don't see why its bad.
>> >
>> > Thats not possible:
>> >
>> > @safe {
>> >     void some func() // now valid
>> > }
>> >
>> > safe:
>> >     void some func() // now valid
>> >
>> >
>> >
>> > safe {
>> >     void some func() // could not be valid
>> > }
>> >
>> > safe:
>> >     void some func() // could not be valid
>> >
>> >
>> > So you need more places where keyword needs to be contextual 
>> > keyword
>> >
>> > And this is a path I am not sure we want to go.
>> 
>> None of those cases would valid.  Non-Keyword attributes 
>> without a '@' must be on the right hand side of the function 
>> parameters.
>> 
>> void some func(); // some is not a keyword, so it is invalid
>
> Typo I mean some_func

Oh ok.  Then I'm not sure what your trying to say with your 
examples.  The proposal is that you could only omit the '@' 
symbol if the word appeared after the function parameters.

safe void foo(); // STILL NOT VALID
void foo() safe; // NOW VALID

If it comes before, then you still need the '@'.

@safe void foo(); // STILL VALID (no change), however,
                   // this usage would be discouraged

Your examples do bring up a usage I hadn't thought of though.  It 
would be a bit odd for newcomers to use "safe" without an '@' in 
one case and then have to include the '@' another case (the 
example you provided).  This makes it less appealing.  Either 
way, I don't think it matters since the proposal isn't acceptable 
for a different reason, the leadership doesn't like the same 
words to be used as function attributes sometimes and identifiers 
other times.



More information about the Digitalmars-d mailing list