On Tue, Oct 31, 2017 at 5:31 PM, Arthur O'Dwyer
<arthur.j.odwyer@gmail.com> wrote:
> On Tuesday, October 31, 2017 at 11:19:22 AM UTC-7, Zhihao Yuan wrote:
>>
>> I was being asked about this question during CppCon,
>> and I answered "no concrete solution emerged".  Here
>> is an idea I got recently.
>
>
> Can you explain the question, please?
>
> When I hear "partial specialization, CTAD, no solution", I immediately think
> of this fiasco:
>
>     template<class> struct Foo;  // notice the lack of explicit deduction
> guides
>
>     template<class T>
>     struct Foo<T*> {
>         Foo(T&);
>     };
>
>     int i;
>     Foo f(i);  // "obviously" we want Foo<int*>, but in C++17 this is not
> deducible
>

Why not just iterate through all the partial specializations visible
at the point of deduction - iterating through all their constructors
to generate deduction function templates - and do the same for
explicit specializations (adding non-function templates) - and add
them to all the function templates generated from the primary
template's constructors and deduction-guides.  We would need to add
some tie-breakers to the overload resolution process here (such as a
function template from the most specialized specialization (if
orderable) always wins regardless of how specialized it otherwise is,
or only wins if the function-templates are otherwise unorderable -
we'd need to think through this).  If we do decide to do something
along these lines - (which I think we should strongly consider
exploring) - I wonder how much backwards compatibility will constrain
us here.

So as a (hopefully) simple example:

template<class T> struct Foo { Foo(T&&); }
template<class T> struct Foo<T*> { Foo(T&); };
template<> struct Foo<int&> { Foo(int&); };

Generates the following notional guides from the above constructors:

template<class T> Foo(T&&) ->Foo<T>;     //#1
template<class T> Foo(T&) -> Foo<T*>;  // #2
Foo(int&) -> Foo<int&>;                            //#3

int I;
Foo f{I}; // deduces Foo<int&> from #3

char C;
Foo f2{C}; // deduces Foo<char *> from #2

Foo f3{&C}; // deduce Foo<char *> frfom #1.

--
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+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABsSThqw9bJ7Ld60ExH%3D%3D0FrxN4un9Cur7-OS2gxTCe39JvuMg%40mail.gmail.com.

.

On Tue, Oct 31, 2017 at 7:54 PM, Faisal Vali <faisalv@gmail.com> wrote:
> On Tue, Oct 31, 2017 at 5:31 PM, Arthur O'Dwyer
> <arthur.j.odwyer@gmail.com> wrote:
>> On Tuesday, October 31, 2017 at 11:19:22 AM UTC-7, Zhihao Yuan wrote:
>>>
>>> I was being asked about this question during CppCon,
>>> and I answered "no concrete solution emerged".  Here
>>> is an idea I got recently.
>>
>>
>> Can you explain the question, please?
>>
>> When I hear "partial specialization, CTAD, no solution", I immediately think
>> of this fiasco:
>>
>>     template<class> struct Foo;  // notice the lack of explicit deduction
>> guides
>>
>>     template<class T>
>>     struct Foo<T*> {
>>         Foo(T&);
>>     };
>>
>>     int i;
>>     Foo f(i);  // "obviously" we want Foo<int*>, but in C++17 this is not
>> deducible
>>
>
> Why not just iterate through all the partial specializations visible
> at the point of deduction - iterating through all their constructors
> to generate deduction function templates - and do the same for
> explicit specializations (adding non-function templates) - and add
> them to all the function templates generated from the primary
> template's constructors and deduction-guides.  We would need to add
> some tie-breakers to the overload resolution process here (such as a
> function template from the most specialized specialization (if
> orderable) always wins regardless of how specialized it otherwise is,
> or only wins if the function-templates are otherwise unorderable -
> we'd need to think through this).  If we do decide to do something
> along these lines - (which I think we should strongly consider
> exploring) - I wonder how much backwards compatibility will constrain
> us here.
>
> So as a (hopefully) simple example:
>
> template<class T> struct Foo { Foo(T&&); }
> template<class T> struct Foo<T*> { Foo(T&); };
> template<> struct Foo<int&> { Foo(int&); };
>
> Generates the following notional guides from the above constructors:
>
> template<class T> Foo(T&&) ->Foo<T>;     //#1
> template<class T> Foo(T&) -> Foo<T*>;  // #2
> Foo(int&) -> Foo<int&>;                            //#3
>
> int I;
> Foo f{I}; // deduces Foo<int&> from #3
>
> char C;
> Foo f2{C}; // deduces Foo<char *> from #2
>
> Foo f3{&C}; // deduce Foo<char *> frfom #1.

Oh and following CTAD - the construct will be ill-formed because it
uses the partial specialization whose constructor would reject the
construction.

--
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+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABsSThqoV9%3DB%3D%3D-nSzAeWxHU2sOrOB3wbj7rYPuOrOMa3zfiyw%40mail.gmail.com.

.

On Tue, Oct 31, 2017 at 8:24 PM, Arthur O'Dwyer
<arthur.j.odwyer@gmail.com> wrote:
> On Tue, Oct 31, 2017 at 3:58 PM, Zhihao Yuan <zy@miator.net> wrote:
>>
>> On Tue, Oct 31, 2017 at 5:31 PM, Arthur O'Dwyer
>> <arthur.j.odwyer@gmail.com> wrote:
>>>
>>> Can you explain the question, please?
>>>
>>> When I hear "partial specialization, CTAD, no solution", I immediately
>>> think of this fiasco:
>>>
>>>     template<class> struct Foo;  // notice the lack of explicit deducti=
on
>>> guides
>>>
>>>     template<class T>
>>>     struct Foo<T*> {
>>
>>
>> I used a wrong term... What I mean is to deduce from a
>> _simple-template-id_, like this
>>
>>   tuple<string> t("str", 1);  // first element std::string
>
>
> Oh, okay. That seems insane. It's one thing to have "tuple" secretly mean
> "tuple<string, int>". It's quite another to have "tuple<string>" secretly
> mean "tuple<string, int>".
>

This seems to be a matter of taste.  There were some use cases where
it made sense to explicitly specify certain template arguments and
deduce the rest (like we do with some function templates).  This
potentially becomes even more useful if we every allow deduction
through template aliases (which would allow us to explicitly specify
arguments such as allocators etc. no matter where they are in the
declaration order).  Mike originally intended this to work - but we
pulled it because of some concerns regarding backwards compatibility.

I'm not saying the idea of partial-template-id's is a slam dunk - and
I expect sensible folk to question its justification - but blanketly
labeling it as insane suggests a very narrow (and potentially not v
useful) definition of sanity ;)

> =E2=80=93Arthur
>
> --
> 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+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L2Sx6=
XJeH_0vo7eYRTBPe%2BuTSdyZNGa9n7BuMB4DoZgQ%40mail.gmail.com.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CABsSThp%3DBncn5Nan5Q9LSJB0sq-_rDbFDw_VMv8gcai_O=
D_JyQ%40mail.gmail.com.

.