Issue 8307 and 13336 - fix documentation around return type inference and ref deduction

[9rnsr]

Issue 8307 - inconsistent treatment of auto functions
Issue 13336 - auto ref return deduced to be ref despite return value coercion

[MetaLang]

"have common" -> "must be implicitly convertible to a common type"?

[9rnsr]

Thanks for the better wording. Fixed.

[JakobOvrum]

Wow, since when did return type inference use the common type of all return statements instead of just using the type of the first return statement? I remember Walter repeatedly saying it's the latter, for ease of implementation purposes. Was the implementation changed at some point?

[9rnsr]

It's from 2.057. The first compiler code change about that was in https://github.com/D-Programming-Language/dmd/pull/476/files#diff-0489411409cd2934730e88bf77677907L3589 .

[JakobOvrum]

It's from 2.057. The first compiler code change about that was in https://github.com/D-Programming-Language/dmd/pull/476/files#diff-0489411409cd2934730e88bf77677907L3589 .

Thanks!

[JakobOvrum]

This also happens if the return statement expression for all return statements is void:

void foo() {}
auto bar() { return foo(); }
static assert(is(typeof(bar()) == void));

[9rnsr]

Yes. In that case, the common type is deduced tovoid. That's intended behavior.

[MartinNowak]

What could that paragraph possibly mean?
It was added with d0a87f8.

[9rnsr]

This paragraph means that all use of "storage classes" (syntactically equivalent with "attributes") can make the function an auto-function.

const foo() {}   // auto-function
pure nothrow foo() {}   // auto-function

If there's no storage class, you should use auto to declare auto-function.

auto foo() {}

[MartinNowak]

Ah right, that's how to explain something. First tell people about exceptional cases, then declare the normal usage as exception of the exception :).