On Mar 5, 2015, at 8:50 PM, Andrew Sutton <asutton.list@gmail.com> wrote:

>>> template<typename ForwardIterator>
>>>  ForwardIterator next(ForwardIterator);
>>>
>>> but that's still true if it's rewritten like this:
>>>
>>> ForwardIterator next(ForwardIterator);
>>
>>
>> That's not what I'm objecting to; I'm objecting to "auto" specifically. But
>> since you mention it, this version definitely conveys less information than
>> the previous one: it obscures the critical fact that 'next' is a function
>> template.
>
> Out of curiosity, why is next's template-ness a critical fact?
>
> I've been writing a fair amount of C lately (and sadly). Many of the
> functions I use turn out to be macros. I don't consider that to be a
> critical fact. And when I'm writing C++, I generally don't care that
> something I call is a template, only that there's an overload that
> matches the arguments I call it with.
>
> I've heard this argument before. I've yet to hear a good answer.
>

I don't think it is very important to the caller, but where next is defined it is important to those maintaining the code.

If ForwardIterator is a constrained-type-specifier, then next is a template, but if ForwardIterator is a type, it is not a template.

At least with "auto" you can figure out from the presence of "auto" that the function is a template.

I agree that the TS is a good chance to get experience and see what people like and don't like, provided that people don't use compatibility with what was specified in the TS for not changing a feature.

One possibility if we wanted some more syntax would be to require a template-introduction (14.2 in the Concepts TS) when a constrained-type-specifier is used, so next would be:

 ForwardIterator{T} T next(T);

which, in this case, is shorter than the form without the template introduction.

John.



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.