Thread overview
Re: Marking a delegate as pure, nothrow, etc.
Apr 13, 2014
Dicebot
Apr 13, 2014
John Colvin
Apr 13, 2014
monarch_dodra
April 13, 2014
On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
> Is it possible to mark a delegate as pure, @safe, nothrow, etc.?  And if so, how?

... just answered my own question with a bit more experimentation.  The declarations need to come _after_ the delegate:

    void foo(int delegate(int) @safe nothrow pure dg)
    {
        ...
    }

April 13, 2014
On Sunday, 13 April 2014 at 18:02:15 UTC, Joseph Rushton Wakeling wrote:
> On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
>> Is it possible to mark a delegate as pure, @safe, nothrow, etc.?  And if so, how?
>
> ... just answered my own question with a bit more experimentation.  The declarations need to come _after_ the delegate:
>
>     void foo(int delegate(int) @safe nothrow pure dg)
>     {
>         ...
>     }

I'd actually recommend to put all function attributes after parameter list even for normal function declarations. It is not widely accepted practice but helps avoid some confusion:

// `const` does not apply to return param here but to foo itself
const int* foo() { return null; }
// makes it obvious
int* foo() const { return null; }
April 13, 2014
On Sunday, 13 April 2014 at 18:10:19 UTC, Dicebot wrote:
> On Sunday, 13 April 2014 at 18:02:15 UTC, Joseph Rushton Wakeling wrote:
>> On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
>>> Is it possible to mark a delegate as pure, @safe, nothrow, etc.?  And if so, how?
>>
>> ... just answered my own question with a bit more experimentation.  The declarations need to come _after_ the delegate:
>>
>>    void foo(int delegate(int) @safe nothrow pure dg)
>>    {
>>        ...
>>    }
>
> I'd actually recommend to put all function attributes after parameter list even for normal function declarations. It is not widely accepted practice but helps avoid some confusion:
>
> // `const` does not apply to return param here but to foo itself
> const int* foo() { return null; }
> // makes it obvious
> int* foo() const { return null; }

I agree. The only thing I put before the function is @property
April 13, 2014
On 13/04/14 20:10, Dicebot wrote:
> I'd actually recommend to put all function attributes after parameter list even
> for normal function declarations. It is not widely accepted practice but helps
> avoid some confusion

It's actually my habitual practice, but for whatever reason I tried putting the delegate attributes _first_ when declaring the delegate function parameter, and got concerned by the compiler errors that resulted.

It was only after writing my email above that I realized, "Hang on, I didn't try what I usually do for functions," and tried it and found it works.  Though I find it a bit dodgy that the order seems to matter only for delegates as function parameters.
April 13, 2014
On 13/04/14 20:28, Joseph Rushton Wakeling wrote:
> On 13/04/14 20:10, Dicebot wrote:
>> I'd actually recommend to put all function attributes after parameter list even
>> for normal function declarations. It is not widely accepted practice but helps
>> avoid some confusion
>
> It's actually my habitual practice

Incidentally, for _exactly_ the reason you describe.  Early in my D life I got quite confused over the need to write,

    const(int) foo() { ... }

and not

    const int foo() { ... }

and putting function attributes after is _really_ helpful in avoiding unhelpful and incorrect comparisons to C/C++ declarations.
April 13, 2014
On Sunday, 13 April 2014 at 18:31:07 UTC, Joseph Rushton Wakeling wrote:
> On 13/04/14 20:28, Joseph Rushton Wakeling wrote:
>> On 13/04/14 20:10, Dicebot wrote:
>>> I'd actually recommend to put all function attributes after parameter list even
>>> for normal function declarations. It is not widely accepted practice but helps
>>> avoid some confusion
>>
>> It's actually my habitual practice
>
> Incidentally, for _exactly_ the reason you describe.  Early in my D life I got quite confused over the need to write,
>
>     const(int) foo() { ... }
>
> and not
>
>     const int foo() { ... }
>
> and putting function attributes after is _really_ helpful in avoiding unhelpful and incorrect comparisons to C/C++ declarations.

Yeah, but then again, putting them first helpful in noticing that you accidentally wrote it wrong:
//I see anyting wrong here?
const int foo() @safe pure nothrow { ... }

//How about now?
@safe pure nothrow const int foo() { ... }

Personally, I like placing everything on its own line, before.