> My main concern is the placeholder in the return type. From what I can see,
> the answer is no, as it's not listed in 7.1.6.5/1, although I'm not sure why
> this is so. Sure, a return type alone can't be deduced, but we can still
> check it when explicitly instantiating the template. And if the placeholder
> in the return type is the same as any in the parameter list, it should share
> the same invented template parameter, and so then can be deduced.
The question is whether the deduction should then happen before the constraint
check or after the constraint check, which affects whether the overload SFINAEs
or not. To make things simple, that question doesn't arise because such uses
are simply forbidden.
> Checking the requirement on deducted return type will require return type to
> be deduced during overload resolution, as the failure in fulfilling
> constrain should eliminate function from set of viable candidates. But in
> current wording, the failure in deduction of return type is hard error,
> instead of SFINEA. So with that resolution, if during the overload
> resolution for one of the candidate return type deduction will result in
> invalid declaration,hard error will occur, instead of candidate being
> removed from overload set.
This is my understanding, and why I very much dislike deduced return
types. The totally conflate the separation of interface and
implementation, which turns out to have some negative impact on other
language features.
My advice? Declare the return type of your functions.
Incidentally, I think that the "same-template-parameter" rule needs to
be extended for return types so that this:
Iterator f(Iterator, Iterator);
is equivalent to this:
template<Iterator I> I f(I, I);
I think that was mentioned in a previous email though.
On Friday, January 30, 2015 at 9:01:22 AM UTC-5, Andrew Sutton wrote:> Checking the requirement on deducted return type will require return type to
> be deduced during overload resolution, as the failure in fulfilling
> constrain should eliminate function from set of viable candidates. But in
> current wording, the failure in deduction of return type is hard error,
> instead of SFINEA. So with that resolution, if during the overload
> resolution for one of the candidate return type deduction will result in
> invalid declaration,hard error will occur, instead of candidate being
> removed from overload set.
This is my understanding, and why I very much dislike deduced return
types. The totally conflate the separation of interface and
implementation, which turns out to have some negative impact on other
language features.
My advice? Declare the return type of your functions.
Incidentally, I think that the "same-template-parameter" rule needs to
be extended for return types so that this:
Iterator f(Iterator, Iterator);
is equivalent to this:
template<Iterator I> I f(I, I);
I think that was mentioned in a previous email though.
Andrew
Have these rules changed at all? The latest version of gcc allows you to place constraints on return-types (http://melpon.org/wandbox/permlink/LRrm5sqkWy7faqUO)
--
You received this message because you are subscribed to the Google Groups "SG8 - Concepts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concepts+u...@isocpp.org.
To post to this group, send email to conc...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/concepts/.
This doesn't work now?
It is intended to be supported.
Suggestions on how to improve wording are welcome.
--