Attribute inference for auto functions?

[Regan Heath]

On Tue, 16 Apr 2013 21:20:59 +0100, Peter Alexander  
<peter.alexander.au at gmail.com> 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.

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.  You  
alter the signature to suit and copy it back to the .d file.

This is how it should be done, IMO, because now you've explicitly defined  
your library interface so when you accidentally change/break it by  
modifying the code in the library function body, the compiler will  
immediately tell you.

It's win-win or so it seems to me.

> It is an unfortunate situation we are in, with D working best with  
> everything inferred and CTFE-able, yet with those things completely at  
> odds with modularity.

I can't see how it can be any other way.  An interface needs to be clearly  
defined or it's consumer can't use it.  'auto' does not suit that purpose  
at all, currently, and this doesn't change with this pull.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/