Please do not use 'auto' return types without thoroughly describing the interface

[Mark]

On Wednesday, 27 December 2017 at 16:36:59 UTC, H. S. Teoh wrote:
> On Tue, Dec 26, 2017 at 11:28:56AM +0000, Mark via 
> Digitalmars-d wrote:
>> On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
>> > [...]
>> 
>> Maybe we can document the interface of the return type using 
>> signature constraints? For instance, for the function:
>> 
>> auto map(Range)(Range r) if (isInputRange!(Unqual!Range));
>> 
>> we'd add the following to its constraints:
>> 
>> isInputRange!(ReturnType!(map!R))
>> 
>> However, this does not compile at the moment. I'm not sure why.
>
> I'm not sure why either, but signature constraints are intended 
> to be used for constraining the range of incoming template 
> arguments that the template will accept. It's not intended to 
> establish a contract on what the template is going to produce 
> when instantiated with those arguments, though this could well 
> be an enhancement request. Perhaps this should be filed in 
> bugzilla so that it won't get forgotten.
> 
> T

I guess we could introduce "static in" and "static out" contracts 
analogous to the existing "in" and "out" contracts, except these 
would be run at compile-time. But this doesn't seem strictly 
necessary - the compiler can figure out on its own which 
constraints depend only on the function's (compile-time) 
parameters and which constraints also depend on its return type.