Attribute inference for auto functions?

[deadalnix]

On Wednesday, 17 April 2013 at 12:22:21 UTC, Peter Alexander 
wrote:
> On Wednesday, 17 April 2013 at 07:58:42 UTC, deadalnix wrote:
>> auto is about type inference. Attribute is part of the 
>> function type as much as it return type, and so it is expected 
>> that auto applied to a function infer its attributes and its 
>> return type.
>
> I disagree. Attributes are completely separate from return 
> value, and I do not think it is "expected" that auto should 
> infer attributes.
>

auto is generally understood as type inference, so ti isn't an 
heresy.

>> The problem you are talking about is very real, but much 
>> broader than this auto thing. The problem is that you have no 
>> control on what the storage classes bind on.
>>
>> Examples :
>> extern(C) void function() foo; // does extern binds to foo, 
>> foo's type or both ?
>> pure function() function() bar; // is bar a pure function ? is 
>> bar() pure ? Noth ? How to choose ?
>
> Yes, that is a problem, but not related to this change.
>

It is, because you can't express both "I want return type 
inference" and " want full type inference"

>> Back to the subject, if auto bind to the function it must 
>> infers attributes, if it binds to the return type, it mustn't. 
>> And right now, storage class bind to the function.
>
> I think you are confusing separate things here.
>
> First, 'auto' is a storage class that means 'no other storage 
> class'. It does NOT mean type inference. You do not need to use 
> 'auto' to get type inference. You cannot use 'auto' in 
> conjunction with other storage classes to get type inference.
>
> auto foo(); // type inference
> const foo(); // type inference
> auto const foo(); // illegal, two storage classes
>
> As you can see, auto is neither sufficient, nor required for 
> type inference. The storage class you use has absolutely 
> nothing to do with type inference. Type inference happens if 
> and only if you do not specify a return type. Storage class and 
> type inference are 100% orthogonal.
>

It is sufficient. It is true that it isn't required as absence of 
type + one storage class means type inference. I kind of 
oversimplyfied that part.

The intent of auto is still type inference, as this is a storage 
class that mean nothing, except that it allow to omit the type.

> The name of this thread is quite misleading. The proposal also 
> has nothing to do with auto. The proposal is to infer 
> attributes when the return type is inferred. I think it's worth 
> being clear on that otherwise people will confuse storage 
> classes with type/attribute inference.

What storage class stand for is already a blurry topic. I don't 
think any confusion can be added.