It's already inferred for templated functions, so it's perfectly possible.
Also it should be checked anyway, so I get an error message if I marked something pure or whatever while it actually isn't.

The only functions where it can't be inferred and manual attributes are really needed are function definitions (i.e. no body available).

What speaks against it?

On 5/11/2012 11:53 AM, Trass3r wrote:
> It's already inferred for templated functions, so it's perfectly possible.
> Also it should be checked anyway, so I get an error message if I marked
> something pure or whatever while it actually isn't.
>
> The only functions where it can't be inferred and manual attributes are really
> needed are function definitions (i.e. no body available).
>
> What speaks against it?

Separate compilation.

I.e. given modules A and B:

A
===
int foo() { return 3; }
===

B
===
import A;

pure int bar() { return foo(); }
===

and the compiler infers purity, so it compiles.

Then, maintenance programmer Fred updates module A to be:

A
===
int x;
int foo() { return x; }
===

and now foo() is no longer pure. He recompiles A, links with existing B.obj, and now whoops! bar() is marked as pure, but is not pure.

This issue does not exist for templates & literals & auto funcs, because already A must be recompiled if B is modified.

Thanks for the explanation.
Should be somewhere in the docs :)

On Friday, 11 May 2012 at 20:29:45 UTC, Walter Bright wrote:
> On 5/11/2012 11:53 AM, Trass3r wrote:
>> It's already inferred for templated functions, so it's perfectly possible.
>> Also it should be checked anyway, so I get an error message if I marked
>> something pure or whatever while it actually isn't.
>>
>> The only functions where it can't be inferred and manual attributes are really
>> needed are function definitions (i.e. no body available).
>>
>> What speaks against it?
>
> Separate compilation.
>
> I.e. given modules A and B:
>
> A
> ===
> int foo() { return 3; }
> ===
>
> B
> ===
> import A;
>
> pure int bar() { return foo(); }
> ===
>
> and the compiler infers purity, so it compiles.
>
> Then, maintenance programmer Fred updates module A to be:
>
> A
> ===
> int x;
> int foo() { return x; }
> ===
>
> and now foo() is no longer pure. He recompiles A, links with existing B.obj, and now whoops! bar() is marked as pure, but is not pure.
>
> This issue does not exist for templates & literals & auto funcs, because already A must be recompiled if B is modified.

I thought Purity was marked in the mangled name, so that should give a link error.

> I thought Purity was marked in the mangled name, so that should give a link error.

Good point.

On 5/11/2012 4:48 PM, Trass3r wrote:
>> I thought Purity was marked in the mangled name, so that should give a link
>> error.
>
> Good point.

Doesn't work if any modules declare:

   extern int foo();

Am 12.05.2012 05:33, schrieb Walter Bright:
> On 5/11/2012 4:48 PM, Trass3r wrote:
>>> I thought Purity was marked in the mangled name, so that should give
>>> a link
>>> error.
>>
>> Good point.
>
> Doesn't work if any modules declare:
>
> extern int foo();

Those functions would always be considered impure, unless the programmer says otherwise in the extern declaration.

On 11-05-2012 20:53, Trass3r wrote:
> It's already inferred for templated functions, so it's perfectly possible.
> Also it should be checked anyway, so I get an error message if I marked
> something pure or whatever while it actually isn't.
>
> The only functions where it can't be inferred and manual attributes are
> really needed are function definitions (i.e. no body available).
>
> What speaks against it?

Purity is part of the API. If, in version $a of an API, your function just happens to be inferred as pure and your users rely on it, you'll break their code if you change your function's code in version $b and it's no longer pure without you noticing. This effectively defeats the purpose of inferred purity because you cannot rely on it.

It's as simple as that.

-- 
- Alex

Le 11/05/2012 22:29, Walter Bright a écrit :
> On 5/11/2012 11:53 AM, Trass3r wrote:
>> It's already inferred for templated functions, so it's perfectly
>> possible.
>> Also it should be checked anyway, so I get an error message if I marked
>> something pure or whatever while it actually isn't.
>>
>> The only functions where it can't be inferred and manual attributes
>> are really
>> needed are function definitions (i.e. no body available).
>>
>> What speaks against it?
>
> Separate compilation.
>
> I.e. given modules A and B:
>
> A
> ===
> int foo() { return 3; }
> ===
>
> B
> ===
> import A;
>
> pure int bar() { return foo(); }
> ===
>
> and the compiler infers purity, so it compiles.
>
> Then, maintenance programmer Fred updates module A to be:
>
> A
> ===
> int x;
> int foo() { return x; }
> ===
>
> and now foo() is no longer pure. He recompiles A, links with existing
> B.obj, and now whoops! bar() is marked as pure, but is not pure.
>
> This issue does not exist for templates & literals & auto funcs, because
> already A must be recompiled if B is modified.

I did considered that quite a lot.

I came to the conclusion that function should have explicit and infered attributes.

For simplicity, I will limit myself to pure here, the same can be extended to other attributes.

So, if a function is marked as pure, this function is EXPLICITELY pure. It means that the compiler ensure it is pure.

Otherwise, the function is marked as not explicitly pure, and purity is inferred unknown. When using such a function in a way that require a pure function, if nothing is explicitly stated, the inferred attribute is used. If the inferred attribute is unknown, the function body is used to infer it.

With such a mechanism, attribute are inferred when needed (otherwise, the calculation can become quite expansive).

If the function body is unknown (separate compilation model). Inference is impossible.

Alternatively, the DI generation could make inferred attributes explicit.

Such inference is very important for D. We have many qualifier, and it is unlikely that every programmer mark everything as it should. Just consider the state of druntime in that regard, and it have been done by experienced D programmers.

On 05/12/2012 04:46 PM, deadalnix wrote:
> Just consider the state of druntime in that regard, and it have been done by
> experienced D programmers.

... before the attributes were introduced.