Thanks to both for the reference to this, I wasn't able to find it when I
searched the archives.

>From what I understand, this was not strongly rejected. People had
concerns, and from what I read most of them exist in the language as of now
(ODR violations, class layout which might change, etc.). The real worry was
that when introduced, `auto` NSDMs will increase their occurrence.

My most frequent usage for this, which was not explicitly mentioned, is
when writing a class which has members that hold references to other
members:

template<typename T1, typename T2>
struct DataOwner
{
    C c{};
    T1 t1{};
    T2 t2{};

    auto foo = makeFoo(FooArg{t1});
    auto bar = makeBar(foo, BarArg{t2, c}); // bar holds ref to foo
    auto baz = makeBaz(foo, bar); // baz holds ref to foo and baz
};

Writing it without `auto` already requires usage of decltype, and that
solution suffers from most of the problems pointed out in the discussion.
Additional problem with decltype approach is that it reduces
maintainability, since you'd have to make changes both to initializer and
the `decltype` statement.
That is why we introduced a macro for this.

A number of years have passed since the initial discussion, so people might
feel differently about this now?
Maybe modules will reduce the problems with ODR violations?

On Thu, 14 Nov 2019 at 12:09, Tam S. B. <cpplearner_at_[hidden]> wrote:

> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html .
>
> In brief: this was proposed and discussed, but it was believed that the
> complexity does not match the benefit.