We're #1 on Hacker News at the moment!

[H. S. Teoh]

On Tue, Apr 28, 2020 at 02:07:07PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 4/28/20 1:06 PM, Adam D. Ruppe wrote:
> > On Tuesday, 28 April 2020 at 16:50:20 UTC, Laust wrote:
> > > The lukewarm response and the type inference argument make me sad.
> > 
> > Type inference itself isn't bad, but the auto in documentation is
> > something I agree isn't great.
[...]
> Yeah, the whole thread is ignoring that there's actual documentation
> for those functions which says what it returns, and IMO it's more
> descriptive than some long machine-usable multi-page type generation
> thing that nobody will comprehend.
> 
> There are certainly cases where auto is overused. I also think, if
> there is a non-template return type, auto could be changed to
> returning that type in the docs.
[...]

Y'know, this makes me wonder if it might be worth having something akin
to a compile-time out-contract that asserts certain attributes of the
returned type. For example:

	// (N.B.: hypothetical syntax)
	auto myComplexRangeFunc(R, Args...)(R range, Args args)
		if (isInputRange!R && is(ElementType!R : SomeType))
		out (S result; isInputRange!S && is(ElementType!S : SomeOtherType))
	{
		return ... /* some complicated Voldemort type */
	}

The point is, sometimes you don't *want* user code to be dependent on
the type you return, but you *do* want some sort of assurance, beyond
textual description in the docs, of what operations you can perform on
the return type.  An out-contract (or equivalent) seems like a good
place to put such assertions.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra