When users write futures code, if the user saves a future in a local variable, they tend to write code like this:

    auto future = getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        });

This is the proper way to write that code. If, however, they want to ignore the result of that future chain, they might instead write:

    getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        })
        .getAsync([](auto) {});

This is correct semantically, but unfortunately, in the case where getFuture returns an ExecutorFuture, this getAsync call will result in an extra call to schedule on the executor even though the lambda is empty and does nothing.

In the past, such code is met with comments to do

    getFuture()
        .getAsync([](StatusWith<T> swVal) {
            if (swVal.isOK()) {
                // Handle success
            } else {
                // Handle error
            }
        });

In my view this is unfortunate given how it differs from the way that we typically formulate future chains, as in the first example.

It has also been deemed inappropriate to simply do a void cast:

    (void)getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        });

We should come up with an idiomatic way to handle this scenario and allow the API to be consistent with normal future chain usage.