On 4/17/2013 8:12 AM, Andrei Alexandrescu wrote:
> I think this is a bit much. Simplicity is a good commodity to allow oneself of,
> and absorbing two different meanings of 'auto' in the same construct is not simple.

It also goes back to your discussion of the observation that programmers do not go back and annotate the code, even for large benefits.

On 4/17/2013 10:37 AM, Michel Fortin wrote:
> Compilation speed is not a problem for functions with the "auto" return type
> because there are only a few of them.

It is not a problem right now because the compiler has to semantically analyze their function bodies already in order to determine the return type. It is insignificant to additionally gather the attribute information.

On 4/17/2013 10:41 AM, Jesse Phillips wrote:
> I wish to bring Someboddies consern to this form.
>
> What does attribute inference mean for inheritance?


I specifically addressed his concern in the git page:

"This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."

On 4/17/2013 12:06 PM, Walter Bright wrote:
> On 4/17/2013 10:41 AM, Jesse Phillips wrote:
>> I wish to bring Someboddies consern to this form.
>>
>> What does attribute inference mean for inheritance?
>
>
> I specifically addressed his concern in the git page:
>
> "This is the same issue as defining a function with 'auto' in one place and
> referring to it having a specific type/attribute in another. So I think all the
> same arguments and reasoning discussed above apply equally."
>

His followup doesn't change that. It's still the same issue (covariance) which is discussed repeatedly.

Yes, please do attribute inference!

On 4/17/2013 8:14 AM, Andrei Alexandrescu wrote:
> On 4/17/13 8:09 AM, Andrej Mitrovic wrote:
>> On 4/17/13, Regan Heath<regan@netmail.co.nz>  wrote:
>>> Solution:  You use 'auto' and compile the code producing a .di.  With the
>>> fix Andrei mentioned the .di has the full and complete function signature,
>>> without 'auto', including return type and all deduced attributes etc.
>>
>> This doesn't work with voldemort types.
>
> It's not supposed to; voldemort functions are by definition non-modular.


The whole point of voldemort functions is that you cannot name the return type, so there is no way to write a signature for it to put in the .di file. Hence, it not working with voldemort types is moot.

On 4/17/2013 8:07 AM, Andrei Alexandrescu wrote:
> On 4/16/13 4:20 PM, Peter Alexander wrote:
>> This is the point I have a problem with:
>>
>>>> 2.2. One cannot opt out of nothrow or pure with auto functions.
>>> This argument has one solid answer: don't use auto when the need is to
>>> specify an attribute pattern explicitly.
>>
>> I find this unacceptable. Thanks to the proliferation of template code
>> in D, it is often rather difficult to spell out return types.
>
> Attribute inference is always done for templates.

And, I might add, I cannot recall a single adverse issue that has caused.

On 4/17/2013 12:58 AM, deadalnix wrote:
> 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.

'auto', like all storage class annotations such as 'const', binds to the declaration and the declaration's type. It is perfectly consistent.


> extern(C) void function() foo; // does extern binds to foo, foo's type or both ?

foo is being declared, so it binds to foo.

> pure function() function() bar; // is bar a pure function ? is bar() pure ? Noth ? How to choose ?

bar is being declared, so it binds to bar.

On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander wrote:
> Often enough. I often find myself returning ranges, which are almost invariably complex template types.

Hmm, I'm still trying to decide if this is a major concern.

Generally when returning a range, this is done because operations are being performed on a container, the specific container isn't important and many times nor is the type in the container. This means my function is a template.

The times when I could see returning a complex type where the function isn't templates is when I'm loading the data to be consumed. In this case I generally will return the container itself (since ownership isn't with the called function).

On 4/17/2013 10:35 AM, Jesse Phillips wrote:
> I don't think auto should be made specific to attribute inference. So I think
> the discussion should consider:
>
> const foo()//...
>
> would that be something that should also be a attribute inference.

Yes, the pull request does that, too.