I love auto, it makes my life easier. The compiler infers what it can and I primarily enjoy the bonuses of @safe without having to annotate it manually.

But it's not always applicable.

1. Some functions I would normally declare as returning void that have return statements that should implicitly discard their return values.

string forTheSakeOfImpurity;
int alsoForTheSakeOfImpurity;

string setString()
{
    forTheSakeOfImpurity = "blah";
    return forTheSakeOfImpurity;
}

int setInt()
{
    alsoForTheSakeOfImpurity = 42;
    return alsoForTheSakeOfImpurity;
}

auto foo(bool condition)
{
    if (condition) return setString();
    else return setInt();
}

/*
onlineapp.d(20): Error: expected return type of `string`, not `int`:
onlineapp.d(19):        Return type of `string` inferred here.
 */

Can be worked around by making it return cast(void) everywhere, but I'm appealing here to not have to.

2. Some functions that I want to coerce the return value of to a specific type. Related to point 1.

string bar() pure
{
    Appender!(char[]) sink;
    // ...
    return sink[];
}

auto baz()
{
    Appender!(char[]) sink;
    // ...
    return sink[];
}

static assert(is(ReturnType!bar == string));
static assert(!is(ReturnType!baz == string));  // :c

3. Any void function that I don't want the tooling to nag about.

auto foo() {}

/*
asdf.d(3:1)[warn]: Auto function without return statement, prefer replacing auto with void
 */

Can we please have void foo() auto? It would behave as auto foo() does, except enforce the return type. As a bonus we'd also get string bar() auto.

Yes, I can make it string foo()(). I can even return cast(string)sink[]. There are technically workarounds for all of this; I'm just trying to make the case for repurposing the neat shortcut we already have in place.

On Thursday, 27 July 2023 at 15:22:45 UTC, Anonymouse wrote:

IMO the correct solution is to just make the compiler infer attributes like @safe for all functions, with exceptions only in cases like extern (C) or virtual class/interface methods where the full implementation is not available, or if the user explicitly opts out (e.g., with something like @noinfer).

I have a half-written draft DIP for this that I plan to get back to once Mike Parker announces that the DIP queue is open again. If anyone else is working on this or wants to collaborate, please let me know!

On Thursday, 27 July 2023 at 18:55:25 UTC, Paul Backus wrote:

Or if the function doesn't have a body?

On Thursday, 27 July 2023 at 19:21:40 UTC, jmh530 wrote:

Yes, naturally. Here's what I've got written down so far:

https://github.com/pbackus/DIPs/blob/universal-attribute-inference/DIPs/1NNN-PJB.md

On Thursday, 27 July 2023 at 15:22:45 UTC, Anonymouse wrote:

auto foo() {}

/*
asdf.d(3:1)[warn]: Auto function without return statement, prefer replacing auto with void
 */

For this you can (and should) open a D-Scanner PR that proposes to deactivate the check by default. The rationale for this check (IIRC) is that if you have an asm block that returns something then the compiler infers void as return type. A quite rare case actually... Unfortunately I did not thought to the attribute problem when I wrote the check, a long time ago.

On 7/27/23 2:55 PM, Paul Backus wrote:

I think it would be nicer to specify exact attributes than to "opt out" of inference.

For e.g. @safe, we are covered, because there is @system. For nothrow, there is throw (I think?). But for @nogc and pure, there is no opposite.

I would like to see some mechanism or additional attributes that make it so you can specify what should not be inferred before turning on full inference.

One large problem with all this is people who "don't care" about attributes. Of course, now their code will infer attributes! But that has become part of the public API. If they change something to change the attribute inference, all of a sudden code that is marked explicitly will stop compiling, and the author will say "too bad, not my fault".

I think the only way to fix this is to only infer when explicitly stated.

And to that effect... we could just make the storage class auto mean that, like the OP says.

I mean, we already allow static void foo(), why not auto void foo()?

If I do auto void foo() {} it complains:

Error: function `onlineapp.foo` storage class `auto` has no effect if return type is not inferred

Well, let's make it... have an effect.

-Steve