Discussion:
[std-proposals] Template Argument Deduction for call to a base class constructor
m***@gmail.com
2018-11-14 20:32:42 UTC
Permalink
Consider


template<class T>
struct A
{
A(T) {}
};

template<class T>
struct B : A<T>
{
B(T t, int i)
: A(t) //< nope
{}
};

int main()
{
A c(12); //< yep
}


This case is not considered in p1021
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html>. Any
reason what this might be? An omission, a technical issue?
Because sooner or later people will wonder why it works in one context and
not in other.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/16f99f8f-6596-4450-98f8-1bd7332cb21c%40isocpp.org.
Barry Revzin
2018-11-14 21:20:33 UTC
Permalink
Post by m***@gmail.com
This case is not considered in p1021
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html>.
Any reason what this might be? An omission, a technical issue?
Because sooner or later people will wonder why it works in one context and
not in other.
Those are pretty different things, despite having the same syntax. In the
mem-initializer list, we already know what the thing we're constructing is
- it would very strange if at that point we stopped and redid overload
resolution to re-figure out what it is we're already in the process of
constructing. What if it happens to give you a different answer?

You can already directly use A<T> there, access the injected-class-name via
B::A.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/36736629-55ad-4f98-94c7-87c36bbd2ad7%40isocpp.org.
m***@gmail.com
2018-11-15 17:46:33 UTC
Permalink
Post by Barry Revzin
Post by m***@gmail.com
This case is not considered in p1021
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html>.
Any reason what this might be? An omission, a technical issue?
Because sooner or later people will wonder why it works in one context
and not in other.
Those are pretty different things, despite having the same syntax. In the
mem-initializer list, we already know what the thing we're constructing is
- it would very strange if at that point we stopped and redid overload
resolution to re-figure out what it is we're already in the process of
constructing. What if it happens to give you a different answer?
You can already directly use A<T> there, access the injected-class-name
via B::A.
Yeah, they are different but both are a construction call and this
situation will rise stackoverflow questions for sure.

Is there a problem to resolve to B::A, if it wold fail otherwise? This will
make calls consistent with the expectations, though behind the scenes the
technicalities might be different.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e33edec4-d037-4b80-b0f7-c7e73f9321ec%40isocpp.org.
Loading...