Topic: N4381 ! Customization points - Not ADL customized functions
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 30 Apr 2015 11:05:30 +0200
Raw View
This is a multi-part message in MIME format.
--------------090106050302070707090802
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
N4381 defines a customization-point as
"function used by the Standard Library that can be overloaded on=20
user-defined types in the user=E2=80=99s namespace and that is found by=20
argument-dependent lookup"
One of the problem with this kind of customization points is that they=20
add a new "keyword" name. E.g. begin(), end(), swap(), size().
If customization points proliferate, the name space on the user side=20
will be reduced considerably, and so the chances we add more=20
customization points in the standard will be reduced. I believe that a=20
customized point must be associated to a specific "concept/ type of=20
types" and that the name of the type of types must be used explicitly.
I was wondering if a customization-point shouldn't be identified in a=20
more explicit way. As Eric pointed out, a customization point should=20
follow the Method pattern. That is the specific customization should not=20
bypass any constraint defined on the customized point.
*What I proposing here doesn't take into account the current standard=20
customization-points**, nor I'm proposing to change them.**
*
I suggest that these functions should always be called using the=20
specific type of types. If a customized point is associated to a "type=20
of types" XXX,
G1 - it can be called only as XXX::cust(a) outside the scope of XXX
G2 - a call to using XXX; cust(a) should be an error, that is the=20
type of types is not a namespace.
Using a struct to represents a "type of types" and static function to=20
represent the customized points seems to respond well to the first and=20
third goal.
struct XXX {
template <class R>
static auto begin(R&& r) { return XXX_cust_begin(forward(r)) }
template <class R>
static auto end(R&& r) { return XXX_custo_end(forward(r)) }
};
This is just an example of customized points using overload on a=20
specific overloaded function.
This doesn't means that we can not have other ways to customize. E.g.=20
the proposed Boost.Hana uses some kind of traits to customize together=20
several operations.
struct XXX {
template <class R> instance; // customization point for all the=20
functions
template <class R>
static auto begin(R&& r) { return XXX::instance<R>::begin(forward(r)) =
}
template <class R>
static auto end(R&& r) { return XXX::instance<R>::end(forward(r)) }
};
Independently on how the customization has been done, the user calls=20
always the customized point always in the same way, a call to a=20
qualified function.
XXX::begin(r);
XXX::end(r);
This has the advantage to don't pollute the user space and the liability=20
to been longer.
But we need to be able refine also "type of types". Using public=20
inheritance seem to work well
struct YYY : XXX {
template <class R>
static auto size(R&& r) { return XXX_cust_size(forward(r)) }
};
YYY::begin(r);
YYY::end(r);
YYY::size(r);
As you can see the problem would be in finding the correct namess for=20
XXX and YYY, but we know already how to do that this (concepts, ...)
We could think of adding a supplementary goal
G3 - a call to cust(a) should be an error outside the Type scope.
Fist this will pollute the user name space, as s/he couldn't use the=20
customized point in their application other than associated to the=20
customized type of types.
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/.
--------------090106050302070707090802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<font size=3D"+1">Hi, <br>
<br>
N4381 defines a customization-point as <br>
=C2=A0=C2=A0=C2=A0 "</font>function used by the Standard Library that=
can be
overloaded on user-defined types in the user=E2=80=99s namespace and th=
at is
found by argument-dependent lookup"<br>
<br>
One of the problem with this kind of customization points is that
they add a new "keyword" name. E.g. begin(), end(), swap(), size().<br>
<br>
If customization points proliferate, the name space on the user side
will be reduced considerably, and so the chances we add more
customization points in the standard will be reduced. I believe that
a customized point must be associated to a specific "concept/ type
of types" and that the name of the type of types must be used
explicitly. <br>
<br>
I was wondering if a customization-point shouldn't be identified in
a more explicit way. As Eric pointed out, a customization point
should follow the Method pattern. That is the specific customization
should not bypass any constraint defined on the customized point.<br>
<br>
<b>What I proposing here doesn't take into account the current
standard customization-points</b><b>, nor I'm proposing to change
them.</b><b><br>
</b><br>
I suggest that these functions should always be called using the
specific type of types. If a customized point is associated to a
"type of types" XXX,<br>
=C2=A0=C2=A0=C2=A0 G1 -=C2=A0 it can be called only as XXX::cust(a) out=
side the scope of
XXX <br>
=C2=A0=C2=A0=C2=A0 G2 -=C2=A0 a call to using XXX; cust(a) should be an=
error, that is
the type of types is not a namespace.<br>
<br>
Using a struct to represents a "type of types" and static function
to represent the customized points seems to respond well to the
first and third goal.<br>
<br>
struct XXX {<br>
=C2=A0=C2=A0=C2=A0 template <class R><br>
=C2=A0=C2=A0=C2=A0 static auto begin(R&& r) { return
XXX_cust_begin(forward(r)) }<br>
=C2=A0=C2=A0=C2=A0 template <class R><br>
=C2=A0=C2=A0=C2=A0 static auto end(R&& r) { return
XXX_custo_end(forward(r)) }<br>
};<br>
<br>
This is just an example of customized points using overload on a
specific overloaded function. <br>
This doesn't means that we can not have other ways to customize.
E.g. the proposed Boost.Hana uses some kind of traits to customize
together several operations.<br>
<br>
struct XXX {<br>
=C2=A0=C2=A0=C2=A0 template <class R> instance; // customization =
point for
all the functions<br>
=C2=A0=C2=A0=C2=A0 template <class R><br>
=C2=A0=C2=A0=C2=A0 static auto begin(R&& r) { return
XXX::instance<R>::begin(forward(r)) }<br>
=C2=A0=C2=A0=C2=A0 template <class R><br>
=C2=A0=C2=A0=C2=A0 static auto end(R&& r) { return
XXX::instance<R>::end(forward(r)) }<br>
};<br>
<br>
Independently on how the customization has been done, the user calls
always the customized point always in the same way, a call to a
qualified function.<br>
<br>
XXX::begin(r);<br>
XXX::end(r);<br>
<br>
This has the advantage to don't pollute the user space and the
liability to been longer.<br>
<br>
But we need to be able refine also "type of types". Using public
inheritance seem to work well<br>
<br>
struct YYY : XXX {<br>
=C2=A0=C2=A0=C2=A0 template <class R><br>
=C2=A0=C2=A0=C2=A0 static auto size(R&& r) { return
XXX_cust_size(forward(r)) }<br>
};<br>
<br>
YYY::begin(r);<br>
YYY::end(r);<br>
YYY::size(r);<br>
<br>
As you can see the problem would be in finding the correct namess
for XXX and YYY, but we know already how to do that this (concepts,
...)<br>
<br>
We could think of adding a supplementary goal<br>
=C2=A0=C2=A0=C2=A0 G3 -=C2=A0 a call to cust(a) should be an error outs=
ide the Type
scope.<br>
<br>
Fist this will pollute the user name space, as s/he couldn't use the
customized point in their application other than associated to the
customized type of types.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------090106050302070707090802--
.