Attribute inference for auto functions?

[Piotr Szturmaj]

W dniu 18.04.2013 16:58, Andrei Alexandrescu pisze:
> On 4/18/13 2:38 AM, Walter Bright wrote:
>> On 4/17/2013 11:34 PM, deadalnix wrote:
>>> On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
>>>> It will break existing code.
>>>>
>>>> int foo() {
>>>> typeof(return) bar() { return 1; }
>>>> return bar();
>>>> }
>>>>
>>>> typeof(return) represents the return type of foo, that is int.
>>>>
>>>
>>> That is true :( Don't seem fixable.
>>
>> It is fixable if it is special cased, but special cases stink.
>
> Thanks Kenji for a surgical destruction.

What about this:

auto inferReturnTypeAndAttributes() { ... }
auto(return) inferOnlyReturnType() { ... }

or since all attributes are constraints, it can be rewritten to:

auto inferOnlyReturnType() pure nothrow @safe { ... }

It really doesn't make sense to infer impurity, throwing or unsafety 
because these are the default.

I imagine there are some use cases where programmer for example wants to 
infer all but purity, possibly because some other part of the code 
relies on pure behavior of his function, and he doesn't care about the 
other attributes. Example of pure function where nothrow and safety are 
inferred:

auto inferAllButPurity() pure { ... }

To sum up:

1. auto               - infers all
2. auto(return)       - infers only a return type
3. auto fn() attrs... - infers return type and all not specified attributes

Second and third are equivalent, thus auto(return) is optional.

There were some voices about breaking overriden functions by 
adding/inferring superclass function attribute. I think this is an 
oversight, virtual functions should not have attributes inferred.