Attribute inference for auto functions?

[Rob T]

On Wednesday, 17 April 2013 at 16:10:02 UTC, deadalnix wrote:
> 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.

It's certainly not helpful if we keep on blurring the concepts.

The "auto" keyword currently means nothing except that when no 
other storage class is present you can specify it to allow the 
compiler to proceed without error, otherwise type inference is 
always performed unless inference is overridden with an explicit 
type.

The proposal therefore seems to be about extending D to always 
perform attribute inference along with type inference unless the 
attributes are explicitly specified.

The question I have is if the proposal wants to extend the 
meaning of the "auto' keyword so that it will be required in 
order for attribute inference to take place, but that indeed does 
confuse things because we're using the same keyword for two 
completely two different purposes, and it clashes with the use of 
auto in some cases.

-rt