Hi,

the template future<T> doesn't name its template parameter. If we added
it to the standard, should it be named value_type or element_type? What
has been the criteria on the standard to name this kind of typedefs.

Is there any interest on adding it to the standard?

Best,
Vicente

--

---
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/?hl=en.



.

2013/5/23 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
> Hi,
>
> the template future<T> doesn't name its template parameter.

... and similar for promise, shared_future, and packaged_task.

> If we added it
> to the standard, should it be named value_type or element_type? What has
> been the criteria on the standard to name this kind of typedefs.

Please don't use element_type. First, there is nothing in the
nomenclature of the future-types that refers to an "element". To my
knowledge, smart pointers have used this typedef since std::auto_ptr,
so we stuck with it for the new ones (not because it was necessarily a
good choice).

value_type seems possible.

We /may/ want to check that it is the right term for these kind of
templates and the asymmetric nature of the "value type". Possible
might also be "in[put]_type" and "out[put]_type" according to the role
of the template. (packaged_task is very special here, we may want to
leave it out).

One further argument that value_type might be OK is that we use it
also for allocators that are not really containers and promise in
particular has a "set_value" function.

Funnily all these template (not packaged_task) use a template
parameter name R, that may indicate that the originally intended
naming was more related to "results". The code comments often refer to
"result" here, but I tend to say that result_type could be quite
confusing with functors.

> Is there any interest on adding it to the standard?

I think it would be useful to have them (maybe considering
packaged_task  as separate), especially since would not impose further
constraints upon type completeness. It recently turned out that
requiring the result_type (argument_type, ...) had the unfortunate
side effect to require that template parameter T is a complete type.
Boost's reference_wrapper works pretty well with incomplete types, but
we could only realize that, when giving up these typedefs in
reference_wrapper.

- Daniel

--

---
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/?hl=en.



.

Le 23/05/13 08:43, Daniel Kr=FCgler a =E9crit :
> 2013/5/23 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
>> Hi,
>>
>> the template future<T> doesn't name its template parameter.
> .. and similar for promise, shared_future, and packaged_task.
>
>> If we added it
>> to the standard, should it be named value_type or element_type? What has
>> been the criteria on the standard to name this kind of typedefs.
> Please don't use element_type. First, there is nothing in the
> nomenclature of the future-types that refers to an "element". To my
> knowledge, smart pointers have used this typedef since std::auto_ptr,
> so we stuck with it for the new ones (not because it was necessarily a
> good choice).
>
> value_type seems possible.
>
> We /may/ want to check that it is the right term for these kind of
> templates and the asymmetric nature of the "value type". Possible
> might also be "in[put]_type" and "out[put]_type" according to the role
> of the template. (packaged_task is very special here, we may want to
> leave it out).
>
> One further argument that value_type might be OK is that we use it
> also for allocators that are not really containers and promise in
> particular has a "set_value" function.
>
> Funnily all these template (not packaged_task) use a template
> parameter name R, that may indicate that the originally intended
> naming was more related to "results". The code comments often refer to
> "result" here, but I tend to say that result_type could be quite
> confusing with functors.
>
>> Is there any interest on adding it to the standard?
> I think it would be useful to have them (maybe considering
> packaged_task  as separate), especially since would not impose further
> constraints upon type completeness. It recently turned out that
> requiring the result_type (argument_type, ...) had the unfortunate
> side effect to require that template parameter T is a complete type.
> Boost's reference_wrapper works pretty well with incomplete types, but
> we could only realize that, when giving up these typedefs in
> reference_wrapper.
>
>
Should I write an issue or a very very short proposal?

Best,
Vicente

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

2013/6/7 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
> Le 23/05/13 08:43, Daniel Kr=FCgler a =E9crit :
>
>> 2013/5/23 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
>>>
>>> Hi,
>>>
>>> the template future<T> doesn't name its template parameter.
>>
>> .. and similar for promise, shared_future, and packaged_task.
>>
>>> If we added it
>>> to the standard, should it be named value_type or element_type? What ha=
s
>>> been the criteria on the standard to name this kind of typedefs.
>>
>> Please don't use element_type. First, there is nothing in the
>> nomenclature of the future-types that refers to an "element". To my
>> knowledge, smart pointers have used this typedef since std::auto_ptr,
>> so we stuck with it for the new ones (not because it was necessarily a
>> good choice).
>>
>> value_type seems possible.
>>
>> We /may/ want to check that it is the right term for these kind of
>> templates and the asymmetric nature of the "value type". Possible
>> might also be "in[put]_type" and "out[put]_type" according to the role
>> of the template. (packaged_task is very special here, we may want to
>> leave it out).
>>
>> One further argument that value_type might be OK is that we use it
>> also for allocators that are not really containers and promise in
>> particular has a "set_value" function.
>>
>> Funnily all these template (not packaged_task) use a template
>> parameter name R, that may indicate that the originally intended
>> naming was more related to "results". The code comments often refer to
>> "result" here, but I tend to say that result_type could be quite
>> confusing with functors.
>>
>>> Is there any interest on adding it to the standard?
>>
>> I think it would be useful to have them (maybe considering
>> packaged_task  as separate), especially since would not impose further
>> constraints upon type completeness. It recently turned out that
>> requiring the result_type (argument_type, ...) had the unfortunate
>> side effect to require that template parameter T is a complete type.
>> Boost's reference_wrapper works pretty well with incomplete types, but
>> we could only realize that, when giving up these typedefs in
>> reference_wrapper.
>>
>>
> Should I write an issue or a very very short proposal?

I see nothing here that would provide a base for an issue, it looks
like a pure extension and so a (short) proposal should be the
appropriate way to solve that.

- Daniel

--=20

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



.