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.
