auto: useful, annoying or bad practice?

[Mark]

On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
> On Fri, May 11, 2018 at 04:57:05PM +0000, Mark via 
> Digitalmars-d wrote:
>> On Wednesday, 9 May 2018 at 15:06:55 UTC, Jonathan M Davis 
>> wrote:
>> > Ultimately, the key is that the user of the function needs 
>> > to be able to know how to use the return type. In some 
>> > cases, that means returning a specific type, whereas in 
>> > others, it means using auto and being clear in the 
>> > documentation about what kind of API the return type has. As 
>> > long as the API is clear, then auto can be fantastic, but if 
>> > the documentation is poorly written (or non-existant), then 
>> > it can be a serious problem.
>> > 
>> > - Jonathan M Davis
>> 
>> He also needs to know what requirements the parameters of the 
>> function should satisfy. We have template constraints for 
>> that, even though that could also have been "implemented" 
>> through documentation.
>
> This makes me wonder if it might be useful to have return-type 
> constraints.  A kind of static out-contract?  Something that's 
> part of the function declaration, that ensures that the return 
> type satisfies certain properties.
>
> 	// Hypothetical syntax
> 	auto myfunc(R)(R r)
> 	if (isInputRange!R &&
> 		isOutputRange!return)
> 	{
> 		... // implementation here
> 	}
>
> The `isOutputRange!return` (this is just tentative syntax, you 
> guys can probably think of better ways of writing this) 
> statically enforces that the return type must satisfy 
> `isOutputRange`, and, being part of the function signature, 
> documents to the user what to expect of it.
-
> T

This method won't work for non-template functions (since template 
constraints can be used only in, well, templates). Granted, 
non-template functions with auto return type are pretty rare, but 
we probably don't want to impose an unnecessary restriction.