Attribute inference for auto functions?

[qznc]

On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander 
wrote:
> On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips 
> wrote:
>> On Tuesday, 16 April 2013 at 20:21:00 UTC, 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. Indeed, this is part of the original reason for 
>>> auto's existence. Denying return type deduction for this use 
>>> case is a major inconvenience.
>>
>> How frequently do you write a non-templated function which 
>> returns a complex template type? It isn't something I really 
>> think about, but I'm pretty sure if I am returning a complex 
>> template type I've already got the function a template.
>
> Often enough. I often find myself returning ranges, which are 
> almost invariably complex template types.
>
> And, to be honest, I would just like to use auto without being 
> locked into inferred attributes. It just feels wrong that these 
> things should be conflated, and I get the feeling we will 
> regret this later on when D starts to be used in larger 
> projects.


I strongly believe you should never use "auto" for API types, 
because it is too easy to break them. If 
Dont-Repeat-Yourself/complex types is a problem, they should be 
solved at the other end by enhancing function body type inference.

An alternative approach would be to do this optimization during 
optimization. However, this means it has to be reimplemented in 
dmd, LLVM, GCC separately. This is e.g. the case for 
pure-inference in C code.