Topic: Request for interest: template constexpr variables
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 10 Feb 2013 19:51:56 +0100
Raw View
This is a multi-part message in MIME format.
--------------040007090200010501060702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I would like to see if there is an interest for a template constexpr
variable extension to C++. Sorry if someting like that is already
proposed or even already in C++11.
*Motivation*
Currently when we need to define a constexpr variable we use a template
class and add a static constexpr variable, e.g.
template <typename T>
struct Equality_comparable {
static constexpr bool value =
has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&
has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;
};
Its use is as follows
Equality_comparable<int>::value
An alternative is to use a constexpr template nullary function
template <typename T>
constexpr bool EqualityComparable() {
return
has_eq<T>::value && Convertible<eq_result<T>, bool>() &&
has_neq<T>::value && Convertible<neq_result<T>, bool>();
};
Its use is as follows
Equality_comparable<int>()
C++11 introduced alias templates to overcome the use of nested typedefs
'type'.
*Proposal*
Allowing /template constexpr variables/ could leverage the syntactic
noise needed by these two approaches. E.g.
template <typename T>
constexpr bool EqualityComparable =
has_eq<T>::value && Convertible<eq_result<T>, bool> &&
has_neq<T>::value && Convertible<neq_result<T>, bool>;
};
*Application**
*
This can be used to simplify the Concept-lite syntax of the requires
clause as well as to define mathematical constants as in
template <typename T>
constexpr T pi = ...;
used as
f(pi<double>);
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.
--------------040007090200010501060702
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
I would like to see if there is an interest for a template constexpr
variable extension to C++. Sorry if someting like that is already
proposed or even already in C++11.<br>
<br>
<b>Motivation</b><br>
Currently when we need to define a constexpr variable we use a
template class and add a static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value = <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value;
<br>
};<br>
<br>
Its use is as follows <br>
<br>
Equality_comparable<int>::value<br>
<br>
An alternative is to use a constexpr template nullary function <br>
<br>
template <typename T><br>
constexpr bool EqualityComparable() {<br>
return<br>
has_eq<T>::value &&
Convertible<eq_result<T>, bool>()
&& <br>
has_neq<T>::value &&
Convertible<neq_result<T>, bool>();
<br>
};<br>
<br>
Its use is as follows <br>
<br>
Equality_comparable<int>()<br>
<br>
C++11 introduced alias templates to overcome the use of nested
typedefs 'type'.<br>
<br>
<b>Proposal</b><br>
<br>
Allowing <i>template constexpr variables</i> could leverage the
syntactic noise needed by these two approaches. E.g.<br>
<br>
template <typename T><br>
constexpr bool EqualityComparable =<br>
has_eq<T>::value &&
Convertible<eq_result<T>, bool>
&& <br>
has_neq<T>::value &&
Convertible<neq_result<T>, bool>;
<br>
};<br>
<br>
<b>Application</b><b><br>
</b><br>
This can be used to simplify the Concept-lite syntax of the requires
clause as well as to define mathematical constants as in<br>
<br>
template <typename T><br>
constexpr T pi = ...;<br>
<br>
used as<br>
<br>
f(pi<double>);<br>
<br>
<br>
Best,<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------040007090200010501060702--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Sun, 10 Feb 2013 19:58:51 +0100
Raw View
On 10 February 2013 19:51:56, Vicente J. Botet Escriba wrote:
> Hi,
>
> I would like to see if there is an interest for a template constexpr
> variable extension to C++. Sorry if someting like that is already
> proposed or even already in C++11.
>
> *Motivation*
> Currently when we need to define a constexpr variable we use a
> template class and add a static constexpr variable, e.g.
>
> template <typename T>
> struct Equality_comparable {
> static constexpr bool value =3D
> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&
> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;
> };
>
> Its use is as follows
>
> Equality_comparable<int>::value
I write it as follows:
struct Equality_comparable : std::integral_constant<bool,
has_eq<T>() && is_convertible<eq_result<T>, bool>() &&
has_neq<T>() && is_convertible<neq_result<T>, bool>()>
{};
And I use it as follows:
Equality_comparable<int>()
This works because integral_constant<T, X> has a constexpr conversion=20
to T that returns X.
I think this is quite an acceptable state of affairs and no more=20
improvement is needed.
--
Mit freundlichen Gr=FC=DFen,
Martinho Fernandes
--=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.
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Sun, 10 Feb 2013 20:02:41 +0100
Raw View
On 10 February 2013 19:58:51, Martinho Fernandes wrote:
> On 10 February 2013 19:51:56, Vicente J. Botet Escriba wrote:
>> Hi,
>>
>> I would like to see if there is an interest for a template constexpr
>> variable extension to C++. Sorry if someting like that is already
>> proposed or even already in C++11.
>>
>> *Motivation*
>> Currently when we need to define a constexpr variable we use a
>> template class and add a static constexpr variable, e.g.
>>
>> template <typename T>
>> struct Equality_comparable {
>> static constexpr bool value =3D
>> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&
>> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;
>> };
>>
>> Its use is as follows
>>
>> Equality_comparable<int>::value
>
> I write it as follows:
>
> struct Equality_comparable : std::integral_constant<bool,
> has_eq<T>() && is_convertible<eq_result<T>, bool>() &&
> has_neq<T>() && is_convertible<neq_result<T>, bool>()>
> {};
>
> And I use it as follows:
>
> Equality_comparable<int>()
>
> This works because integral_constant<T, X> has a constexpr conversion
> to T that returns X.
>
> I think this is quite an acceptable state of affairs and no more
> improvement is needed.
>
> --
> Mit freundlichen Gr=FC=DFen,
>
> Martinho Fernandes
I'll also mention that deriving from integral_constant<T, X> also=20
provides a ::type member alias to integral_constant<T, X>, which is=20
useful in some TMP scenarios. All the standard type traits derive from=20
integral_constant, and so should yours.
--
Mit freundlichen Gr=FC=DFen,
Martinho Fernandes
--=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.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 15 Feb 2013 07:44:40 +0100
Raw View
Le 10/02/13 19:58, Martinho Fernandes a =E9crit :
> On 10 February 2013 19:51:56, Vicente J. Botet Escriba wrote:
>> Hi,
>>
>> I would like to see if there is an interest for a template constexpr
>> variable extension to C++. Sorry if someting like that is already
>> proposed or even already in C++11.
>>
>> *Motivation*
>> Currently when we need to define a constexpr variable we use a
>> template class and add a static constexpr variable, e.g.
>>
>> template <typename T>
>> struct Equality_comparable {
>> static constexpr bool value =3D
>> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&
>> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;
>> };
>>
>> Its use is as follows
>>
>> Equality_comparable<int>::value
>
> I write it as follows:
>
> struct Equality_comparable : std::integral_constant<bool,
> has_eq<T>() && is_convertible<eq_result<T>, bool>() &&
> has_neq<T>() && is_convertible<neq_result<T>, bool>()>
> {};
>
> And I use it as follows:
>
> Equality_comparable<int>()
>
> This works because integral_constant<T, X> has a constexpr conversion=20
> to T that returns X.
>
You are right. I forget to mention this possibility. Anyway this has the=20
same syntax as the constexpr template function.
> I think this is quite an acceptable state of affairs and no more=20
> improvement is needed.
>
I agree that it could be acceptable as it was quite acceptable to use
eq_result<T>::type
and alias template were added.
Why are you against this simple proposal?
If already present wouldn't you use it?
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.
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Fri, 15 Feb 2013 10:10:53 +0100
Raw View
On 15 February 2013 07:44:40, Vicente J. Botet Escriba wrote:
> I agree that it could be acceptable as it was quite acceptable to use
>
> eq_result<T>::type
>
> and alias template were added.
>
> Why are you against this simple proposal?
> If already present wouldn't you use it?
>
> Vicente
>
Of course I would use it if it was there. But it isn't. Adding it means=20
adding yet one more different kind of entity to C++ and it saves you a=20
pair of parentheses. I don't think it is worth it.
--
Mit freundlichen Gr=FC=DFen,
Martinho Fernandes
--=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.
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Fri, 15 Feb 2013 03:35:19 -0800 (PST)
Raw View
------=_Part_9_27455309.1360928119859
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet Escriba=20
wrote:
>
> Currently when we need to define a constexpr variable we use a template=
=20
> class and add a static constexpr variable, e.g.
>
> template <typename T>
> struct Equality_comparable {
> static constexpr bool value =3D=20
> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&=20
> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;=20
> };
>
Such implementation doesn't look sensible. If has_eq<T>::value evaluates to=
=20
false, what type should eq_result<T> designate? If eq_result<T> is=20
ill-formed, then the whole expression is ill-formed. What we actually need=
=20
here is something like is_well_formed operator.
template <bool C>
using bool_constant =3D std::integral_constant<bool, C>;
template <class T, class U>
struct equality_comparable_with :
bool_constant
<
is_well_formed
{
bool b1 =3D std::declval<T>() =3D=3D std::declval<U>();
bool b2 =3D std::declval<T>() !=3D std::declval<U>();
}
> {};
template <class T>
struct equality_comparable :
equality_comparable_with<T const &, T const &> {};
On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. Botet Escriba=20
wrote:
>
> Le 10/02/13 19:58, Martinho Fernandes a =EF=BF=BDcrit :=20
>
> > I write it as follows:=20
> >=20
> > struct Equality_comparable : std::integral_constant<bool,=20
> > has_eq<T>() && is_convertible<eq_result<T>, bool>() &&=20
> > has_neq<T>() && is_convertible<neq_result<T>, bool>()>=20
> > {};=20
> >=20
> > And I use it as follows:=20
> >=20
> > Equality_comparable<int>()=20
> >=20
> > This works because integral_constant<T, X> has a constexpr conversion=
=20
> > to T that returns X.=20
> >=20
> You are right. I forget to mention this possibility. Anyway this has the=
=20
> same syntax as the constexpr template function.
Is () or {} too long for you?
> I think this is quite an acceptable state of affairs and no more=20
> > improvement is needed.=20
> >=20
> I agree that it could be acceptable as it was quite acceptable to use=20
>
> eq_result<T>::type
>
The difference between "typename eq_result<T>::type" and "eq_result<T>" is=
=20
much more visible than the difference between "equality_comparable<int>{}"=
=20
and "equality_comparable<int>".
If already present wouldn't you use it?
I wouldn't use it. Moreover, I would prefer not to define alias templates=
=20
for "typename Template<PAPAMS>::type" for purely cosmetic purposes and use=
=20
something like Template(PAPAMS) instead, so, for example
template <class T1, class T2>
struct is_decay_affined :
std::is_same<std::decay(T1), std::decay(T2)> {};
would be equivalent to
template <class T1, class T2>
struct is_decay_affined :
std::is_same
<
typename std::decay<T1>::type,
typename std::decay<T2>::type
> {};
--=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.
------=_Part_9_27455309.1360928119859
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet Escriba wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">
Currently when we need to define a constexpr variable we use a
template class and add a static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value =3D <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value;
<br>
};<br></div></blockquote><br>Such implementation doesn't look=20
sensible. If has_eq<T>::value evaluates to false, what type should
eq_result<T> designate? If eq_result<T> is ill-formed, then
the whole expression is ill-formed. What we actually need here is=20
something like is_well_formed operator.<br><br> template =
<bool C><br> using bool_con=
stant =3D std::integral_constant<bool, C>;<br><br> =
template <class T, class U><br> &n=
bsp; struct equality_comparable_with :<br> &nb=
sp; bool_constant<br> =
<<br> =
is_well_=
formed<br>  =
; {<br> &n=
bsp; bool=
b1 =3D std::declval<T>() =3D=3D std::declval<U>();<br> &n=
bsp;  =
; bool b2 =3D std::declval<T>() !=3D st=
d::declval<U>();<br> &=
nbsp; }<br> &nbs=
p; > {};<br><br> t=
emplate <class T><br> struc=
t equality_comparable :<br> =
equality_comparable_with<T const &, T const &=
> {};<br><br>On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. =
Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 10/02/1=
3 19:58, Martinho Fernandes a =EF=BF=BDcrit :
<br><br>> I write it as follows:
<br>>
<br>> struct Equality_comparable : std::integral_constant<bool,
<br>> has_eq<T>() && is_convertible<eq_res=
ult<T>, bool>() &&
<br>> has_neq<T>() && is_convertible<neq_r=
esult<T>, bool>()>
<br>> {};
<br>>
<br>> And I use it as follows:
<br>>
<br>> Equality_comparable<int>()
<br>>
<br>> This works because integral_constant<T, X> has a constexpr c=
onversion=20
<br>> to T that returns X.
<br>>
<br>You are right. I forget to mention this possibility. Anyway this has th=
e=20
<br>same syntax as the constexpr template function.</blockquote><div><br>Is=
() or {} too long for you?<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
> I think this is quite an acceptable state of affairs and no more=20
<br>> improvement is needed.
<br>>
<br>I agree that it could be acceptable as it was quite acceptable to use
<br>
<br> eq_result<T>::type<br></blockquote><div><br>The diff=
erence between "typename eq_result<T>::type" and "eq_result<=
T>" is much more visible than the difference between "equality_comparabl=
e<int>{}" and "equality_comparable<int>".<br> <br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">If already present wouldn't you use i=
t?</blockquote><div><br>I wouldn't use it. Moreover, I would prefer not to =
define alias templates for "typename Template<PAPAMS>::type" for pure=
ly cosmetic purposes and use something like Template(PAPAMS) instead, so, f=
or example<br><br> template <class T1, class T2><br=
> struct is_decay_affined :<br>&n=
bsp; std::is_sa=
me<std::decay(T1), std::decay(T2)> {};<br><br>would be equivalent to<=
br><br> template <class T1, class T2><br> &nbs=
p; struct is_decay_affined :<br> &=
nbsp; std::is_same<br> =
; <<br> =
; &n=
bsp; typename std::decay<T1>::type,<br> =
typename=
std::decay<T2>::type<br> &n=
bsp; > {};<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_9_27455309.1360928119859--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 15 Feb 2013 12:47:42 -0800 (PST)
Raw View
------=_Part_159_14694938.1360961262377
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, February 15, 2013 3:35:19 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet Escriba=
=20
> wrote:
>>
>> Currently when we need to define a constexpr variable we use a template=
=20
>> class and add a static constexpr variable, e.g.
>>
>> template <typename T>
>> struct Equality_comparable {
>> static constexpr bool value =3D=20
>> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&=20
>> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;=20
>> };
>>
>
> Such implementation doesn't look sensible. If has_eq<T>::value evaluates=
=20
> to false, what type should eq_result<T> designate? If eq_result<T> is=20
> ill-formed, then the whole expression is ill-formed. What we actually nee=
d=20
> here is something like is_well_formed operator.
>
> template <bool C>
> using bool_constant =3D std::integral_constant<bool, C>;
>
> template <class T, class U>
> struct equality_comparable_with :
> bool_constant
> <
> is_well_formed
> {
> bool b1 =3D std::declval<T>() =3D=3D std::declval<U>(=
);
> bool b2 =3D std::declval<T>() !=3D std::declval<U>();
> }
> > {};
>
> template <class T>
> struct equality_comparable :
> equality_comparable_with<T const &, T const &> {};
>
> On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. Botet Escriba=
=20
> wrote:
>>
>> Le 10/02/13 19:58, Martinho Fernandes a =EF=BF=BDcrit :=20
>>
>> > I write it as follows:=20
>> >=20
>> > struct Equality_comparable : std::integral_constant<bool,=20
>> > has_eq<T>() && is_convertible<eq_result<T>, bool>() &&=20
>> > has_neq<T>() && is_convertible<neq_result<T>, bool>()>=20
>> > {};=20
>> >=20
>> > And I use it as follows:=20
>> >=20
>> > Equality_comparable<int>()=20
>> >=20
>> > This works because integral_constant<T, X> has a constexpr conversion=
=20
>> > to T that returns X.=20
>> >=20
>> You are right. I forget to mention this possibility. Anyway this has the=
=20
>> same syntax as the constexpr template function.
>
>
> Is () or {} too long for you?
>
> > I think this is quite an acceptable state of affairs and no more=20
>> > improvement is needed.=20
>> >=20
>> I agree that it could be acceptable as it was quite acceptable to use=20
>>
>> eq_result<T>::type
>>
>
> The difference between "typename eq_result<T>::type" and "eq_result<T>"=
=20
> is much more visible than the difference between=20
> "equality_comparable<int>{}" and "equality_comparable<int>".
>
> If already present wouldn't you use it?
>
>
> I wouldn't use it. Moreover, I would prefer not to define alias templates=
=20
> for "typename Template<PAPAMS>::type" for purely cosmetic purposes and us=
e=20
> something like Template(PAPAMS) instead, so, for example
>
> template <class T1, class T2>
> struct is_decay_affined :
> std::is_same<std::decay(T1), std::decay(T2)> {};
>
So what exactly would this mean? Are you saying that if you apply the () to=
=20
a template (not an instantiation), then the stuff in the () is a list of=20
types to be applied to the template?
That sounds exceedingly confusing. Far less so than a simple template=20
alias. It's also very inconsistent with the way template instantiations=20
work in every other case besides template argument deduction.
--=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.
------=_Part_159_14694938.1360961262377
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, February 15, 2013 3:35:19 AM UTC-8, Nikolay Ivchenkov wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, February 10, 20=
13 10:51:56 PM UTC+4, Vicente J. Botet Escriba wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">
Currently when we need to define a constexpr variable we use a
template class and add a static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value =3D <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value;
<br>
};<br></div></blockquote><br>Such implementation doesn't look=20
sensible. If has_eq<T>::value evaluates to false, what type should
eq_result<T> designate? If eq_result<T> is ill-formed, then
the whole expression is ill-formed. What we actually need here is=20
something like is_well_formed operator.<br><br> template =
<bool C><br> using bool_con=
stant =3D std::integral_constant<bool, C>;<br><br> =
template <class T, class U><br> &n=
bsp; struct equality_comparable_with :<br> &nb=
sp; bool_constant<br> =
<<br> =
is_well_=
formed<br>  =
; {<br> &n=
bsp; bool=
b1 =3D std::declval<T>() =3D=3D std::declval<U>();<br> &n=
bsp;  =
; bool b2 =3D std::declval<T>() !=3D st=
d::declval<U>();<br> &=
nbsp; }<br> &nbs=
p; > {};<br><br> t=
emplate <class T><br> struc=
t equality_comparable :<br> =
equality_comparable_with<T const &, T const &=
> {};<br><br>On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. =
Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le 10/02/13 19:=
58, Martinho Fernandes a =EF=BF=BDcrit :
<br><br>> I write it as follows:
<br>>
<br>> struct Equality_comparable : std::integral_constant<bool,
<br>> has_eq<T>() && is_convertible<eq_res=
ult<T>, bool>() &&
<br>> has_neq<T>() && is_convertible<neq_r=
esult<T>, bool>()>
<br>> {};
<br>>
<br>> And I use it as follows:
<br>>
<br>> Equality_comparable<int>()
<br>>
<br>> This works because integral_constant<T, X> has a constexpr c=
onversion=20
<br>> to T that returns X.
<br>>
<br>You are right. I forget to mention this possibility. Anyway this has th=
e=20
<br>same syntax as the constexpr template function.</blockquote><div><br>Is=
() or {} too long for you?<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">
> I think this is quite an acceptable state of affairs and no more=20
<br>> improvement is needed.
<br>>
<br>I agree that it could be acceptable as it was quite acceptable to use
<br>
<br> eq_result<T>::type<br></blockquote><div><br>The diff=
erence between "typename eq_result<T>::type" and "eq_result<=
T>" is much more visible than the difference between "equality_comparabl=
e<int>{}" and "equality_comparable<int>".<br> <br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">If already present wouldn't you use it?</b=
lockquote><div><br>I wouldn't use it. Moreover, I would prefer not to defin=
e alias templates for "typename Template<PAPAMS>::type" for purely co=
smetic purposes and use something like Template(PAPAMS) instead, so, for ex=
ample<br><br> template <class T1, class T2><br>&nbs=
p; struct is_decay_affined :<br> &=
nbsp; std::is_same<=
;std::decay(T1), std::decay(T2)> {};<br></div></blockquote><div><br>So w=
hat exactly would this mean? Are you saying that if you apply the () to a t=
emplate (not an instantiation), then the stuff in the () is a list of types=
to be applied to the template?<br><br>That sounds exceedingly confusing. F=
ar less so than a simple template alias. It's also very inconsistent with t=
he way template instantiations work in every other case besides template ar=
gument deduction.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_159_14694938.1360961262377--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Fri, 15 Feb 2013 13:25:13 -0800 (PST)
Raw View
------=_Part_752_33231300.1360963513339
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 16, 2013 12:47:42 AM UTC+4, Nicol Bolas wrote:
>
> On Friday, February 15, 2013 3:35:19 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> Moreover, I would prefer not to define alias templates for "typename
>> Template<PAPAMS>::type" for purely cosmetic purposes and use something like
>> Template(PAPAMS) instead, so, for example
>>
>> template <class T1, class T2>
>> struct is_decay_affined :
>> std::is_same<std::decay(T1), std::decay(T2)> {};
>>
>
> So what exactly would this mean?
>
Here
TemplateName(TEMPLATE_ARGUMENT_LIST)
is assumed to be equivalent to
typename TemplateName<TEMPLATE_ARGUMENT_LIST>::type
Probably, [] would be a better choice than (), because template-name
followed by (ARGS) may also mean a function call.
Are you saying that if you apply the () to a template (not an
> instantiation), then the stuff in the () is a list of types to be applied
> to the template?
>
List of arbitrary template-arguments (including non-types).
That sounds exceedingly confusing. Far less so than a simple template alias.
>
I don't think so. And I don't like to write wrappers for every metafunction
returning a type.
> It's also very inconsistent with the way template instantiations work in
> every other case besides template argument deduction.
>
I don't understand your claiming.
--
---
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.
------=_Part_752_33231300.1360963513339
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 16, 2013 12:47:42 AM UTC+4, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Friday, February 15, 2013 3:35:19 =
AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>Moreover, I would prefer not to define alias templates for "typename Templ=
ate<PAPAMS>::type" for purely cosmetic purposes and use something lik=
e Template(PAPAMS) instead, so, for example<br><div><br> =
template <class T1, class T2><br> =
struct is_decay_affined :<br> &nb=
sp; std::is_same<std::decay(T1), std::decay(T2)&=
gt; {};<br></div></blockquote><div><br>So what exactly would this mean?</di=
v></blockquote><div><br>Here<br><br> TemplateName(TEMPLAT=
E_ARGUMENT_LIST)<br><br>is assumed to be equivalent to<br><br> &=
nbsp; typename TemplateName<TEMPLATE_ARGUMENT_LIST>::type<br> <b=
r>Probably, [] would be a better choice than (), because template-name foll=
owed by (ARGS) may also mean a function call.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div> Are you saying that if you apply the () =
to a template (not an instantiation), then the stuff in the () is a list of=
types to be applied to the template?<br></div></blockquote><div><br>List o=
f arbitrary template-arguments (including non-types).<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>That sounds exceedingly confusing=
.. Far less so than a simple template alias.</div></blockquote><div><br>I do=
n't think so. And I don't like to write wrappers for every metafunction ret=
urning a type.<br> <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div> It's also very inconsistent with the way template instantiation=
s work in every other case besides template argument deduction.</div></bloc=
kquote><div><br>I don't understand your claiming.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_752_33231300.1360963513339--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 15 Feb 2013 23:57:26 +0100
Raw View
Le 15/02/13 10:10, Martinho Fernandes a =E9crit :
> On 15 February 2013 07:44:40, Vicente J. Botet Escriba wrote:
>> I agree that it could be acceptable as it was quite acceptable to use
>>
>> eq_result<T>::type
>>
>> and alias template were added.
>>
>> Why are you against this simple proposal?
>> If already present wouldn't you use it?
>>
>> Vicente
>>
>
> Of course I would use it if it was there. But it isn't. Adding it=20
> means adding yet one more different kind of entity to C++ and it saves=20
> you a pair of parentheses. I don't think it is worth it.
>
The problem is not in saving a pair of parenthesis, but on providing=20
something that is coherent with the rest of the language and allows to=20
use concepts without any additional syntax just to conform with=20
constexpr, just because we can not define template constexpr CONSTANTS.
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.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 15 Feb 2013 15:03:15 -0800 (PST)
Raw View
------=_Part_5_12119333.1360969395182
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, February 15, 2013 2:57:26 PM UTC-8, Vicente J. Botet Escriba=20
wrote:
>
> Le 15/02/13 10:10, Martinho Fernandes a =EF=BF=BDcrit :=20
> > On 15 February 2013 07:44:40, Vicente J. Botet Escriba wrote:=20
> >> I agree that it could be acceptable as it was quite acceptable to use=
=20
> >>=20
> >> eq_result<T>::type=20
> >>=20
> >> and alias template were added.=20
> >>=20
> >> Why are you against this simple proposal?=20
> >> If already present wouldn't you use it?=20
> >>=20
> >> Vicente=20
> >>=20
> >=20
> > Of course I would use it if it was there. But it isn't. Adding it=20
> > means adding yet one more different kind of entity to C++ and it saves=
=20
> > you a pair of parentheses. I don't think it is worth it.=20
> >=20
> The problem is not in saving a pair of parenthesis, but on providing=20
> something that is coherent with the rest of the language and allows to=20
> use concepts without any additional syntax just to conform with=20
> constexpr, just because we can not define template constexpr CONSTANTS.=
=20
You can't define template *variables* either. So what you want is=20
inconsistent with the rest of C++. You want to make an exception for one=20
specific case.=20
--=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.
------=_Part_5_12119333.1360969395182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, February 15, 2013 2:57:26 PM UTC-8, Vicente J. Botet Escriba wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">Le 15/02/13 10:10, Martinho=
Fernandes a =EF=BF=BDcrit :
<br>> On 15 February 2013 07:44:40, Vicente J. Botet Escriba wrote:
<br>>> I agree that it could be acceptable as it was quite acceptable=
to use
<br>>>
<br>>> eq_result<T>::type
<br>>>
<br>>> and alias template were added.
<br>>>
<br>>> Why are you against this simple proposal?
<br>>> If already present wouldn't you use it?
<br>>>
<br>>> Vicente
<br>>>
<br>>
<br>> Of course I would use it if it was there. But it isn't. Adding it=
=20
<br>> means adding yet one more different kind of entity to C++ and it s=
aves=20
<br>> you a pair of parentheses. I don't think it is worth it.
<br>>
<br>The problem is not in saving a pair of parenthesis, but on providing=20
<br>something that is coherent with the rest of the language and allows to=
=20
<br>use concepts without any additional syntax just to conform with=20
<br>constexpr, just because we can not define template constexpr CONSTANTS.=
</blockquote><div><br>You can't define template <i>variables</i> eith=
er. So what you want is inconsistent with the rest of C++. You want to make=
an exception for one specific case. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5_12119333.1360969395182--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 16 Feb 2013 00:06:07 +0100
Raw View
This is a multi-part message in MIME format.
--------------000906040202040807040007
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 15/02/13 12:35, Nikolay Ivchenkov a =C3=A9crit :
> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet=20
> Escriba wrote:
>
> Currently when we need to define a constexpr variable we use a
> template class and add a static constexpr variable, e.g.
>
> template <typename T>
> struct Equality_comparable {
> static constexpr bool value =3D
> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&
> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;
> };
>
>
> Such implementation doesn't look sensible. If has_eq<T>::value=20
> evaluates to false, what type should eq_result<T> designate? If=20
> eq_result<T> is ill-formed, then the whole expression is ill-formed.=20
> What we actually need here is something like is_well_formed operator.
false && undefined is false as the right hand side is even not evaluated.
>
> template <bool C>
> using bool_constant =3D std::integral_constant<bool, C>;
>
> template <class T, class U>
> struct equality_comparable_with :
> bool_constant
> <
> is_well_formed
> {
> bool b1 =3D std::declval<T>() =3D=3D std::declval<U>(=
);
> bool b2 =3D std::declval<T>() !=3D std::declval<U>();
> }
> > {};
>
> template <class T>
> struct equality_comparable :
> equality_comparable_with<T const &, T const &> {};
>
> On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. Botet=20
> Escriba wrote:
>
> Le 10/02/13 19:58, Martinho Fernandes a =C4=8F=C5=BC=CB=9Dcrit :
>
> > I write it as follows:
> >
> > struct Equality_comparable : std::integral_constant<bool,
> > has_eq<T>() && is_convertible<eq_result<T>, bool>() &&
> > has_neq<T>() && is_convertible<neq_result<T>, bool>()>
> > {};
> >
> > And I use it as follows:
> >
> > Equality_comparable<int>()
> >
> > This works because integral_constant<T, X> has a constexpr
> conversion
> > to T that returns X.
> >
> You are right. I forget to mention this possibility. Anyway this
> has the
> same syntax as the constexpr template function.
>
>
> Is () or {} too long for you?
I don't see the need to add () when a constant is behind.
>
> > I think this is quite an acceptable state of affairs and no more
> > improvement is needed.
> >
> I agree that it could be acceptable as it was quite acceptable to use
>
> eq_result<T>::type
>
>
> The difference between "typename eq_result<T>::type" and=20
> "eq_result<T>" is much more visible than the difference between=20
> "equality_comparable<int>{}" and "equality_comparable<int>".
Maybe the syntactic difference, but the semantic difference is equivalent.
>
> If already present wouldn't you use it?
>
>
> I wouldn't use it. Moreover, I would prefer not to define alias=20
> templates for "typename Template<PAPAMS>::type" for purely cosmetic=20
> purposes and use something like Template(PAPAMS) instead, so, for example
>
> template <class T1, class T2>
> struct is_decay_affined :
> std::is_same<std::decay(T1), std::decay(T2)> {};
>
> would be equivalent to
>
> template <class T1, class T2>
> struct is_decay_affined :
> std::is_same
> <
> typename std::decay<T1>::type,
> typename std::decay<T2>::type
> > {};
>
I propose you to present a separated proposal so we can discuss it=20
separately.
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.
--------------000906040202040807040007
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 15/02/13 12:35, Nikolay Ivchenkov a
écrit :<br>
</div>
<blockquote
cite="mid:34b74efe-986c-45c6-bf18-4f2f32e098e1@isocpp.org"
type="cite">On Sunday, February 10, 2013 10:51:56 PM UTC+4,
Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF"> Currently when we need to define a
constexpr variable we use a template class and add a static
constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value = <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value; <br>
};<br>
</div>
</blockquote>
<br>
Such implementation doesn't look sensible. If
has_eq<T>::value evaluates to false, what type should
eq_result<T> designate? If eq_result<T> is ill-formed,
then the whole expression is ill-formed. What we actually need
here is something like is_well_formed operator.<br>
</blockquote>
false && undefined is false as the right hand side is even
not evaluated.<br>
<blockquote
cite="mid:34b74efe-986c-45c6-bf18-4f2f32e098e1@isocpp.org"
type="cite"><br>
template <bool C><br>
using bool_constant = std::integral_constant<bool,
C>;<br>
<br>
template <class T, class U><br>
struct equality_comparable_with :<br>
bool_constant<br>
<<br>
is_well_formed<br>
{<br>
bool b1 = std::declval<T>() ==
std::declval<U>();<br>
bool b2 = std::declval<T>() !=
std::declval<U>();<br>
}<br>
> {};<br>
<br>
template <class T><br>
struct equality_comparable :<br>
equality_comparable_with<T const &, T const
&> {};<br>
<br>
On Friday, February 15, 2013 10:44:40 AM UTC+4, Vicente J. Botet
Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
10/02/13 19:58, Martinho Fernandes a �crit :
<br>
<br>
> I write it as follows:
<br>
>
<br>
> struct Equality_comparable :
std::integral_constant<bool,
<br>
> has_eq<T>() &&
is_convertible<eq_result<T>, bool>() &&
<br>
> has_neq<T>() &&
is_convertible<neq_result<T>, bool>()>
<br>
> {};
<br>
>
<br>
> And I use it as follows:
<br>
>
<br>
> Equality_comparable<int>()
<br>
>
<br>
> This works because integral_constant<T, X> has a
constexpr conversion <br>
> to T that returns X.
<br>
>
<br>
You are right. I forget to mention this possibility. Anyway this
has the <br>
same syntax as the constexpr template function.</blockquote>
<div><br>
Is () or {} too long for you?<br>
</div>
</blockquote>
I don't see the need to add () when a constant is behind.<br>
<blockquote
cite="mid:34b74efe-986c-45c6-bf18-4f2f32e098e1@isocpp.org"
type="cite">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> I think this is quite an acceptable state of affairs and no
more <br>
> improvement is needed.
<br>
>
<br>
I agree that it could be acceptable as it was quite acceptable
to use
<br>
<br>
eq_result<T>::type<br>
</blockquote>
<div><br>
The difference between "typename eq_result<T>::type" and
"eq_result<T>" is much more visible than the difference
between "equality_comparable<int>{}" and
"equality_comparable<int>".<br>
</div>
</blockquote>
Maybe the syntactic difference, but the semantic difference is
equivalent.<br>
<blockquote
cite="mid:34b74efe-986c-45c6-bf18-4f2f32e098e1@isocpp.org"
type="cite">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If already
present wouldn't you use it?</blockquote>
<div><br>
I wouldn't use it. Moreover, I would prefer not to define alias
templates for "typename Template<PAPAMS>::type" for purely
cosmetic purposes and use something like Template(PAPAMS)
instead, so, for example<br>
<br>
template <class T1, class T2><br>
struct is_decay_affined :<br>
std::is_same<std::decay(T1), std::decay(T2)>
{};<br>
<br>
would be equivalent to<br>
<br>
template <class T1, class T2><br>
struct is_decay_affined :<br>
std::is_same<br>
<<br>
typename std::decay<T1>::type,<br>
typename std::decay<T2>::type<br>
> {};<br>
</div>
<br>
</blockquote>
I propose you to present a separated proposal so we can discuss it
separately.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------000906040202040807040007--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 15 Feb 2013 15:06:36 -0800 (PST)
Raw View
------=_Part_1_13552403.1360969596644
Content-Type: text/plain; charset=ISO-8859-1
On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:
>
> On Saturday, February 16, 2013 12:47:42 AM UTC+4, Nicol Bolas wrote:
>>
>> On Friday, February 15, 2013 3:35:19 AM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>> Moreover, I would prefer not to define alias templates for "typename
>>> Template<PAPAMS>::type" for purely cosmetic purposes and use something like
>>> Template(PAPAMS) instead, so, for example
>>>
>>> template <class T1, class T2>
>>> struct is_decay_affined :
>>> std::is_same<std::decay(T1), std::decay(T2)> {};
>>>
>>
>> So what exactly would this mean?
>>
>
> Here
>
> TemplateName(TEMPLATE_ARGUMENT_LIST)
>
> is assumed to be equivalent to
>
> typename TemplateName<TEMPLATE_ARGUMENT_LIST>::type
>
> Probably, [] would be a better choice than (), because template-name
> followed by (ARGS) may also mean a function call.
>
> Are you saying that if you apply the () to a template (not an
>> instantiation), then the stuff in the () is a list of types to be applied
>> to the template?
>>
>
> List of arbitrary template-arguments (including non-types).
>
> That sounds exceedingly confusing. Far less so than a simple template
>> alias.
>>
>
> I don't think so. And I don't like to write wrappers for every
> metafunction returning a type.
>
It's one line of code. That you write once. Yes, for every metafunction,
but it's very little overhead for something like this. And considering the
following inconcistency, it has the virtue of working exactly like any
other C++ template construct:
> It's also very inconsistent with the way template instantiations work in
>> every other case besides template argument deduction.
>>
>
> I don't understand your claiming.
>
With the exception of calling template functions, all template
instantiations take the form of "template_name<template_args>". You now
want to create a new instantiation syntax of the form
"template_name(template_args)".
C++ likes to use <> to mean "instantiate template". To now use () or [] for
that is inconsistent with how C++ normally works with template
instantiation. Not to mention confusing, since "name()" and "name[]" all
have fairly consistent, agreed-upon meanings.
That's why C++ settled on <> syntax: because they had already used up their
scoping constructs.
Furthermore, I don't like the idea of formalizing the `::type` metafunction
concept directly into the language like that. There's nothing wrong with
having `::type` as something to conform to. I just don't like the idea of
it being a real part of the language itself, something that the language
requires you to use.
--
---
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.
------=_Part_1_13552403.1360969596644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Saturday, February 16, 2013 12:=
47:42 AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Friday, February 15, 2013 3:35:19 AM UTC-8, Nikolay Ivchenkov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Moreover, I would prefer not to define=
alias templates for "typename Template<PAPAMS>::type" for purely cos=
metic purposes and use something like Template(PAPAMS) instead, so, for exa=
mple<br><div><br> template <class T1, class T2><br>=
struct is_decay_affined :<br>&nb=
sp; std::is_sam=
e<std::decay(T1), std::decay(T2)> {};<br></div></blockquote><div><br>=
So what exactly would this mean?</div></blockquote><div><br>Here<br><br>&nb=
sp; TemplateName(TEMPLATE_<wbr>ARGUMENT_LIST)<br><br>is assumed=
to be equivalent to<br><br> typename TemplateName<TEM=
PLATE_<wbr>ARGUMENT_LIST>::type<br> <br>Probably, [] would be a bet=
ter choice than (), because template-name followed by (ARGS) may also mean =
a function call.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
Are you saying that if you apply the () to a template (not an instantiatio=
n), then the stuff in the () is a list of types to be applied to the templa=
te?<br></div></blockquote><div><br>List of arbitrary template-arguments (in=
cluding non-types).<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>That sounds exceedingly confusing. Far less so than a simple template al=
ias.</div></blockquote><div><br>I don't think so. And I don't like to write=
wrappers for every metafunction returning a type.<br></div></blockquote><d=
iv><br>It's one line of code. That you write once. Yes, for every metafunct=
ion, but it's very little overhead for something like this. And considering=
the following inconcistency, it has the virtue of working exactly like any=
other C++ template construct:<br> </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div> It=
's also very inconsistent with the way template instantiations work in ever=
y other case besides template argument deduction.</div></blockquote><div><b=
r>I don't understand your claiming.<br></div></blockquote><div><br>With the=
exception of calling template functions, all template instantiations take =
the form of "template_name<template_args>". You now want to create a =
new instantiation syntax of the form "template_name(template_args)".<br><br=
>C++ likes to use <> to mean "instantiate template". To now use () or=
[] for that is inconsistent with how C++ normally works with template inst=
antiation. Not to mention confusing, since "name()" and "name[]" all have f=
airly consistent, agreed-upon meanings.<br><br>That's why C++ settled on &l=
t;> syntax: because they had already used up their scoping constructs.<b=
r><br>Furthermore, I don't like the idea of formalizing the `::type` metafu=
nction concept directly into the language like that. There's nothing wrong =
with having `::type` as something to conform to. I just don't like the idea=
of it being a real part of the language itself, something that the languag=
e requires you to use.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1_13552403.1360969596644--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 16 Feb 2013 07:37:45 +0100
Raw View
This is a multi-part message in MIME format.
--------------000102090204040906050502
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/02/13 00:03, Nicol Bolas a =C3=A9crit :
> On Friday, February 15, 2013 2:57:26 PM UTC-8, Vicente J. Botet=20
> Escriba wrote:
>
> Le 15/02/13 10:10, Martinho Fernandes a =C4=8F=C5=BC=CB=9Dcrit :
> > On 15 February 2013 07:44:40, Vicente J. Botet Escriba wrote:
> >> I agree that it could be acceptable as it was quite acceptable
> to use
> >>
> >> eq_result<T>::type
> >>
> >> and alias template were added.
> >>
> >> Why are you against this simple proposal?
> >> If already present wouldn't you use it?
> >>
> >> Vicente
> >>
> >
> > Of course I would use it if it was there. But it isn't. Adding it
> > means adding yet one more different kind of entity to C++ and it
> saves
> > you a pair of parentheses. I don't think it is worth it.
> >
> The problem is not in saving a pair of parenthesis, but on providing
> something that is coherent with the rest of the language and
> allows to
> use concepts without any additional syntax just to conform with
> constexpr, just because we can not define template constexpr
> CONSTANTS.=20
>
>
> You can't define template /variables/ either.
You are right. I've not see a motivating use cases for template=20
variables. Do you?
> So what you want is inconsistent with the rest of C++. You want to=20
> make an exception for one specific case.
>
C++ is a complex language that have a lot of exceptions. T proposal=20
removes an exception and introduce another. IMO, the proposal makes the=20
language more uniform however.
I'm proposing template constexpr variables because there are motivating=20
use cases.
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.
--------------000102090204040906050502
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 16/02/13 00:03, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:fd45185d-d8ff-48a9-8ba6-667709366bfb@isocpp.org"
type="cite">On Friday, February 15, 2013 2:57:26 PM UTC-8, Vicente
J. Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
15/02/13 10:10, Martinho Fernandes a �crit :
<br>
> On 15 February 2013 07:44:40, Vicente J. Botet Escriba
wrote:
<br>
>> I agree that it could be acceptable as it was quite
acceptable to use
<br>
>>
<br>
>> eq_result<T>::type
<br>
>>
<br>
>> and alias template were added.
<br>
>>
<br>
>> Why are you against this simple proposal?
<br>
>> If already present wouldn't you use it?
<br>
>>
<br>
>> Vicente
<br>
>>
<br>
>
<br>
> Of course I would use it if it was there. But it isn't.
Adding it <br>
> means adding yet one more different kind of entity to C++
and it saves <br>
> you a pair of parentheses. I don't think it is worth it.
<br>
>
<br>
The problem is not in saving a pair of parenthesis, but on
providing <br>
something that is coherent with the rest of the language and
allows to <br>
use concepts without any additional syntax just to conform with
<br>
constexpr, just because we can not define template constexpr
CONSTANTS. </blockquote>
<div><br>
You can't define template <i>variables</i> either. </div>
</blockquote>
You are right. I've not see a motivating use cases for template
variables. Do you?<br>
<br>
<blockquote
cite="mid:fd45185d-d8ff-48a9-8ba6-667709366bfb@isocpp.org"
type="cite">
<div>So what you want is inconsistent with the rest of C++. You
want to make an exception for one specific case. <br>
</div>
<br>
</blockquote>
<br>
C++ is a complex language that have a lot of exceptions. T proposal
removes an exception and introduce another. IMO, the proposal makes
the language more uniform however.<br>
<br>
I'm proposing template constexpr variables because there are
motivating use cases. <br>
<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------000102090204040906050502--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Sat, 16 Feb 2013 03:35:26 -0800 (PST)
Raw View
------=_Part_590_25628214.1361014526308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 16, 2013 3:06:07 AM UTC+4, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 15/02/13 12:35, Nikolay Ivchenkov a =E9crit :
> =20
> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Currently when we need to define a constexpr variable we use a template=
=20
>> class and add a static constexpr variable, e.g.
>>
>> template <typename T>
>> struct Equality_comparable {
>> static constexpr bool value =3D=20
>> has_eq<T>::value && is_convertible<eq_result<T>, bool>::value &&=20
>> has_neq<T>::value && is_convertible<neq_result<T>, bool>::value;=20
>> };
>> =20
>
> Such implementation doesn't look sensible. If has_eq<T>::value evaluates=
=20
> to false, what type should eq_result<T> designate? If eq_result<T> is=20
> ill-formed, then the whole expression is ill-formed. What we actually nee=
d=20
> here is something like is_well_formed operator.
>
> false && undefined is false as the right hand side is even not evaluated.
>
Both operands of && are syntactically and semantically checked. If either=
=20
is ill-formed, then the whole expression is ill-formed. Note that && can be=
=20
overloaded and short-circuit evaluation can be applied only to built-in=20
version, so types of both operands have to be determined anyway. In order=
=20
to use short-circuit evaluations in metaprogramming, we have to apply=20
special techniques:
template <bool C>
using bool_constant =3D std::integral_constant<bool, C>;
template <class Condition1, class... OtherConditions>
struct logical_and :
bool_constant<Condition1::value> {};
template <class Condition1, class Condition2, class... OtherConditions>
struct logical_and<Condition1, Condition2, OtherConditions...> :
std::conditional
<
Condition1::value,
logical_and<Condition2, OtherConditions...>,
std::false_type
>::type {};
template <class T>
struct A : bool_constant<....> {};
template <class T>
struct B : bool_constant<....> {};
template <class T>
struct C : logical_and<A<T>, B<T>> {};
Instantiation of C<T> will cause instantiation of B<T> only if A<T>::value=
=20
evaluates to true. Therefore, when A<T>::value =3D=3D false, "logical and"=
=20
operation will be evaluated successfully even if B<T>::value would be=20
ill-formed. You can't achieve such flexibility with your constexpr=20
variables.
Your implementation could be corrected as follows:
template <class C, class T1, class T2>
using lazy_if =3D typename std::conditional<C::value, T1,=20
T2>::type::type;
template <class T>
struct identity
{ using type =3D T; };
template <typename T>
struct equality_comparable :
std::is_convertible
<
lazy_if<has_eq<T>, eq_result<T>, identity<void>>,
bool
> {};
where has_eq and eq_result are plain class templates.
On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:
>
> On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:
>>
>> And I don't like to write wrappers for every metafunction returning a=20
>> type.
>>
>
> It's one line of code. That you write once.
>
I don't want to write redundant code, even once. I don't like unobvious=20
and/or ugly naming conventions that I have to use in order to distinguish=
=20
original class templates and wrappers.
=20
> With the exception of calling template functions, all template=20
> instantiations take the form of "template_name<template_args>".
>
template_name<template_args> is not an instantiation. Such notation only=20
refers to a template specialization, which may actually never be=20
instantiated.
=20
> You now want to create a new instantiation syntax of the form=20
> "template_name(template_args)".
>
This is syntax for obtaining result of a metafunction. Metafunction is a=20
separate abstraction and instantiation is just a detail of how a=20
metafunction works.
C++ likes to use <> to mean "instantiate template". To now use () or [] for=
=20
> that is inconsistent with how C++ normally works with template=20
> instantiation.
>
I don't see problems here. "New syntax is bad because it's new" is not=20
convincing argument for me.
Furthermore, I don't like the idea of formalizing the `::type` metafunction=
=20
> concept directly into the language like that. There's nothing wrong with=
=20
> having `::type` as something to conform to. I just don't like the idea of=
=20
> it being a real part of the language itself, something that the language=
=20
> requires you to use.
>
::type is a widely used and well-known concept. If you don't want to use=20
it, you are free not to use such core language feature.
--=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.
------=_Part_590_25628214.1361014526308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 16, 2013 3:06:07 AM UTC+4, Vicente J. Botet Escriba w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 15/02/13 12:35, Nikolay Ivchenkov a
=E9crit :<br>
</div>
<blockquote type=3D"cite">On Sunday, February 10, 2013 10:51:56 PM UTC+=
4,
Vicente J. Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF"> Currently when we need to define a
constexpr variable we use a template class and add a static
constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value =3D <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value; <br>
};<br>
</div>
</blockquote>
<br>
Such implementation doesn't look sensible. If
has_eq<T>::value evaluates to false, what type should
eq_result<T> designate? If eq_result<T> is ill-formed,
then the whole expression is ill-formed. What we actually need
here is something like is_well_formed operator.<br>
</blockquote>
false && undefined is false as the right hand side is even
not evaluated.<br></div></blockquote><div><br>Both operands of &&am=
p; are syntactically and semantically checked. If either is ill-formed, the=
n the whole expression is ill-formed. Note that && can be overloade=
d and short-circuit evaluation can be applied only to built-in version, so =
types of both operands have to be determined anyway. In order to use short-=
circuit evaluations in metaprogramming, we have to apply special techniques=
:<br><br> template <bool C><br> &n=
bsp; using bool_constant =3D std::integral_constant<bo=
ol, C>;<br><br> template <class Condition1, class..=
.. OtherConditions><br> struct =
logical_and :<br> &nbs=
p; bool_constant<Condition1::value> {};<br> t=
emplate <class Condition1, class Condition2, class... OtherConditions>=
;<br> struct logical_and<Condi=
tion1, Condition2, OtherConditions...> :<br> &nbs=
p; std::conditional<br> &nbs=
p; <<br> &nbs=
p; =
Condition1::value,<br>  =
; logical_and<Condition2, OtherCondi=
tions...>,<br> &nbs=
p; std::false_type<br>  =
; >::type {};<br><br> &nb=
sp; template <class T><br> &=
nbsp; struct A : bool_constant<....> {};<br> templa=
te <class T><br> struct B :=
bool_constant<....> {};<br> template <class T&g=
t;<br> struct C : logical_and<=
A<T>, B<T>> {};<br><br>Instantiation of C<T> will caus=
e instantiation of B<T> only if A<T>::value evaluates to true. =
Therefore, when A<T>::value =3D=3D false, "logical and" operation wil=
l be evaluated successfully even if B<T>::value would be ill-formed. =
You can't achieve such flexibility with your constexpr variables.<br><br>Yo=
ur implementation could be corrected as follows:<br><br> =
template <class C, class T1, class T2><br> &nb=
sp; using lazy_if =3D typename std::conditional<C::value, T1=
, T2>::type::type;<br><br> template <class T><br=
> struct identity<br> =
{ using type =3D T; =
};<br><br> template <typename T><br> &nb=
sp; struct equality_comparable :<br> &nb=
sp; std::is_convertible<br>=
<<br>=
&nb=
sp; lazy_if<has_eq<T>, eq_result<T>, identity<=
;void>>,<br> &nb=
sp; bool<br> &nb=
sp; > {};<br><br>where has_eq and eq_resul=
t are plain class templates.<br><br>On Saturday, February 16, 2013 3:06:36 =
AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">And I don't like to write wrappers for ev=
ery metafunction returning a type.<br></blockquote><div><br>It's one line o=
f code. That you write once.</div></blockquote><div><br>I
don't want to write redundant code, even once. I don't like unobvious=20
and/or ugly naming conventions that I have to use in order to=20
distinguish original class templates and wrappers.<br> </div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div>With
the exception of calling template functions, all template=20
instantiations take the form of "template_name<template_args>"<wbr>.<=
/div></blockquote><div><br>template_name<template_args>
is not an instantiation. Such notation only refers to a template=20
specialization, which may actually never be instantiated.<br> </div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div> You now want to create a n=
ew instantiation syntax of the form "template_name(template_args)"<wbr>.<br=
></div></blockquote><div><br>This
is syntax for obtaining result of a metafunction. Metafunction is a=20
separate abstraction and instantiation is just a detail of how a=20
metafunction works.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div>C++
likes to use <> to mean "instantiate template". To now use () or=20
[] for that is inconsistent with how C++ normally works with template=20
instantiation.</div></blockquote><div><br>I don't see problems here. "New s=
yntax is bad because it's new" is not convincing argument for me.</div><br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div>Furthermore,
I don't like the idea of formalizing the `::type` metafunction concept=20
directly into the language like that. There's nothing wrong with having=20
`::type` as something to conform to. I just don't like the idea of it=20
being a real part of the language itself, something that the language=20
requires you to use.<br></div></blockquote><div><br>::type is a widely used=
and well-known concept. If you don't want to use it, you are free not to u=
se such core language feature.<br></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_590_25628214.1361014526308--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 16 Feb 2013 05:28:54 -0800 (PST)
Raw View
------=_Part_463_31069493.1361021334980
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 16, 2013 3:35:26 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:
>
>> On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>> And I don't like to write wrappers for every metafunction returning a
>>> type.
>>>
>>
>> It's one line of code. That you write once.
>>
>
> I don't want to write redundant code, even once. I don't like unobvious
> and/or ugly naming conventions that I have to use in order to distinguish
> original class templates and wrappers.
>
There aren't wrappers. There's "the thing you use" (AKA: the template
alias), and "the thing that implements it". The latter of which can go into
some "detail" namespace that nobody ever needs to know about, see, or use.
It's no different from any other mechanism where you hide implementation
details.
You're effectively saying that there is an adequate solution, but you don't
like it because you think it's "unobvious" (I don't know how you get that)
and "ugly" (also, I don't see how that works, since it's cleaner than your
() syntax, as it uses <> notation just like any other template). That seems
to me like you simply don't like the existing solution.
The existing solution works. It fits into the language. It's useful for
more than just instantiating metafunctions. It uses existing syntax rather
than creating its own. It makes "metafunctions" look like any old type. I
don't see any *objective* downside here, save for introducing another
typename. And again, if name pollution is an issue, that's what namespaces
are for.
I don't see the need for introducing such a language feature that will only
be used on such a specific programming tool (ie: metafunctions), when you
can get the same effect by employing existing language features.
C++ likes to use <> to mean "instantiate template". To now use () or [] for
>> that is inconsistent with how C++ normally works with template
>> instantiation.
>>
>
> I don't see problems here. "New syntax is bad because it's new" is not
> convincing argument for me.
>
OK, how about the fact that () means something else? Names followed by ()
means "call a function." Admittedly, sometimes it means "construct an
object", but even that is still calling a function.
And no, you can't "call" a metafunction. Metafunctions are template
instantiations, and thus they should *look* like template instantiations.
They aren't function calls and we shouldn't fool people into thinking they
are.
When you start using () to hold a typelist instead of an argument list,
you're really torturing the language into something else. There's a reason
why the C++ committee used <> notation for templates instead of
re-purposing [] or ().
And then there's the general confusion of exactly what's going on. If I use
a template alias, you can follow the alias back to its source to see what
is actually happening. Your way, the ::type part is completely erased from
existence. It's gone, invisible, assumed by the compiler. And thus anyone
using has to know what the implicit assumption of the language construct is.
I don't think that's a good idea.
Furthermore, I don't like the idea of formalizing the `::type` metafunction
>> concept directly into the language like that. There's nothing wrong with
>> having `::type` as something to conform to. I just don't like the idea of
>> it being a real part of the language itself, something that the language
>> requires you to use.
>>
>
> ::type is a widely used and well-known concept. If you don't want to use
> it, you are free not to use such core language feature.
>
std::initializer_list is a language feature, as you can only generate them
by using a language feature. std::type_info is a language feature, as you
can only generate them with a language feature.
::type is not a "core language feature" by any definition of that term. It
is a *library convention*, nothing more. The only thing we have that
standardizes a library convention in a language feature currently is
range-based for, which relies upon std::begin/end and the iterator
concepts. And even that is primarily for extensibility, so that you can
allow iteration over arbitrary containers.
To do what you're suggesting is to effectively say that this is the only
correct metafunction syntax. It favors one convention over another.
And all of this is so that you don't have to use template aliases for what
is one of the main reasons that feature was adopted in the first place.
--
---
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.
------=_Part_463_31069493.1361021334980
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, February 16, 2013 3:35:26 AM UTC-8, Nikolay Ivchenkov =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, February 16=
, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:<div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenk=
ov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">And I don't like to write =
wrappers for every metafunction returning a type.<br></blockquote><div><br>=
It's one line of code. That you write once.</div></blockquote><div><br>I
don't want to write redundant code, even once. I don't like unobvious=20
and/or ugly naming conventions that I have to use in order to=20
distinguish original class templates and wrappers.<br></div></div></blockqu=
ote><div><br>There aren't wrappers. There's "the thing you use" (AKA: the t=
emplate alias), and "the thing that implements it". The latter of which can=
go into some "detail" namespace that nobody ever needs to know about, see,=
or use.<br><br>It's no different from any other mechanism where you hide i=
mplementation details.<br><br>You're effectively saying that there is an ad=
equate solution, but you don't like it because you think it's "unobvious" (=
I don't know how you get that) and "ugly" (also, I don't see how that works=
, since it's cleaner than your () syntax, as it uses <> notation just=
like any other template). That seems to me like you simply don't like the =
existing solution.<br><br>The existing solution works. It fits into the lan=
guage. It's useful for more than just instantiating metafunctions. It uses =
existing syntax rather than creating its own. It makes "metafunctions" look=
like any old type. I don't see any <i>objective</i> downside here, save fo=
r introducing another typename. And again, if name pollution is an issue, t=
hat's what namespaces are for.<br><br>I don't see the need for introducing =
such a language feature that will only be used on such a specific programmi=
ng tool (ie: metafunctions), when you can get the same effect by employing =
existing language features.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div><div></div><div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div>C++
likes to use <> to mean "instantiate template". To now use () or=20
[] for that is inconsistent with how C++ normally works with template=20
instantiation.</div></blockquote><div><br>I don't see problems here. "New s=
yntax is bad because it's new" is not convincing argument for me.</div></di=
v></blockquote><div><br>OK, how about the fact that () means something else=
? Names followed by () means "call a function." Admittedly, sometimes it me=
ans "construct an object", but even that is still calling a function.<br><b=
r>And no, you can't "call" a metafunction. Metafunctions are template insta=
ntiations, and thus they should <i>look</i> like template instantiations. T=
hey aren't function calls and we shouldn't fool people into thinking they a=
re.<br><br>When you start using () to hold a typelist instead of an argumen=
t list, you're really torturing the language into something else. There's a=
reason why the C++ committee used <> notation for templates instead =
of re-purposing [] or ().<br><br>And then there's the general confusion of =
exactly what's going on. If I use a template alias, you can follow the alia=
s back to its source to see what is actually happening. Your way, the ::typ=
e part is completely erased from existence. It's gone, invisible, assumed b=
y the compiler. And thus anyone using has to know what the implicit assumpt=
ion of the language construct is.<br><br>I don't think that's a good idea.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div>Furthermore,
I don't like the idea of formalizing the `::type` metafunction concept=20
directly into the language like that. There's nothing wrong with having=20
`::type` as something to conform to. I just don't like the idea of it=20
being a real part of the language itself, something that the language=20
requires you to use.<br></div></blockquote><div><br>::type is a widely used=
and well-known concept. If you don't want to use it, you are free not to u=
se such core language feature.<br></div></div></blockquote><div><br>std::in=
itializer_list is a language feature, as you can only generate them by usin=
g a language feature. std::type_info is a language feature, as you can only=
generate them with a language feature.<br><br>::type is not a "core langua=
ge feature" by any definition of that term. It is a <i>library convention</=
i>, nothing more. The only thing we have that standardizes a library conven=
tion in a language feature currently is range-based for, which relies upon =
std::begin/end and the iterator concepts. And even that is primarily for ex=
tensibility, so that you can allow iteration over arbitrary containers.<br>=
<br>To do what you're suggesting is to effectively say that this is the onl=
y correct metafunction syntax. It favors one convention over another.<br><b=
r>And all of this is so that you don't have to use template aliases for wha=
t is one of the main reasons that feature was adopted in the first place.<b=
r></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_463_31069493.1361021334980--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 16 Feb 2013 05:41:00 -0800 (PST)
Raw View
------=_Part_466_23373275.1361022060470
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 16, 2013 5:28:54 AM UTC-8, Nicol Bolas wrote:
>
> On Saturday, February 16, 2013 3:35:26 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:
>>
>>> C++ likes to use <> to mean "instantiate template". To now use () or []
>>> for that is inconsistent with how C++ normally works with template
>>> instantiation.
>>>
>>
>> I don't see problems here. "New syntax is bad because it's new" is not
>> convincing argument for me.
>>
>
> OK, how about the fact that () means something else? Names followed by ()
> means "call a function." Admittedly, sometimes it means "construct an
> object", but even that is still calling a function.
>
> And no, you can't "call" a metafunction. Metafunctions are template
> instantiations, and thus they should *look* like template instantiations.
> They aren't function calls and we shouldn't fool people into thinking they
> are.
>
> When you start using () to hold a typelist instead of an argument list,
> you're really torturing the language into something else. There's a reason
> why the C++ committee used <> notation for templates instead of
> re-purposing [] or ().
>
> And then there's the general confusion of exactly what's going on. If I
> use a template alias, you can follow the alias back to its source to see
> what is actually happening. Your way, the ::type part is completely erased
> from existence. It's gone, invisible, assumed by the compiler. And thus
> anyone using has to know what the implicit assumption of the language
> construct is.
>
> I don't think that's a good idea.
>
Also, there's another bit of inconsistency. Consider what if you want to
take a complex metafunction instantiation and boil it down into a simpler
instantiation for repeated use. What tool do you use?
Template aliases.
template<typename T>
using simple_instance = <insert complex instantiation here>;
However, you can no longer use this with your () syntax, as it's no longer
a metafunction by your definition. Therefore, you'd have to do this:
template<typename T>
struct simple_instance
{
using type = <insert complex instantiation here>;
};
The former one is what most people are going to want to use. So it makes
sense, from a consistency point of view, for users to simply apply template
aliases to all metafunctions globally.
--
---
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.
------=_Part_466_23373275.1361022060470
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, February 16, 2013 5:28:54 AM UTC-8, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, February 16, 2013=
3:35:26 AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:=
<div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div><div></div><div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>C++
likes to use <> to mean "instantiate template". To now use () or=20
[] for that is inconsistent with how C++ normally works with template=20
instantiation.</div></blockquote><div><br>I don't see problems here. "New s=
yntax is bad because it's new" is not convincing argument for me.</div></di=
v></blockquote><div><br>OK, how about the fact that () means something else=
? Names followed by () means "call a function." Admittedly, sometimes it me=
ans "construct an object", but even that is still calling a function.<br><b=
r>And no, you can't "call" a metafunction. Metafunctions are template insta=
ntiations, and thus they should <i>look</i> like template instantiations. T=
hey aren't function calls and we shouldn't fool people into thinking they a=
re.<br><br>When you start using () to hold a typelist instead of an argumen=
t list, you're really torturing the language into something else. There's a=
reason why the C++ committee used <> notation for templates instead =
of re-purposing [] or ().<br><br>And then there's the general confusion of =
exactly what's going on. If I use a template alias, you can follow the alia=
s back to its source to see what is actually happening. Your way, the ::typ=
e part is completely erased from existence. It's gone, invisible, assumed b=
y the compiler. And thus anyone using has to know what the implicit assumpt=
ion of the language construct is.<br><br>I don't think that's a good idea.<=
br></div></blockquote><div><br>Also, there's another bit of inconsistency. =
Consider what if you want to take a complex metafunction instantiation and =
boil it down into a simpler instantiation for repeated use. What tool do yo=
u use?<br><br>Template aliases.<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">usi=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> simple_=
instance </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">insert complex instant=
iation here</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>However, you can no longer use this with your=
() syntax, as it's no longer a metafunction by your definition. Therefore,=
you'd have to do this:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> simple_instanc=
e<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> type </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">insert complex instantiation here</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">>;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div><br=
>The former one is what most people are going to want to use. So it makes s=
ense, from a consistency point of view, for users to simply apply template =
aliases to all metafunctions globally.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_466_23373275.1361022060470--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 16 Feb 2013 15:17:24 +0100
Raw View
This is a multi-part message in MIME format.
--------------090802040005030408030502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/02/13 12:35, Nikolay Ivchenkov a =E9crit :
> On Saturday, February 16, 2013 3:06:07 AM UTC+4, Vicente J. Botet=20
> Escriba wrote:
>
> Le 15/02/13 12:35, Nikolay Ivchenkov a =E9crit :
>> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet
>> Escriba wrote:
>>
>> Currently when we need to define a constexpr variable we use
>> a template class and add a static constexpr variable, e.g.
>>
>> template <typename T>
>> struct Equality_comparable {
>> static constexpr bool value =3D
>> has_eq<T>::value && is_convertible<eq_result<T>,
>> bool>::value &&
>> has_neq<T>::value && is_convertible<neq_result<T>,
>> bool>::value;
>> };
>>
>>
>> Such implementation doesn't look sensible. If has_eq<T>::value
>> evaluates to false, what type should eq_result<T> designate? If
>> eq_result<T> is ill-formed, then the whole expression is
>> ill-formed. What we actually need here is something like
>> is_well_formed operator.
> false && undefined is false as the right hand side is even not
> evaluated.
>
>
> Both operands of && are syntactically and semantically checked. If=20
> either is ill-formed, then the whole expression is ill-formed. Note=20
> that && can be overloaded and short-circuit evaluation can be applied=20
> only to built-in version, so types of both operands have to be=20
> determined anyway.
You are surely right. The subject of the post is not how to define=20
EqualityComparable. Anyway you could say that eq_result<T> designates a=20
dummy. Maybe you can create a new thread respect to this point for the=20
concept proposal. The example I used is extracted from there.
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.
--------------090802040005030408030502
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 16/02/13 12:35, Nikolay Ivchenkov a
écrit :<br>
</div>
<blockquote
cite="mid:d73342a1-c82a-4156-86d5-fce0163828c8@isocpp.org"
type="cite">On Saturday, February 16, 2013 3:06:07 AM UTC+4,
Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Le 15/02/13 12:35, Nikolay Ivchenkov a écrit :<br>
</div>
<blockquote type="cite">On Sunday, February 10, 2013 10:51:56
PM UTC+4, Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> Currently when we need to define a
constexpr variable we use a template class and add a
static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value = <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>, bool>::value;
<br>
};<br>
</div>
</blockquote>
<br>
Such implementation doesn't look sensible. If
has_eq<T>::value evaluates to false, what type should
eq_result<T> designate? If eq_result<T> is
ill-formed, then the whole expression is ill-formed. What we
actually need here is something like is_well_formed
operator.<br>
</blockquote>
false && undefined is false as the right hand side is
even not evaluated.<br>
</div>
</blockquote>
<div><br>
Both operands of && are syntactically and semantically
checked. If either is ill-formed, then the whole expression is
ill-formed. Note that && can be overloaded and
short-circuit evaluation can be applied only to built-in
version, so types of both operands have to be determined anyway.
</div>
</blockquote>
<br>
You are surely right. The subject of the post is not how to define
EqualityComparable. Anyway you could say that eq_result<T>
designates a dummy. Maybe you can create a new thread respect to
this point for the concept proposal. The example I used is extracted
from there.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------090802040005030408030502--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 16 Feb 2013 15:44:38 +0100
Raw View
This is a multi-part message in MIME format.
--------------060003060909040204030702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/02/13 15:17, Vicente J. Botet Escriba a =E9crit :
> Le 16/02/13 12:35, Nikolay Ivchenkov a =E9crit :
>> On Saturday, February 16, 2013 3:06:07 AM UTC+4, Vicente J. Botet=20
>> Escriba wrote:
>>
>> Le 15/02/13 12:35, Nikolay Ivchenkov a =E9crit :
>>> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J. Botet
>>> Escriba wrote:
>>>
>>> Currently when we need to define a constexpr variable we use
>>> a template class and add a static constexpr variable, e.g.
>>>
>>> template <typename T>
>>> struct Equality_comparable {
>>> static constexpr bool value =3D
>>> has_eq<T>::value && is_convertible<eq_result<T>,
>>> bool>::value &&
>>> has_neq<T>::value && is_convertible<neq_result<T>,
>>> bool>::value;
>>> };
>>>
>>>
>>> Such implementation doesn't look sensible. If has_eq<T>::value
>>> evaluates to false, what type should eq_result<T> designate? If
>>> eq_result<T> is ill-formed, then the whole expression is
>>> ill-formed. What we actually need here is something like
>>> is_well_formed operator.
>> false && undefined is false as the right hand side is even not
>> evaluated.
>>
>>
>> Both operands of && are syntactically and semantically checked. If=20
>> either is ill-formed, then the whole expression is ill-formed. Note=20
>> that && can be overloaded and short-circuit evaluation can be applied=20
>> only to built-in version, so types of both operands have to be=20
>> determined anyway.
>
> You are surely right. The subject of the post is not how to define=20
> EqualityComparable. Anyway you could say that eq_result<T> designates=20
> a dummy. Maybe you can create a new thread respect to this point for=20
> the concept proposal. The example I used is extracted from there.
>
>
In case you don't have access to the Concept proposal here it is how=20
has_eq and eq_result are defined:
template<typename T>
struct eq_result_impl
{
template<typename X>
static auto check(const X& x) -> decltype(x =3D=3D x);
s
--=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.
--------------060003060909040204030702
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 16/02/13 15:17, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:511F94F4.8000004@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 16/02/13 12:35, Nikolay Ivchenkov
a écrit :<br>
</div>
<blockquote
cite="mid:d73342a1-c82a-4156-86d5-fce0163828c8@isocpp.org"
type="cite">On Saturday, February 16, 2013 3:06:07 AM UTC+4,
Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Le 15/02/13 12:35, Nikolay Ivchenkov a écrit :<br>
</div>
<blockquote type="cite">On Sunday, February 10, 2013
10:51:56 PM UTC+4, Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> Currently when we need to define
a constexpr variable we use a template class and add a
static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value = <br>
has_eq<T>::value &&
is_convertible<eq_result<T>, bool>::value
&& <br>
has_neq<T>::value &&
is_convertible<neq_result<T>,
bool>::value; <br>
};<br>
</div>
</blockquote>
<br>
Such implementation doesn't look sensible. If
has_eq<T>::value evaluates to false, what type
should eq_result<T> designate? If eq_result<T>
is ill-formed, then the whole expression is ill-formed.
What we actually need here is something like
is_well_formed operator.<br>
</blockquote>
false && undefined is false as the right hand side
is even not evaluated.<br>
</div>
</blockquote>
<div><br>
Both operands of && are syntactically and semantically
checked. If either is ill-formed, then the whole expression is
ill-formed. Note that && can be overloaded and
short-circuit evaluation can be applied only to built-in
version, so types of both operands have to be determined
anyway. </div>
</blockquote>
<br>
You are surely right. The subject of the post is not how to define
EqualityComparable. Anyway you could say that eq_result<T>
designates a dummy. Maybe you can create a new thread respect to
this point for the concept proposal. The example I used is
extracted from there.<br>
<br>
<br>
</blockquote>
In case you don't have access to the Concept proposal here it is how
has_eq and eq_result are defined:<br>
<br>
template<typename T><br>
struct eq_result_impl<br>
{<br>
template<typename X><br>
static auto check(const X& x) -> decltype(x == x);<br>
s
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------060003060909040204030702--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 16 Feb 2013 17:17:36 +0100
Raw View
This is a multi-part message in MIME format.
--------------030806080405030509030604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/02/13 15:44, Vicente J. Botet Escriba a =E9crit :
> Le 16/02/13 15:17, Vicente J. Botet Escriba a =E9crit :
>> Le 16/02/13 12:35, Nikolay Ivchenkov a =E9crit :
>>> On Saturday, February 16, 2013 3:06:07 AM UTC+4, Vicente J. Botet=20
>>> Escriba wrote:
>>>
>>> Le 15/02/13 12:35, Nikolay Ivchenkov a =E9crit :
>>>> On Sunday, February 10, 2013 10:51:56 PM UTC+4, Vicente J.
>>>> Botet Escriba wrote:
>>>>
>>>> Currently when we need to define a constexpr variable we
>>>> use a template class and add a static constexpr variable, e.g.
>>>>
>>>> template <typename T>
>>>> struct Equality_comparable {
>>>> static constexpr bool value =3D
>>>> has_eq<T>::value && is_convertible<eq_result<T>,
>>>> bool>::value &&
>>>> has_neq<T>::value && is_convertible<neq_result<T>,
>>>> bool>::value;
>>>> };
>>>>
>>>>
>>>> Such implementation doesn't look sensible. If has_eq<T>::value
>>>> evaluates to false, what type should eq_result<T> designate? If
>>>> eq_result<T> is ill-formed, then the whole expression is
>>>> ill-formed. What we actually need here is something like
>>>> is_well_formed operator.
>>> false && undefined is false as the right hand side is even not
>>> evaluated.
>>>
>>>
>>> Both operands of && are syntactically and semantically checked. If=20
>>> either is ill-formed, then the whole expression is ill-formed. Note=20
>>> that && can be overloaded and short-circuit evaluation can be=20
>>> applied only to built-in version, so types of both operands have to=20
>>> be determined anyway.
>>
>> You are surely right. The subject of the post is not how to define=20
>> EqualityComparable. Anyway you could say that eq_result<T> designates=20
>> a dummy. Maybe you can create a new thread respect to this point for=20
>> the concept proposal. The example I used is extracted from there.
>>
>>
> In case you don't have access to the Concept proposal here it is how=20
> has_eq and eq_result are defined:
>
template<typename T>
struct eq_result_impl
{
template<typename X>
static auto check(const X& x) -> decltype(x =3D=3D x);
static subst_failure check(...);
using type =3D decltype(check(declval<T>()));
};
template<typename T>
using eq_result =3D typename eq_result_impl<T>::type;
template<typename T>
struct has_eq
: integral_constant<bool, !is_same<eq_result<T>, subst_failure>::value>
{ };
As you can see the definitions are robust and well-formed.
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.
--------------030806080405030509030604
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 16/02/13 15:44, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:511F9B56.50503@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 16/02/13 15:17, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:511F94F4.8000004@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 16/02/13 12:35, Nikolay
Ivchenkov a écrit :<br>
</div>
<blockquote
cite="mid:d73342a1-c82a-4156-86d5-fce0163828c8@isocpp.org"
type="cite">On Saturday, February 16, 2013 3:06:07 AM UTC+4,
Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Le 15/02/13 12:35, Nikolay Ivchenkov a écrit :<br>
</div>
<blockquote type="cite">On Sunday, February 10, 2013
10:51:56 PM UTC+4, Vicente J. Botet Escriba wrote:
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> Currently when we need to
define a constexpr variable we use a template class
and add a static constexpr variable, e.g.<br>
<br>
template <typename T><br>
struct Equality_comparable {<br>
static constexpr bool value = <br>
has_eq<T>::value &&
is_convertible<eq_result<T>,
bool>::value && <br>
has_neq<T>::value &&
is_convertible<neq_result<T>,
bool>::value; <br>
};<br>
</div>
</blockquote>
<br>
Such implementation doesn't look sensible. If
has_eq<T>::value evaluates to false, what type
should eq_result<T> designate? If
eq_result<T> is ill-formed, then the whole
expression is ill-formed. What we actually need here is
something like is_well_formed operator.<br>
</blockquote>
false && undefined is false as the right hand side
is even not evaluated.<br>
</div>
</blockquote>
<div><br>
Both operands of && are syntactically and
semantically checked. If either is ill-formed, then the
whole expression is ill-formed. Note that && can be
overloaded and short-circuit evaluation can be applied only
to built-in version, so types of both operands have to be
determined anyway. </div>
</blockquote>
<br>
You are surely right. The subject of the post is not how to
define EqualityComparable. Anyway you could say that
eq_result<T> designates a dummy. Maybe you can create a
new thread respect to this point for the concept proposal. The
example I used is extracted from there.<br>
<br>
<br>
</blockquote>
In case you don't have access to the Concept proposal here it is
how has_eq and eq_result are defined:<br>
<br>
</blockquote>
template<typename T>
<br>
struct eq_result_impl
<br>
{
<br>
template<typename X>
<br>
static auto check(const X& x) -> decltype(x == x);
<br>
static subst_failure check(...);
<br>
using type = decltype(check(declval<T>()));
<br>
};
<br>
template<typename T>
<br>
using eq_result = typename eq_result_impl<T>::type;
<br>
template<typename T>
<br>
struct has_eq
<br>
: integral_constant<bool, !is_same<eq_result<T>,
subst_failure>::value>
<br>
{ };<br>
<br>
As you can see the definitions are robust and well-formed.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------030806080405030509030604--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Sat, 16 Feb 2013 13:24:25 -0800 (PST)
Raw View
------=_Part_1021_20690179.1361049865258
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:
>
> On Saturday, February 16, 2013 3:35:26 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:
>>
>>> On Friday, February 15, 2013 1:25:13 PM UTC-8, Nikolay Ivchenkov wrote:
>>>>
>>>> And I don't like to write wrappers for every metafunction returning a
>>>> type.
>>>>
>>>
>>> It's one line of code. That you write once.
>>>
>>
>> I don't want to write redundant code, even once. I don't like unobvious
>> and/or ugly naming conventions that I have to use in order to distinguish
>> original class templates and wrappers.
>>
>
> There aren't wrappers. There's "the thing you use" (AKA: the template
> alias), and "the thing that implements it". The latter of which can go into
> some "detail" namespace that nobody ever needs to know about, see, or use.
>
Alias templates (as metafunctions returning types) aren't perfect
replacement for plain class templates. Plain class templates are more
convenient for lazy evaluations. For example, compare the following two
implementations of to_unsigned:
http://liveworkspace.org/code/1WyqXN$0
http://liveworkspace.org/code/PO3Gc$0
You're effectively saying that there is an adequate solution, but you don't
> like it because you think it's "unobvious" (I don't know how you get that)
> and "ugly" (also, I don't see how that works, since it's cleaner than your
> () syntax, as it uses <> notation just like any other template).
>
You are misreading my words.
The existing solution works. It fits into the language. It's useful for
> more than just instantiating metafunctions. It uses existing syntax rather
> than creating its own.
>
I could say similar things about
for (auto i = range.begin(); i != range.end(); ++i)
The question is: so what? Range-based "for" is useless?
I don't see any *objective* downside here
>
I don't worry much about that.
I don't see the need for introducing such a language feature
>
Rhetorical question: do you have enough experience with metaprogramming in
order to judge about it?
OK, how about the fact that () means something else? Names followed by ()
> means "call a function."
>
How about macro invocations? How about function parameter lists? How about
function-style type conversions to built-in types?
The only thing we have that standardizes a library convention in a language
> feature currently is range-based for, which relies upon std::begin/end and
> the iterator concepts. And even that is primarily for extensibility, so
> that you can allow iteration over arbitrary containers.
>
> To do what you're suggesting is to effectively say that this is the only
> correct metafunction syntax. It favors one convention over another.
>
So what? Let's ban range-based for?
On Saturday, February 16, 2013 6:17:24 PM UTC+4, Vicente J. Botet Escriba
wrote:
>
> Anyway you could say that eq_result<T> designates a dummy.
>
We don't need has_eq then :-) Dummy type can be defined so that it would
not be convertible to bool.
On Saturday, February 16, 2013 8:17:36 PM UTC+4, Vicente J. Botet Escriba
wrote:
>
> template<typename T>
> struct eq_result_impl
> {
> template<typename X>
> static auto check(const X& x) -> decltype(x == x);
> static subst_failure check(...);
> using type = decltype(check(declval<T>()));
> };
> template<typename T>
> using eq_result = typename eq_result_impl<T>::type;
> template<typename T>
> struct has_eq
> : integral_constant<bool, !is_same<eq_result<T>, subst_failure>::value>
> { };
>
> As you can see the definitions are robust and well-formed.
>
Strictly speaking, it's not correct (failure cases: cv void, arrays of
unknown bound, volatile-qualified equatity-comparable types), but usually
it would work as expected.
--
---
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.
------=_Part_1021_20690179.1361049865258
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Saturday, February 16, 2013 3:35:26=
AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Saturday, February 16, 2013 3:06:36 AM UTC+4, Nicol Bolas wrote:<div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">On Friday, February 15, 2013 1:25:13 =
PM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>And I don't like to write wrappers for every metafunction returning a type=
..<br></blockquote><div><br>It's one line of code. That you write once.</div=
></blockquote><div><br>I
don't want to write redundant code, even once. I don't like unobvious=20
and/or ugly naming conventions that I have to use in order to=20
distinguish original class templates and wrappers.<br></div></div></blockqu=
ote><div><br>There aren't wrappers. There's "the thing you use" (AKA: the t=
emplate alias), and "the thing that implements it". The latter of which can=
go into some "detail" namespace that nobody ever needs to know about, see,=
or use.<br></div></blockquote><div><br>Alias templates (as metafunctions r=
eturning types) aren't perfect replacement for plain class templates. Plain=
class templates are more convenient for lazy evaluations. For example, com=
pare the following two implementations of to_unsigned:<br>http://liveworksp=
ace.org/code/1WyqXN$0<br>http://liveworkspace.org/code/PO3Gc$0<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div>You're effectively sayin=
g that there is an adequate solution, but you don't like it because you thi=
nk it's "unobvious" (I don't know how you get that) and "ugly" (also, I don=
't see how that works, since it's cleaner than your () syntax, as it uses &=
lt;> notation just like any other template).</div></blockquote><div><br>=
You are misreading my words.<br></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div>The existing solution works. It fits into the l=
anguage. It's useful for more than just instantiating metafunctions. It use=
s existing syntax rather than creating its own.</div></blockquote><div><br>=
I could say similar things about<br><br> for (auto i =3D range=
..begin(); i !=3D range.end(); ++i)<br><br>The question is: so what? Range-b=
ased "for" is useless?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>I don't see any <i>objective</i> downside here</div></blockquote=
><div><br>I don't worry much about that.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div>I don't see the need for introducing such a la=
nguage feature</div></blockquote><div><br>Rhetorical question: do you have =
enough experience with metaprogramming in order to judge about it?<br><br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>OK, how about the fact tha=
t () means something else? Names followed by () means "call a function."</d=
iv></blockquote></div><div><br>How about macro invocations? How about funct=
ion parameter lists? How about function-style type conversions to built-in =
types?<br><br></div><div></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div> The only thing we have that standardizes a library convention in a l=
anguage feature currently is range-based for, which relies upon std::begin/=
end and the iterator concepts. And even that is primarily for extensibility=
, so that you can allow iteration over arbitrary containers.<br><br>To do w=
hat you're suggesting is to effectively say that this is the only correct m=
etafunction syntax. It favors one convention over another.<br></div></block=
quote><div><br>So what? Let's ban range-based for?<br><br>On Saturday, Febr=
uary 16, 2013 6:17:24 PM UTC+4, Vicente J. Botet Escriba wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">Anyway you could say that eq_result<T>
designates a dummy.</div></blockquote><div><br>We don't need has_eq the=
n :-) Dummy type can be defined so that it would not be convertible to bool=
..<br><br>On Saturday, February 16, 2013 8:17:36 PM UTC+4, Vicente J. Botet =
Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">template<typename T>
<br>
struct eq_result_impl
<br>
{
<br>
template<typename X>
<br>
static auto check(const X& x) -> decltype(x =
=3D=3D x);
<br>
static subst_failure check(...);
<br>
using type =3D decltype(check(declval<T>()));
<br>
};
<br>
template<typename T>
<br>
using eq_result =3D typename eq_result_impl<T>::type;
<br>
template<typename T>
<br>
struct has_eq
<br>
: integral_constant<bool, !is_same<eq_result<T>,
subst_failure>::value>
<br>
{ };<br>
<br>
As you can see the definitions are robust and well-formed.<br></div></b=
lockquote><div> <br>Strictly
speaking, it's not correct (failure cases: cv void, arrays of unknown=20
bound, volatile-qualified equatity-comparable types), but usually it=20
would work as expected.<br></div></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1021_20690179.1361049865258--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 16 Feb 2013 15:05:59 -0800 (PST)
Raw View
------=_Part_625_9152530.1361055959742
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 16, 2013 1:24:25 PM UTC-8, Nikolay Ivchenkov wrote:
>
> On Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:
>>
>> The existing solution works. It fits into the language. It's useful for
>> more than just instantiating metafunctions. It uses existing syntax rather
>> than creating its own.
>>
>
> I could say similar things about
>
> for (auto i = range.begin(); i != range.end(); ++i)
>
> The question is: so what? Range-based "for" is useless?
>
That's not the code produced by a range-based for-loop. Range-for
guaranteed that it will call range.end() exactly once. Yours does not, and
therefore is open to potential performance issues.
So that right there is a strong disproof of range-based for being
"useless": doing it the right way takes a lot more effort. Which is exactly
why the feature exists: to keep people from screwing it up.
You could try to say the same thing about metafunctions. And you'd be
correct if you stick with `typename ::type` coding, though that will
generally cause compiler errors if you don't use it correctly. But if
you're using template aliases in addition to your metafunctions, then
you've got no problem with that. So the "difficult to use" problem is
solved via existing functionality, and the solution requires nothing more
than one line of code that introduces a new typename.
Which brings me to the next point. The only thing this feature will do is
avoid the introduction of a second typename via template alias, or avoid
the use of a lot of `typename ::type` in a lot of metaprogramming. Why is
avoiding the addition of a template alias (and thus introducing a second
typename) so important in this particular case that C++ *needs* to have a
whole language feature that serves *no other purpose* than to resolve this?
To look at it a different way, the downside of not having range-based for,
beside user convenience, is a potential performance issue from people not
writing the loop correctly. The downside of not having what you're
suggesting... is that programmers will introduce more typenames. Typenames,
within a namespace, are not a limited resource that needs to be conserved.
We all have our pet features that would make our personal spheres of C++
easier. But this problem? It's far from *urgent*, even within the
metaprogramming sphere. I'd say that metaprogramming needs `static if` 30x
more than it needs this. I just don't see how saving a typename is worth a
whole language feature.
I don't see any *objective* downside here
>>
>
> I don't worry much about that.
>
Are you suggesting that the committee consider this change solely because
you personally don't like adding a a few typenames to your namespaces?
Without anything being *objectively* wrong with the status quo?
I don't see the need for introducing such a language feature
>>
>
> Rhetorical question: do you have enough experience with metaprogramming in
> order to judge about it?
>
> OK, how about the fact that () means something else? Names followed by ()
>> means "call a function."
>>
>
> How about macro invocations? How about function parameter lists? How about
> function-style type conversions to built-in types?
>
Function parameter lists are meant to mirror function call syntax, much
like template parameter lists mirror template instantiation syntax. So ()
is still about functions. Function-style type conversions are still calling
functions, even if they're built-in. Functionally, it's no different than
creating a temporary... which is exactly what it's doing.
The only thing we have that standardizes a library convention in a language
>> feature currently is range-based for, which relies upon std::begin/end and
>> the iterator concepts. And even that is primarily for extensibility, so
>> that you can allow iteration over arbitrary containers.
>>
>> To do what you're suggesting is to effectively say that this is the only
>> correct metafunction syntax. It favors one convention over another.
>>
>
> So what? Let's ban range-based for?
>
Range-based `for` can be extended to other types unintrusively; that's why
it uses iterator syntax. Your metafunction syntax cannot be unintrusively
applied to arbitrary metafunctions. At least, not without creating a
wrapper type, which is functionally identical to just using a template
alias, as you wind up with two separate typenames. Which is exactly what
this feature is trying to avoid.
--
---
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.
------=_Part_625_9152530.1361055959742
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, February 16, 2013 1:24:25 PM UTC-8, Nikolay Ivchenkov =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, February 16=
, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div>The existing solution works. It fits into the language. It's u=
seful for more than just instantiating metafunctions. It uses existing synt=
ax rather than creating its own.</div></blockquote><div><br>I could say sim=
ilar things about<br><br> for (auto i =3D range.begin(); i !=
=3D range.end(); ++i)<br><br>The question is: so what? Range-based "for" is=
useless?<br></div></blockquote><div><br>That's not the code produced by a =
range-based for-loop. Range-for guaranteed that it will call range.end() ex=
actly once. Yours does not, and therefore is open to potential performance =
issues.<br><br>So that right there is a strong disproof of range-based for =
being "useless": doing it the right way takes a lot more effort. Which is e=
xactly why the feature exists: to keep people from screwing it up.<br><br>Y=
ou could try to say the same thing about metafunctions. And you'd be correc=
t if you stick with `typename ::type` coding, though that will generally ca=
use compiler errors if you don't use it correctly. But if you're using temp=
late aliases in addition to your metafunctions, then you've got no problem =
with that. So the "difficult to use" problem is solved via existing functio=
nality, and the solution requires nothing more than one line of code that i=
ntroduces a new typename.<br><br>Which brings me to the next point. The onl=
y thing this feature will do is avoid the introduction of a second typename=
via template alias, or avoid the use of a lot of `typename ::type` in a lo=
t of metaprogramming. Why is avoiding the addition of a template alias (and=
thus introducing a second typename) so important in this particular case t=
hat C++ <i>needs</i> to have a whole language feature that serves <i>no oth=
er purpose</i> than to resolve this?<br><br>To look at it a different way, =
the downside of not having range-based for, beside user convenience, is a p=
otential performance issue from people not writing the loop correctly. The =
downside of not having what you're suggesting... is that programmers will i=
ntroduce more typenames. Typenames, within a namespace, are not a limited r=
esource that needs to be conserved.<br><br>We all have our pet features tha=
t would make our personal spheres of C++ easier. But this problem? It's far=
from <i>urgent</i>, even within the metaprogramming sphere. I'd say that m=
etaprogramming needs `static if` 30x more than it needs this. I just don't =
see how saving a typename is worth a whole language feature.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div>I don't see any <i>objective</i> downside here</di=
v></blockquote><div><br>I don't worry much about that.<br></div></blockquot=
e><div><br>Are you suggesting that the committee consider this change solel=
y because you personally don't like adding a a few typenames to your namesp=
aces? Without anything being <i>objectively</i> wrong with the status quo?<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>I don't see the need for introducing=
such a language feature</div></blockquote><div><br>Rhetorical question: do=
you have enough experience with metaprogramming in order to judge about it=
?<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>OK, how about the fac=
t that () means something else? Names followed by () means "call a function=
.."</div></blockquote></div><div><br>How about macro invocations? How about =
function parameter lists? How about function-style type conversions to buil=
t-in types?<br></div></blockquote><div><br>Function parameter lists are mea=
nt to mirror function call syntax, much like template parameter lists mirro=
r template instantiation syntax. So () is still about functions. Function-s=
tyle type conversions are still calling functions, even if they're built-in=
.. Functionally, it's no different than creating a temporary... which is exa=
ctly what it's doing.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div></div><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div> T=
he only thing we have that standardizes a library convention in a language =
feature currently is range-based for, which relies upon std::begin/end and =
the iterator concepts. And even that is primarily for extensibility, so tha=
t you can allow iteration over arbitrary containers.<br><br>To do what you'=
re suggesting is to effectively say that this is the only correct metafunct=
ion syntax. It favors one convention over another.<br></div></blockquote><d=
iv><br>So what? Let's ban range-based for?<br></div></blockquote><div><br>R=
ange-based `for` can be extended to other types unintrusively; that's why i=
t uses iterator syntax. Your metafunction syntax cannot be unintrusively ap=
plied to arbitrary metafunctions. At least, not without creating a wrapper =
type, which is functionally identical to just using a template alias, as yo=
u wind up with two separate typenames. Which is exactly what this feature i=
s trying to avoid.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_625_9152530.1361055959742--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Sun, 17 Feb 2013 00:05:05 -0800 (PST)
Raw View
------=_Part_1142_24666088.1361088305223
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, February 17, 2013 3:05:59 AM UTC+4, Nicol Bolas wrote:
>
> On Saturday, February 16, 2013 1:24:25 PM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:
>>>
>>> The existing solution works. It fits into the language. It's useful for
>>> more than just instantiating metafunctions. It uses existing syntax rather
>>> than creating its own.
>>>
>>
>> I could say similar things about
>>
>> for (auto i = range.begin(); i != range.end(); ++i)
>>
>> The question is: so what? Range-based "for" is useless?
>>
>
> That's not the code produced by a range-based for-loop. Range-for
> guaranteed that it will call range.end() exactly once. Yours does not, and
> therefore is open to potential performance issues.
>
That's mostly theoretical issue. How often do we have expensive
range.end()? And even if range.end() is expensive, we can always guarantee
that it will be evaluated only once.
Which brings me to the next point. The only thing this feature will do is
> avoid the introduction of a second typename via template alias, or avoid
> the use of a lot of `typename ::type` in a lot of metaprogramming. Why is
> avoiding the addition of a template alias (and thus introducing a second
> typename) so important in this particular case that C++ *needs* to have a
> whole language feature that serves *no other purpose* than to resolve
> this?
>
The "whole language feature" is actually a very small language extension.
The motivation is simple: we get rid of redundant entities in programs and
so make 'em more simple.
We all have our pet features that would make our personal spheres of C++
> easier. But this problem? It's far from *urgent*
>
I didn't say that it's urgent. I can live with alias templates (and I'm
using them right now, because currently I have no other choice when I want
to get rid of typename ::type).
I'd say that metaprogramming needs `static if` 30x more than it needs this
>
static if is not a syntactic sugar. It's very heavy feature that requires
much more time for standardization.
I don't see any *objective* downside here
>>>
>>
>> I don't worry much about that.
>>
>
> Are you suggesting that the committee consider this change solely because
> you personally don't like adding a a few typenames to your namespaces?
>
AFAICS, you're not a member of the committee, so your opinion doesn't
matter.
> Without anything being *objectively* wrong with the status quo?
>
That's just your point of view, which is not an ultimate truth.
Function parameter lists are meant to mirror function call syntax, much
> like template parameter lists mirror template instantiation syntax. So ()
> is still about functions.
>
That's a pure sophistic. I'm tired of your demagogic speech and I won't
discuss anything with you until you begin to provide normal arguments.
Function-style type conversions are still calling functions, even if
> they're built-in.
>
std::size_t(-1) is not a function call.
--
---
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.
------=_Part_1142_24666088.1361088305223
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, February 17, 2013 3:05:59 AM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Saturday, February 16, 2013 1:24:25 P=
M UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On=
Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div>The existing solution works. It fits int=
o the language. It's useful for more than just instantiating metafunctions.=
It uses existing syntax rather than creating its own.</div></blockquote><d=
iv><br>I could say similar things about<br><br> for (auto i =
=3D range.begin(); i !=3D range.end(); ++i)<br><br>The question is: so what=
? Range-based "for" is useless?<br></div></blockquote><div><br>That's not t=
he code produced by a range-based for-loop. Range-for guaranteed that it wi=
ll call range.end() exactly once. Yours does not, and therefore is open to =
potential performance issues.<br></div></blockquote><div><br>That's mostly =
theoretical issue. How often do we have expensive range.end()? And even if =
range.end() is expensive, we can always guarantee that it will be evaluated=
only once.<br><br> </div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
>Which brings me to the next point. The only thing this feature will do is =
avoid the introduction of a second typename via template alias, or avoid th=
e use of a lot of `typename ::type` in a lot of metaprogramming. Why is avo=
iding the addition of a template alias (and thus introducing a second typen=
ame) so important in this particular case that C++ <i>needs</i> to have a w=
hole language feature that serves <i>no other purpose</i> than to resolve t=
his?<br></div></blockquote><div><br>The "whole language feature" is actuall=
y a very small language extension. The motivation is simple: we get rid of =
redundant entities in programs and so make 'em more simple.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div>We all have our pet feature=
s that would make our personal spheres of C++ easier. But this problem? It'=
s far from <i>urgent</i></div></blockquote><div><br>I didn't say that it's =
urgent. I can live with alias templates (and I'm using them right now, beca=
use currently I have no other choice when I want to get rid of typename ::t=
ype).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I'd sa=
y that metaprogramming needs `static if` 30x more than it needs this</div><=
/blockquote><div><br>static if is not a syntactic sugar. It's very heavy fe=
ature that requires much more time for standardization.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I do=
n't see any <i>objective</i> downside here</div></blockquote><div><br>I don=
't worry much about that.<br></div></blockquote><div><br>Are you suggesting=
that the committee consider this change solely because you personally don'=
t like adding a a few typenames to your namespaces?</div></blockquote><div>=
<br>AFAICS, you're not a member of the committee, so your opinion doesn't m=
atter.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> Wi=
thout anything being <i>objectively</i> wrong with the status quo?<br></div=
></blockquote><div><br>That's just your point of view, which is not an ulti=
mate truth.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div></div></blockquote><div>=
Function parameter lists are meant to mirror function call syntax, much lik=
e template parameter lists mirror template instantiation syntax. So () is s=
till about functions.</div></blockquote><div><br>That's a pure sophistic. I=
'm tired of your demagogic speech and I won't discuss anything with you unt=
il you begin to provide normal arguments.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div> Function-style type conversions are still ca=
lling functions, even if they're built-in.</div></blockquote><div><br>std::=
size_t(-1) is not a function call.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1142_24666088.1361088305223--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 17 Feb 2013 20:40:46 -0800 (PST)
Raw View
------=_Part_734_32924661.1361162446741
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, February 17, 2013 12:05:05 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Sunday, February 17, 2013 3:05:59 AM UTC+4, Nicol Bolas wrote:
>>
>> On Saturday, February 16, 2013 1:24:25 PM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>> On Saturday, February 16, 2013 5:28:54 PM UTC+4, Nicol Bolas wrote:
>>>>
>>>> The existing solution works. It fits into the language. It's useful for
>>>> more than just instantiating metafunctions. It uses existing syntax rather
>>>> than creating its own.
>>>>
>>>
>>> I could say similar things about
>>>
>>> for (auto i = range.begin(); i != range.end(); ++i)
>>>
>>> The question is: so what? Range-based "for" is useless?
>>>
>>
>> That's not the code produced by a range-based for-loop. Range-for
>> guaranteed that it will call range.end() exactly once. Yours does not, and
>> therefore is open to potential performance issues.
>>
>
> That's mostly theoretical issue. How often do we have expensive
> range.end()? And even if range.end() is expensive, we can always guarantee
> that it will be evaluated only once.
>
My point remains: range-based for makes looping over a container work
correctly, every time, with zero performance loss no matter how you
implement range.end(), and no chance for the user to screw it up.
That is a demonstrable, objective improvement to the status quo: preventing
mistakes that are both common and widely known.
So where is the equivalent for your feature? Show me where introducing a
template alias is something users can fail to do correctly and still get
compiling code. Show me where using a template alias leads to performance
degradation.
Your argument right now is "we should have this because I don't like using
template aliases for it."
Which brings me to the next point. The only thing this feature will do is
>> avoid the introduction of a second typename via template alias, or avoid
>> the use of a lot of `typename ::type` in a lot of metaprogramming. Why is
>> avoiding the addition of a template alias (and thus introducing a second
>> typename) so important in this particular case that C++ *needs* to have
>> a whole language feature that serves *no other purpose* than to resolve
>> this?
>>
>
> The "whole language feature" is actually a very small language extension.
> The motivation is simple: we get rid of redundant entities in programs and
> so make 'em more simple.
>
Very small? You want a new template instantiation syntax; that's not "very
small" by any measurement. Oh, it would be fairly minor to implement. And
the spec language won't be particularly extensive. But the *ramifications*of it are not "very small".
For example, introducing this syntax means that the syntax can't be used
for something else in the future. One of the reasons why braced-init-lists
can't be used in template argument deduction cases is precisely because
they wanted to leave options available for potential ways of standardizing.
Maybe they could turn it into a std::tuple<>, or even a language-based
tuple. Or whatever. So they made it illegal to leave design space open.
What if someone wanted `template_name(arguments)` to perform
template-argument deduction and overload resolution on the set of
constructors for a `template_name` type? Right now, we have to create
template functions and forward parameters, so adding this is not an
unreasonable thing to want to do.
But here's your syntax, getting in the way of that. So if your syntax is to
be adopted, we would have to be certain that we *never want to do this* (or
that we will make people use uniform initialization syntax for it, which
also means *fixing* uniform initialization syntax).
That's the kind of stuff the committee will have to discuss. They'll also
have to discuss alternate syntax ( `()` vs `[]`). Because of its narrow
focus, people are going to want to expand its scope to make it useful for
more things. Maybe `template(args)` could also evaluate `::value` if it's
present? Or maybe there should be some mechanism for a user to specify a
default evaluation, so that `template(args)` could evaluate to whatever the
maker of `template` wants.
All of this is going to take committee time. This is not a "very small
language extension" at all. Indeed, there *are no* small language
extensions (for the most part). The time they will spend discussing this is
time not spent on real problems.
Function parameter lists are meant to mirror function call syntax, much
>> like template parameter lists mirror template instantiation syntax. So ()
>> is still about functions.
>>
> That's a pure sophistic. I'm tired of your demagogic speech and I won't
> discuss anything with you until you begin to provide normal arguments.
>
sophistic <http://dictionary.reference.com/browse/sophistic?db=*>: of the
nature of sophistry; fallacious.
sophistry <http://dictionary.reference.com/browse/sophistry>: a subtle,
tricky, superficially plausible, but generally fallacious method of
reasoning.
Calling the opposing argument fallacious without providing evidence on how
it is so is itself fallacious.
FYI, the correct term for the logical fallacy I employed is "moving the
goalposts <http://en.wikipedia.org/wiki/Moving_the_goalposts>", (since my
original claim was that () was for *calling *functions). But I guess
whipping out $10 words is more important than making a solid argument or
showing the opposing argument to be faulty.
Oh, and there's nothing "tricky" about the fact that function definition
syntax mirrors function call syntax. That was done intentionally by the
designers of the language.
Lastly, if you really wanted to shut my argument down, just point out that
metafunctions *are functions*; they just operate on types instead of
values. I was practically baiting that response out.
--
---
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.
------=_Part_734_32924661.1361162446741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, February 17, 2013 12:05:05 AM UTC-8, Nikolay Ivchenkov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, February 17, 2013 3:05=
:59 AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On =
Saturday, February 16, 2013 1:24:25 PM UTC-8, Nikolay Ivchenkov wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">On Saturday, February 16, 2013 5:28:54 P=
M UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The=
existing solution works. It fits into the language. It's useful for more t=
han just instantiating metafunctions. It uses existing syntax rather than c=
reating its own.</div></blockquote><div><br>I could say similar things abou=
t<br><br> for (auto i =3D range.begin(); i !=3D range.end(); +=
+i)<br><br>The question is: so what? Range-based "for" is useless?<br></div=
></blockquote><div><br>That's not the code produced by a range-based for-lo=
op. Range-for guaranteed that it will call range.end() exactly once. Yours =
does not, and therefore is open to potential performance issues.<br></div><=
/blockquote><div><br>That's mostly theoretical issue. How often do we have =
expensive range.end()? And even if range.end() is expensive, we can always =
guarantee that it will be evaluated only once.<br></div></blockquote><div><=
br>My point remains: range-based for makes looping over a container work co=
rrectly, every time, with zero performance loss no matter how you implement=
range.end(), and no chance for the user to screw it up.<br><br>That is a d=
emonstrable, objective improvement to the status quo: preventing mistakes t=
hat are both common and widely known.<br><br>So where is the equivalent for=
your feature? Show me where introducing a template alias is something user=
s can fail to do correctly and still get compiling code. Show me where usin=
g a template alias leads to performance degradation.<br><br>Your argument r=
ight now is "we should have this because I don't like using template aliase=
s for it."<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>Which brings me to the n=
ext point. The only thing this feature will do is avoid the introduction of=
a second typename via template alias, or avoid the use of a lot of `typena=
me ::type` in a lot of metaprogramming. Why is avoiding the addition of a t=
emplate alias (and thus introducing a second typename) so important in this=
particular case that C++ <i>needs</i> to have a whole language feature tha=
t serves <i>no other purpose</i> than to resolve this?<br></div></blockquot=
e><div><br>The "whole language feature" is actually a very small language e=
xtension. The motivation is simple: we get rid of redundant entities in pro=
grams and so make 'em more simple.<br></div></blockquote><div><br>Very smal=
l? You want a new template instantiation syntax; that's not "very small" by=
any measurement. Oh, it would be fairly minor to implement. And the spec l=
anguage won't be particularly extensive. But the <i>ramifications</i> of it=
are not "very small".<br><br>For example, introducing this syntax means th=
at the syntax can't be used for something else in the future. One of the re=
asons why braced-init-lists can't be used in template argument deduction ca=
ses is precisely because they wanted to leave options available for potenti=
al ways of standardizing. Maybe they could turn it into a std::tuple<>=
;, or even a language-based tuple. Or whatever. So they made it illegal to =
leave design space open.<br><br>What if someone wanted `template_name(argum=
ents)` to perform template-argument deduction and overload resolution on th=
e set of constructors for a `template_name` type? Right now, we have to cre=
ate template functions and forward parameters, so adding this is not an unr=
easonable thing to want to do.<br><br>But here's your syntax, getting in th=
e way of that. So if your syntax is to be adopted, we would have to be cert=
ain that we <i>never want to do this</i> (or that we will make people use u=
niform initialization syntax for it, which also means <i>fixing</i> uniform=
initialization syntax).<br><br>That's the kind of stuff the committee will=
have to discuss. They'll also have to discuss alternate syntax ( `()` vs `=
[]`). Because of its narrow focus, people are going to want to expand its s=
cope to make it useful for more things. Maybe `template(args)` could also e=
valuate `::value` if it's present? Or maybe there should be some mechanism =
for a user to specify a default evaluation, so that `template(args)` could =
evaluate to whatever the maker of `template` wants.<br><br>All of this is g=
oing to take committee time. This is not a "very small language extension" =
at all. Indeed, there <i>are no</i> small language extensions (for the most=
part). The time they will spend discussing this is time not spent on real =
problems.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div></div></blockquote><div>Function parameter lists a=
re meant to mirror function call syntax, much like template parameter lists=
mirror template instantiation syntax. So () is still about functions.</div=
></blockquote><div>That's a pure sophistic. I'm tired of your demagogic spe=
ech and I won't discuss anything with you until you begin to provide normal=
arguments.<br></div></blockquote><div><br><a href=3D"http://dictionary.ref=
erence.com/browse/sophistic?db=3D*">sophistic</a>: of the nature of sophist=
ry; fallacious.<br><br><a href=3D"http://dictionary.reference.com/browse/so=
phistry">sophistry</a>: a subtle, tricky, superficially plausible, but gene=
rally fallacious method of reasoning.<br><br>Calling the opposing argument =
fallacious without providing evidence on how it is so is itself fallacious.=
<br><br>FYI, the correct term for the logical fallacy I employed is "<a hre=
f=3D"http://en.wikipedia.org/wiki/Moving_the_goalposts">moving the goalpost=
s</a>", (since my original claim was that () was for <i>calling </i>functio=
ns). But I guess whipping out $10 words is more important than making a sol=
id argument or showing the opposing argument to be faulty.<br><br>Oh, and t=
here's nothing "tricky" about the fact that function definition syntax mirr=
ors function call syntax. That was done intentionally by the designers of t=
he language.<br><br>Lastly, if you really wanted to shut my argument down, =
just point out that metafunctions <i>are functions</i>; they just operate o=
n types instead of values. I was practically baiting that response out.<br>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_734_32924661.1361162446741--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Mon, 18 Feb 2013 12:05:23 -0800 (PST)
Raw View
------=_Part_1424_4164825.1361217923096
Content-Type: text/plain; charset=ISO-8859-1
On Monday, February 18, 2013 8:40:46 AM UTC+4, Nicol Bolas wrote:
>
>
> My point remains: range-based for makes looping over a container work
> correctly, every time, with zero performance loss no matter how you
> implement range.end(), and no chance for the user to screw it up.
>
I consider that as a contrived reasoning.
Your argument right now is "we should have this because I don't like using
> template aliases for it."
>
Write-only mode on? My point is "it would be nice to have short notation
without redundant entities in programs".
For example, introducing this syntax means that the syntax can't be used
> for something else in the future.
>
There are ways to provide similar alternative syntax. For example, name!(),
which is used in D.
What if someone wanted `template_name(arguments)` to perform
> template-argument deduction and overload resolution on the set of
> constructors for a `template_name` type? Right now, we have to create
> template functions and forward parameters, so adding this is not an
> unreasonable thing to want to do.
>
It's unlikely that such feature will ever be introduced. Constructors can
be overloaded and class templates can be specialized, so I hardly imagine
sensible deduction rules for that.
Calling the opposing argument fallacious without providing evidence on how
> it is so is itself fallacious.
>
I don't recognize a sensible argument in your casuistry around function
calls.
This is a typical holy war, where each side considers its own arguments as
relevant and important, but arguments from the opposite side as irrelevant
and/or unimportant. The typical outcome of such discussions is that all
sides remain with their original opinions + optionally begin to think that
opponents are very strange people (maybe from other planet). I don't
participate in such silly conversations on principle, so you can go on
without me if you want.
--
---
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.
------=_Part_1424_4164825.1361217923096
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, February 18, 2013 8:40:46 AM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br><div>My point remains: range-based f=
or makes looping over a container work correctly, every time, with zero per=
formance loss no matter how you implement range.end(), and no chance for th=
e user to screw it up.<br></div></blockquote><div><br>I consider that as a =
contrived reasoning.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>Your argument right now is "we should have this because I don't =
like using template aliases for it."<br></div></blockquote><div><br>Write-o=
nly mode on? My point is "it would be nice to have short notation without r=
edundant entities in programs".<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div>For example, introducing this syntax means that the syn=
tax can't be used for something else in the future.</div></blockquote><div>=
<br>There are ways to provide similar alternative syntax. For example, name=
!(), which is used in D.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div> What if someone wanted `template_name(arguments)` to perform =
template-argument deduction and overload resolution on the set of construct=
ors for a `template_name` type? Right now, we have to create template funct=
ions and forward parameters, so adding this is not an unreasonable thing to=
want to do.<br></div></blockquote><div><br>It's unlikely that such feature=
will ever be introduced. Constructors can be overloaded and class template=
s can be specialized, so I hardly imagine sensible deduction rules for that=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><div=
>Calling the opposing argument fallacious without providing evidence on how=
it is so is itself fallacious.<br></div></blockquote><div><br>I don't reco=
gnize a sensible argument in your casuistry around function calls.<br><br>T=
his is a typical holy war, where each side considers its own arguments as r=
elevant and important, but arguments from the opposite side as irrelevant a=
nd/or unimportant. The typical outcome of such discussions is that all side=
s remain with their original opinions + optionally begin to think that oppo=
nents are very strange people (maybe from other planet). I don't participat=
e in such silly conversations on principle, so you can go on without me if =
you want.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1424_4164825.1361217923096--
.