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. <> wrote:
See .

In brief: this was proposed and discussed, but it was believed that the complexity does not match the benefit.