On 9 May 2014 15:48, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> C++11 allows to overload std::begin/end.
>
> Having two different overloads for the same type results on a violation of
> the ODR (One Definition Rule), isn't it?

Yes. I would expect such overloads to be in different namespaces, in
which case it's
not an ODR violation.

> Does it means that it is a good idea to propose non-member function
> interfaces for other concepts, e.g. the functor/monad functions fmap(),
> mbind(), then() that can be implemented differently depending on the
> specific monad model (optional<T>, future<T>  or other UDT)?

I don't see non-member functions as problematic, especially compared to
adding multiple new member functions to multiple existing classes.

> If yes, should a proposal define all the overloads for all the C++ types
> that can be seen as a monad, as e.g. pointers, smart pointers, containers,
> range?


Probably. How else would it work with all types that can be seen as a monad?

--

---
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/.

.

Le 09/05/14 15:14, Ville Voutilainen a =C3=A9crit :
> On 9 May 2014 15:48, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> =
wrote:
>> Hi,
>>
>> C++11 allows to overload std::begin/end.
>>
>> Having two different overloads for the same type results on a violation =
of
>> the ODR (One Definition Rule), isn't it?
> Yes. I would expect such overloads to be in different namespaces, in
> which case it's
> not an ODR violation.
They will need to be on the namespace of the specific class X so that=20
ADL can be used.
>
>> Does it means that it is a good idea to propose non-member function
>> interfaces for other concepts, e.g. the functor/monad functions fmap(),
>> mbind(), then() that can be implemented differently depending on the
>> specific monad model (optional<T>, future<T>  or other UDT)?
> I don't see non-member functions as problematic, especially compared to
> adding multiple new member functions to multiple existing classes.
I prefer also non-member functions when them can be implemented using a=20
minimal interface. However this definition can be done on multiple and=20
independent files resulting in ODR violation.
>
>> If yes, should a proposal define all the overloads for all the C++ types
>> that can be seen as a monad, as e.g. pointers, smart pointers, container=
s,
>> range?
>
> Probably. How else would it work with all types that can be seen as a mon=
ad?
>
Right, there will be no other way :(

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/.

.

--Apple-Mail=_D765A42F-C4D0-450B-A3F6-C4B2E8AB649A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-09, at 8:48 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.=
fr> wrote:

> Hi,
>=20
> C++11 allows to overload std::begin/end.
>=20
> Having two different overloads for the same type results on a violation o=
f the ODR (One Definition Rule), isn't it?

The ODR isn't concerned with overloading per se. Declarations which fail to=
 overload per [over.load] =A713.1 and end up defining the same thing do vio=
late the ODR.

Note that range-based for loops seldom use free begin and end, not for arra=
ys or classes. The only things left with ADL compatibility are enumerations=
 and compound types such as pointers. You could also make crippled, non-ADL=
 overloads for the likes of char*, at your own risk. Such uses are a bit ex=
otic.

Overall, unlike swap, it's probably better to define begin and end as membe=
rs and leave the free function interface to the few corner cases where it's=
 necessary. The qualified names std::begin/std::end are then sufficiently g=
eneric.

> Does it means that it is a good idea to propose non-member function inter=
faces for other concepts, e.g. the functor/monad functions fmap(), mbind(),=
 then() that can be implemented differently depending on the specific monad=
 model (optional<T>, future<T>  or other UDT)?

This is a separate issue. The precedents of swap, begin, and end don't make=
 unqualified names better interfaces. They do give us solid experience, but=
 that experience shows that even experienced users seldom apply the using s=
td::*; declarations properly.

> If yes, should a proposal define all the overloads for all the C++ types =
that can be seen as a monad, as e.g. pointers, smart pointers, containers, =
range?

A proposal should describe a usable interface. Higher-order functions that =
work with raw function pointer types need to be either non-members or membe=
rs of a thin wrapper which supersedes the raw function pointer for that int=
erface. I'd favor a thin wrapper just for uniformity of an object-oriented =
interface.

Ranges, when finalized, will be preferable to free functions begin and end.=
 Non-polymorphic functor wrappers could be analogous.

--=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/.

--Apple-Mail=_D765A42F-C4D0-450B-A3F6-C4B2E8AB649A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05&ndash;09, at 8:48 PM, Vicente J. Botet Escriba &lt;<a href=3D"mail=
to:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Hi,<br><br=
>C++11 allows to overload std::begin/end.<br><br>Having two different overl=
oads for the same type results on a violation of the ODR (One Definition Ru=
le), isn't it?<br></blockquote><div><br></div><div>The ODR isn&rsquo;t conc=
erned with overloading per se. Declarations which fail to overload per [ove=
r.load] =A713.1 and end up defining the same thing do violate the ODR.</div=
><div><br></div><div>Note that range-based <font face=3D"Courier">for</font=
>&nbsp;loops seldom use free begin and end, not for arrays or classes. The =
only things left with ADL compatibility are enumerations and compound types=
 such as pointers. You could also make crippled, non-ADL overloads for the =
likes of <font face=3D"Courier">char*</font>, at your own risk. Such uses a=
re a bit exotic.</div><div><br></div><div>Overall, unlike <font face=3D"Cou=
rier">swap</font>, it&rsquo;s probably better to define&nbsp;<font face=3D"=
Courier">begin</font> and <font face=3D"Courier">end</font> as members and =
leave the free function interface to the few corner cases where it&rsquo;s =
necessary. The qualified names <font face=3D"Courier">std::begin</font>/<fo=
nt face=3D"Courier">std::end</font> are then sufficiently generic.</div><br=
><blockquote type=3D"cite">Does it means that it is a good idea to propose =
non-member function interfaces for other concepts, e.g. the functor/monad f=
unctions fmap(), mbind(), then() that can be implemented differently depend=
ing on the specific monad model (optional&lt;T&gt;, future&lt;T&gt; &nbsp;o=
r other UDT)?<br></blockquote><div><br></div>This is a separate issue. The =
precedents of swap, begin, and end don&rsquo;t make unqualified names bette=
r interfaces. They do give us solid experience, but that experience shows t=
hat even experienced users seldom apply the&nbsp;<font face=3D"Courier">usi=
ng std::*;</font> declarations properly.</div><div><br><blockquote type=3D"=
cite">If yes, should a proposal define all the overloads for all the C++ ty=
pes that can be seen as a monad, as e.g. pointers, smart pointers, containe=
rs, range?<br></blockquote><div><br></div><div>A proposal should describe a=
 usable interface. Higher-order functions that work with raw function point=
er types need to be either non-members or members of a thin wrapper which s=
upersedes the raw function pointer for that interface. I&rsquo;d favor a th=
in wrapper just for uniformity of an object-oriented interface.</div></div>=
<br><div>Ranges, when finalized, will be preferable to free functions begin=
 and end. Non-polymorphic functor wrappers could be analogous.</div><div><b=
r></div></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&quot; 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 />

--Apple-Mail=_D765A42F-C4D0-450B-A3F6-C4B2E8AB649A--

.

This is a multi-part message in MIME format.
--------------070902060905080302020302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 10/05/14 06:06, David Krauss a =E9crit :
>
> On 2014--05--09, at 8:48 PM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>> Hi,
>>
>> C++11 allows to overload std::begin/end.
>>
>> Having two different overloads for the same type results on a=20
>> violation of the ODR (One Definition Rule), isn't it?
>
> The ODR isn't concerned with overloading per se. Declarations which=20
> fail to overload per [over.load] =A713.1 and end up defining the same=20
> thing do violate the ODR.
>
> Note that range-based for loops seldom use free begin and end, not for=20
> arrays or classes. The only things left with ADL compatibility are=20
> enumerations and compound types such as pointers. You could also make=20
> crippled, non-ADL overloads for the likes of char*, at your own risk.=20
> Such uses are a bit exotic.
>
> Overall, unlike swap, it's probably better to define begin and end as=20
> members and leave the free function interface to the few corner cases=20
> where it's necessary. The qualified names std::begin/std::end are then=20
> sufficiently generic.
I agree that defining begin/end members functions would be a better=20
choice when possible. However you could have a 3pp or legacy class that=20
needs to be adapted. The overloading of the non-member begin/end=20
functions solves the issue. The problem is when two other 3pp libraries=20
define these overloads and you application integrates the three 3pp=20
libraries.
>
>> Does it means that it is a good idea to propose non-member function=20
>> interfaces for other concepts, e.g. the functor/monad functions=20
>> fmap(), mbind(), then() that can be implemented differently depending=20
>> on the specific monad model (optional<T>, future<T>  or other UDT)?
>
> This is a separate issue. The precedents of swap, begin, and end don't=20
> make unqualified names better interfaces. They do give us solid=20
> experience, but that experience shows that even experienced users=20
> seldom apply the using std::*; declarations properly.
I don't see that this is the problem. Any free function or class in std=20
namespace has the same issue.
>
>> If yes, should a proposal define all the overloads for all the C++=20
>> types that can be seen as a monad, as e.g. pointers, smart pointers,=20
>> containers, range?
>
> A proposal should describe a usable interface. Higher-order functions=20
> that work with raw function pointer types need to be either=20
> non-members or members of a thin wrapper which supersedes the raw=20
> function pointer for that interface. I'd favor a thin wrapper just for=20
> uniformity of an object-oriented interface.
>
Are you suggesting that the user will need to add a future_monad<T>=20
class that wraps a future and behaves as a monad? And a specific wrapper=20
future_xxx<T> for each concept xxx that future could be adapted to=20
conform with?

> Ranges, when finalized, will be preferable to free functions begin and=20
> end. Non-polymorphic functor wrappers could be analogous.
>
>
Do you have a reference of the current status of the Range proposal?
Could you elaborate on why non-polymorphic functor wrappers could be=20
preferable?


Thanks for you comments,
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/.

--------------070902060905080302020302
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 10/05/14 06:06, David Krauss a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On 2014&#8211;05&#8211;09, at 8:48 PM, Vicente J. Botet Escriba &lt;<a
            moz-do-not-send="true"
            href="mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">Hi,<br>
          <br>
          C++11 allows to overload std::begin/end.<br>
          <br>
          Having two different overloads for the same type results on a
          violation of the ODR (One Definition Rule), isn't it?<br>
        </blockquote>
        <div><br>
        </div>
        <div>The ODR isn&#8217;t concerned with overloading per se.
          Declarations which fail to overload per [over.load] &sect;13.1 and
          end up defining the same thing do violate the ODR.</div>
        <div><br>
        </div>
        <div>Note that range-based <font face="Courier">for</font>&nbsp;loops
          seldom use free begin and end, not for arrays or classes. The
          only things left with ADL compatibility are enumerations and
          compound types such as pointers. You could also make crippled,
          non-ADL overloads for the likes of <font face="Courier">char*</font>,
          at your own risk. Such uses are a bit exotic.</div>
        <div><br>
        </div>
        <div>Overall, unlike <font face="Courier">swap</font>, it&#8217;s
          probably better to define&nbsp;<font face="Courier">begin</font>
          and <font face="Courier">end</font> as members and leave the
          free function interface to the few corner cases where it&#8217;s
          necessary. The qualified names <font face="Courier">std::begin</font>/<font
            face="Courier">std::end</font> are then sufficiently
          generic.</div>
      </div>
    </blockquote>
    I agree that defining begin/end members functions would be a better
    choice when possible. However you could have a 3pp or legacy class
    that needs to be adapted. The overloading of the non-member
    begin/end functions solves the issue. The problem is when two other
    3pp libraries define these overloads and you application integrates
    the three 3pp libraries. <br>
    <blockquote
      cite="mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com"
      type="cite">
      <div><br>
        <blockquote type="cite">Does it means that it is a good idea to
          propose non-member function interfaces for other concepts,
          e.g. the functor/monad functions fmap(), mbind(), then() that
          can be implemented differently depending on the specific monad
          model (optional&lt;T&gt;, future&lt;T&gt; &nbsp;or other UDT)?<br>
        </blockquote>
        <div><br>
        </div>
        This is a separate issue. The precedents of swap, begin, and end
        don&#8217;t make unqualified names better interfaces. They do give us
        solid experience, but that experience shows that even
        experienced users seldom apply the&nbsp;<font face="Courier">using
          std::*;</font> declarations properly.</div>
    </blockquote>
    I don't see that this is the problem. Any free function or class in
    std namespace has the same issue.<br>
    <blockquote
      cite="mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com"
      type="cite">
      <div><br>
        <blockquote type="cite">If yes, should a proposal define all the
          overloads for all the C++ types that can be seen as a monad,
          as e.g. pointers, smart pointers, containers, range?<br>
        </blockquote>
        <div><br>
        </div>
        <div>A proposal should describe a usable interface. Higher-order
          functions that work with raw function pointer types need to be
          either non-members or members of a thin wrapper which
          supersedes the raw function pointer for that interface. I&#8217;d
          favor a thin wrapper just for uniformity of an object-oriented
          interface.</div>
      </div>
      <br>
    </blockquote>
    Are you suggesting that the user will need to add a
    future_monad&lt;T&gt; class that wraps a future and behaves as a
    monad? And a specific wrapper future_xxx&lt;T&gt; for each concept
    xxx that future could be adapted to conform with?<br>
    <br>
    <blockquote
      cite="mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com"
      type="cite">
      <div>Ranges, when finalized, will be preferable to free functions
        begin and end. Non-polymorphic functor wrappers could be
        analogous.</div>
      <div><br>
      </div>
      <br>
    </blockquote>
    Do you have a reference of the current status of the Range proposal?<br>
    Could you elaborate on why non-polymorphic functor wrappers could be
    preferable? <br>
    <br>
    <br>
    Thanks for you comments,<br>
    Vicente<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------070902060905080302020302--

.

--Apple-Mail=_961B0D81-D9F0-4B92-977B-94F0A16A8B3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-10, at 4:04 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.=
fr> wrote:

> Le 10/05/14 06:06, David Krauss a =E9crit :
>>=20
>> Note that range-based for loops seldom use free begin and end, not for a=
rrays or classes. The only things left with ADL compatibility are enumerati=
ons and compound types such as pointers. You could also make crippled, non-=
ADL overloads for the likes of char*, at your own risk. Such uses are a bit=
 exotic.
>>=20
>> Overall, unlike swap, it's probably better to define begin and end as me=
mbers and leave the free function interface to the few corner cases where i=
t's necessary. The qualified names std::begin/std::end are then sufficientl=
y generic.
> I agree that defining begin/end members functions would be a better choic=
e when possible. However you could have a 3pp or legacy class that needs to=
 be adapted. The overloading of the non-member begin/end functions solves t=
he issue.

No, as I mention above, class non-member begin/end will *not* be found by r=
ange-based for-loops (and that's the only thing I know that would go lookin=
g). It would be misleading to name a function as such, and confused users w=
ill need to refer to =A76.5.4 [stmt.ranged] to figure out why the non-membe=
r isn't getting called.

> The problem is when two other 3pp libraries define these overloads and yo=
u application integrates the three 3pp libraries.=20

Are you suggesting adding functions to third-party namespaces?

>> A proposal should describe a usable interface. Higher-order functions th=
at work with raw function pointer types need to be either non-members or me=
mbers of a thin wrapper which supersedes the raw function pointer for that =
interface. I'd favor a thin wrapper just for uniformity of an object-orient=
ed interface.
>>=20
> Are you suggesting that the user will need to add a future_monad<T> class=
 that wraps a future and behaves as a monad? And a specific wrapper future_=
xxx<T> for each concept xxx that future could be adapted to conform with?

Actually we already have a thin non-polymorphic functor wrapper: the result=
 of std::bind. So, the suggestion comes down to adding customizable higher-=
order functions as members by adding default implementations as members of =
bind objects and std::function, and requiring the user to adapt custom func=
tor types by std::bind( my_ftor ) or std::function< sig >( my_ftor ). This =
normalizes the interface for the purpose of generic functional programming,=
 by hiding the original type, and expresses a necessary design decision abo=
ut how functional manipulations will be accomplished. So, you would have

 std::bind( my_ftor ).template fmap< map_to >() // static dispatch
 std::function< void( map_from ) >( my_ftor ).template fmap< map_to >() // =
dynamic dispatch

instead of

 using std::fmap;
 fmap< map_to >( my_ftor ) // static dispatch?
 fmap< map_to >( std::function< void( map_from ) >(  my_ftor ) ) // dynamic=
 dispatch

I'm not sure how you expect higher-order functions on futures or optionals =
to look, since they're not functors. But, such classes could follow suit.

Maybe I'm not so certain about the superiority of this approach, but if you=
 anticipate requiring using declarations, I don't think the history of std:=
:swap is very encouraging. So, alternatives are at least worth consideratio=
n.

As for the ugly .template notation, I suspect it can be eliminated for such=
 interfaces by a fairly simple extension to Concepts Lite. I should give th=
at idea some more love. (Famous last words.)

--=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/.

--Apple-Mail=_961B0D81-D9F0-4B92-977B-94F0A16A8B3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05&ndash;10, at 4:04 PM, Vicente J. Botet Escriba &lt;<a href=3D"mail=
to:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 10/05/14 06:06, David Krauss a
      =E9crit&nbsp;:<br>
    </div>
    <blockquote cite=3D"mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com"=
 type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3DISO-8859-1">
      <br>
      <div>
        <div>Note that range-based <font face=3D"Courier">for</font>&nbsp;l=
oops
          seldom use free begin and end, not for arrays or classes. The
          only things left with ADL compatibility are enumerations and
          compound types such as pointers. You could also make crippled,
          non-ADL overloads for the likes of <font face=3D"Courier">char*</=
font>,
          at your own risk. Such uses are a bit exotic.</div>
        <div><br>
        </div>
        <div>Overall, unlike <font face=3D"Courier">swap</font>, it&rsquo;s
          probably better to define&nbsp;<font face=3D"Courier">begin</font=
>
          and <font face=3D"Courier">end</font> as members and leave the
          free function interface to the few corner cases where it&rsquo;s
          necessary. The qualified names <font face=3D"Courier">std::begin<=
/font>/<font face=3D"Courier">std::end</font> are then sufficiently
          generic.</div>
      </div>
    </blockquote>
    I agree that defining begin/end members functions would be a better
    choice when possible. However you could have a 3pp or legacy class
    that needs to be adapted. The overloading of the non-member
    begin/end functions solves the issue. </div></blockquote><div><br></div=
><div>No, as I mention above, class non-member begin/end will *<i>not</i>* =
be found by range-based for-loops (and that&rsquo;s the only thing I know t=
hat would go looking). It would be misleading to name a function as such, a=
nd confused users will need to refer to =A76.5.4 [stmt.ranged] to figure ou=
t why the non-member isn&rsquo;t getting called.</div><br><blockquote type=
=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">The problem is when two=
 other
    3pp libraries define these overloads and you application integrates
    the three 3pp libraries. <br></div></blockquote><div><br></div><div>Are=
 you suggesting adding functions to third-party namespaces?</div><br><block=
quote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><blockquote c=
ite=3D"mid:AC4B4918-195B-4A29-8630-82CC3738AA95@gmail.com" type=3D"cite"><d=
iv><div>A proposal should describe a usable interface. Higher-order
          functions that work with raw function pointer types need to be
          either non-members or members of a thin wrapper which
          supersedes the raw function pointer for that interface. I&rsquo;d
          favor a thin wrapper just for uniformity of an object-oriented
          interface.</div>
      </div>
      <br>
    </blockquote>
    Are you suggesting that the user will need to add a
    future_monad&lt;T&gt; class that wraps a future and behaves as a
    monad? And a specific wrapper future_xxx&lt;T&gt; for each concept
    xxx that future could be adapted to conform with?<br></div></blockquote=
><div><br></div><div>Actually we already have a thin non-polymorphic functo=
r wrapper: the result of <font face=3D"Courier">std::bind</font>. So, the s=
uggestion comes down to adding customizable higher-order functions as membe=
rs by adding default implementations as members of bind objects and <font f=
ace=3D"Courier">std::function</font>, and requiring the user to adapt custo=
m functor types by <font face=3D"Courier">std::bind( my_ftor )</font>&nbsp;=
or <font face=3D"Courier">std::function&lt; sig &gt;( my_ftor )</font>. Thi=
s normalizes the interface for the purpose of generic functional programmin=
g, by hiding the original type, and expresses a necessary design decision a=
bout how functional manipulations will be accomplished. So, you would have<=
/div><div><span style=3D"font-family: Courier;"><br></span></div><div><font=
 face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-space: pre;=
"> </span>std::bind( my_ftor ).template fmap&lt; map_to &gt;() // static di=
spatch</font></div><div><div><font face=3D"Courier"><span class=3D"Apple-ta=
b-span" style=3D"white-space: pre;"> </span>std::function&lt; void( map_fro=
m ) &gt;( my_ftor ).template fmap&lt; map_to &gt;() // dynamic dispatch</fo=
nt></div><div><font face=3D"Courier"><br></font></div></div><div>instead of=
</div><div><br></div><div><font face=3D"Courier"><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>using std::fmap;</font></div><div><f=
ont face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>fmap&lt; map_to &gt;( my_ftor ) // static dispatch?</font></div>=
<div><div><font face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"wh=
ite-space: pre;"> </span>fmap&lt; map_to &gt;(&nbsp;</font><span style=3D"f=
ont-family: Courier;">std::function&lt; void( map_from ) &gt;(&nbsp;</span>=
&nbsp;<span style=3D"font-family: Courier;">my_ftor ) ) // dynamic dispatch=
</span></div><div><font face=3D"Courier"><br></font></div></div><div>I&rsqu=
o;m not sure how you expect higher-order functions on futures or optionals =
to look, since they&rsquo;re not functors. But, such classes could follow s=
uit.</div><div><br></div><div>Maybe I&rsquo;m not so certain about the supe=
riority of this approach, but if you anticipate requiring <font face=3D"Cou=
rier">using</font> declarations, I don&rsquo;t think the history of&nbsp;<f=
ont face=3D"Courier">std::swap</font> is very encouraging. So, alternatives=
 are at least worth consideration.</div></div><br><div>As for the ugly <fon=
t face=3D"Courier">.template</font> notation, I suspect it can be eliminate=
d for such interfaces by a fairly simple extension to Concepts Lite. I shou=
ld give that idea some more love. (Famous last words.)</div><div><br></div>=
</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&quot; 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 />

--Apple-Mail=_961B0D81-D9F0-4B92-977B-94F0A16A8B3D--

.