viboes wrote:

> Hi,
>
> issue 921. "Rational Arithmetic should use template aliases" had as
> resolution the change of ratio arithmetic metafunctions to template
> aliases.
>
> There are other metafunctions that could follow the same change, as
> for example in
> 20.4.2.1
>
> template <size_t I, class... Types>
> class tuple_element<I, tuple<Types...> > {
> public:
>  typedef TI type;
> };
>
> and all the transformation traits in 20.7 and in particular
> common_type.
>
> Is there a rationale to prefer one technique or the other?
>

For the transformations, you may not want to immediately have the type they
transform to to be formed. For example:

   typedef conditional<is_foo<T>::value, bar<T>, baz<T>>::type::type

If for some reason the type that bar<T> transforms to is not compatible with
T but works for baz<T>, the above compiles But if "bar<T>" would be
equivalen to "bar_impl<T>::type", you will get a compile-time error.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 16, 12:13=A0am, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
wrote:
> On 15 Sep., 20:04, viboes <vicente.bo...@wanadoo.fr> wrote:
>
>
>
> > issue 921. "Rational Arithmetic should use template aliases" had as
> > resolution the change of ratio arithmetic metafunctions to template
> > aliases.
>
[...]
> > Is there a rationale to prefer one technique or the other?
>
> Yes: A specific difference is that template alias cannot
> be specialized - which is very advantageous for a designer
> of a type family: There is no reason to allow user-code to
> specialize std::ratio, for example.
>
> std::tuple_element and std::common_type are just the opposite
> examples: You *want* to grant user-code the permission to
> specialize these templates for user-defined tuple-like types
> and for user-defined conversion-relations!
>
> There is at least one place in the standard library, where more
> usage of template alias would have been useful: The built-in
> type-traits should be made template alias as an additional
> protection against user-code attempting to specialize them
> (thus your above mentioned transformation traits).

Thanks for the clear explanation.

Vicente

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,

issue 921. "Rational Arithmetic should use template aliases" had as
resolution the change of ratio arithmetic metafunctions to template
aliases.

There are other metafunctions that could follow the same change, as
for example in
20.4.2.1

template <size_t I, class... Types>
class tuple_element<I, tuple<Types...> > {
public:
 typedef TI type;
};

and all the transformation traits in 20.7 and in particular
common_type.

Is there a rationale to prefer one technique or the other?

--
Vicente

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 15 Sep., 20:04, viboes <vicente.bo...@wanadoo.fr> wrote:
> issue 921. "Rational Arithmetic should use template aliases" had as
> resolution the change of ratio arithmetic metafunctions to template
> aliases.
>
> There are other metafunctions that could follow the same change, as
> for example in 20.4.2.1
>
> template <size_t I, class... Types>
> class tuple_element<I, tuple<Types...> > {
> public:
>  typedef TI type;
> };
>
> and all the transformation traits in 20.7 and in particular
> common_type.
>
> Is there a rationale to prefer one technique or the other?

Yes: A specific difference is that template alias cannot
be specialized - which is very advantageous for a designer
of a type family: There is no reason to allow user-code to
specialize std::ratio, for example.

std::tuple_element and std::common_type are just the opposite
examples: You *want* to grant user-code the permission to
specialize these templates for user-defined tuple-like types
and for user-defined conversion-relations!

There is at least one place in the standard library, where more
usage of template alias would have been useful: The built-in
type-traits should be made template alias as an additional
protection against user-code attempting to specialize them
(thus your above mentioned transformation traits).

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 15, 1:04=A0pm, viboes <vicente.bo...@wanadoo.fr> wrote:
> Is there a rationale to prefer one technique or the other?

One is more elegant and the other is more backward-compatible.

Considering that template aliases are unsupported by any current
compiler (http://wiki.apache.org/stdcxx/C++0xCompilerSupport),
"backward-compatible" might be an understatement.

If the new syntax can be shoehorned into the old, maybe we will see it
in C++2x. Any proposals?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]