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.

Reply via email to