Topic: Proposal for additional generic behaviour
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 24 Nov 2012 06:30:04 -0000
Raw View
--001636d33d2ad9f83004cf37d426
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Nice. So that would also work with the [] operator? [][]. :-)
Sent from my BlackBerry=AE PlayBook=99
www.blackberry.com
------------------------------
*From:* "grigorij1981@gmail.com" <grigorij1981@gmail.com>
*To:* "std-proposals@isocpp.org" <std-proposals@isocpp.org>
*CC:* "grigorij1981@gmail.com" <grigorij1981@gmail.com>
*Sent:* 23 November, 2012 6:43 PM
*Subject:* [std-proposals] Re: Proposal for additional generic behaviour
when dealing with functions
By the way if we allow [] with operators then we would have a really
concise way of passing operators to functions, for example
accumulate(v.begin(), v.end(), []*); // instead of multiply<>
way of capturing an overload set. I haven't seen any further development
of that idea, but it seems like a really nice way to simplify usage of
functions as function parameters without fundamental changes.
>
--=20
--001636d33d2ad9f83004cf37d426
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Nice. =A0So that would also work with the [] opera=
tor? [][]. :-)<div><br><br><div id=3D"1330154144936-sig-id">Sent from my Bl=
ackBerry=AE PlayBook=99<br><a href=3D"http://www.blackberry.com">www.blackb=
erry.com</a></div>
<br><hr><div><strong>From:</strong> "<a href=3D"mailto:grigorij1981@gm=
ail.com">grigorij1981@gmail.com</a>" <<a href=3D"mailto:grigorij198=
1@gmail.com">grigorij1981@gmail.com</a>><br><strong>To:</strong> "<=
a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>&quo=
t; <<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org=
</a>><br>
<strong>CC:</strong> "<a href=3D"mailto:grigorij1981@gmail.com">grigor=
ij1981@gmail.com</a>" <<a href=3D"mailto:grigorij1981@gmail.com">gr=
igorij1981@gmail.com</a>><br><strong>Sent:</strong> 23 November, 2012 6:=
43 PM<br>
<strong>Subject:</strong> [std-proposals] Re: Proposal for additional gener=
ic behaviour when dealing with functions<br></div><br><div>By the way if we=
allow [] with operators then we would have a really concise way of passing=
operators to functions, for example</div>
<div>=A0</div><div><font face=3D"courier new,monospace">accumulate(v.begin(=
), v.end(), []*); // instead of multiply<></font></div><div><br><span=
style=3D"font-family:arial,sans-serif">=A0way of capturing an overload set=
.. I haven't seen any further development of that idea, but it seems lik=
e a really nice way to simplify usage of functions as function parameters w=
ithout fundamental changes.</span></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><pre><font face=3D"Arial"></font></pre></blockquote>
=A0<br>
=A0<br>
=A0<br>
</div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--001636d33d2ad9f83004cf37d426--
.
Author: grigorij1981@gmail.com
Date: Sat, 24 Nov 2012 01:48:41 -0800 (PST)
Raw View
------=_Part_294_9687481.1353750521441
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
While [][] looks funny, I see no ambiguity here. So if we allow []+ and=20
[]*, we should allow [][] as well. There's ambiguity with []() - it looks=
=20
like a beginning of lambda, so that should not be treated like lifted form=
=20
of operator ().
=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UTC+2=
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:
> Nice. So that would also work with the [] operator? [][]. :-)
>
>
> Sent from my BlackBerry(R) PlayBook(tm)
> www.blackberry.com
>
> ------------------------------
> *From:* "grigor...@gmail.com <javascript:>" <grigor...@gmail.com<javascri=
pt:>
> >
> *To:* "std-pr...@isocpp.org <javascript:>" <std-pr...@isocpp.org<javascri=
pt:>
> >
> *CC:* "grigor...@gmail.com <javascript:>" <grigor...@gmail.com<javascript=
:>
> >
> *Sent:* 23 November, 2012 6:43 PM
> *Subject:* [std-proposals] Re: Proposal for additional generic behaviour=
=20
> when dealing with functions
>
> By the way if we allow [] with operators then we would have a really=20
> concise way of passing operators to functions, for example
> =20
> accumulate(v.begin(), v.end(), []*); // instead of multiply<>
>
> way of capturing an overload set. I haven't seen any further development=
=20
> of that idea, but it seems like a really nice way to simplify usage of=20
> functions as function parameters without fundamental changes.
>
>> =20
> =20
> =20
> =20
--=20
------=_Part_294_9687481.1353750521441
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<div>While [][] looks funny, I see no ambiguity here. So if we allow []+ an=
d []*, we should allow [][] as well. There's ambiguity with []() - it looks=
like a beginning of lambda, so that should not be treated like lifted form=
of operator ().</div><div><br>=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=
=C4=C1 2012 =D2. 08:30:09 UTC+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=
=C1=D0=C9=D3=C1=D7:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div>Nice. So t=
hat would also work with the [] operator? [][]. :-)<div><br><br><div>Sent f=
rom my BlackBerry® PlayBook™<br><a href=3D"http://www.blackberry.=
com" target=3D"_blank">www.blackberry.com</a></div>
<br><hr><div><strong>From:</strong> "<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"KK2Ni2wQuBYJ">grigor...@gmail.com</a>" <<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"KK2Ni2wQuBY=
J">grigor...@gmail.com</a>><br><strong>To:</strong> "<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"KK2Ni2wQuBYJ">std-pr...@iso=
cpp.org</a>" <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"KK2Ni2wQuBYJ">std-pr...@isocpp.org</a>><br>
<strong>CC:</strong> "<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"KK2Ni2wQuBYJ">grigor...@gmail.com</a>" <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"KK2Ni2wQuBYJ">grigor...@gm=
ail.com</a>><br><strong>Sent:</strong> 23 November, 2012 6:43 PM<br>
<strong>Subject:</strong> [std-proposals] Re: Proposal for additional gener=
ic behaviour when dealing with functions<br></div><br><div>By the way if we=
allow [] with operators then we would have a really concise way of passing=
operators to functions, for example</div>
<div> </div><div><font face=3D"courier new,monospace">accumulate(v.beg=
in(), v.end(), []*); // instead of multiply<></font></div><div><br><s=
pan style=3D"font-family: arial,sans-serif;"> way of capturing an over=
load set. I haven't seen any further development of that idea, but it seems=
like a really nice way to simplify usage of functions as function paramete=
rs without fundamental changes.</span></div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><pre><font face=3D"Arial"></font></pre></block=
quote>
<br>
<br>
<br>
</div></div>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_294_9687481.1353750521441--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Nov 2012 03:15:22 -0800 (PST)
Raw View
------=_Part_82_25001282.1353755722037
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
On Saturday, November 24, 2012 1:48:41 AM UTC-8, grigor...@gmail.com wrote:
>
> While [][] looks funny, I see no ambiguity here. So if we allow []+ and=
=20
> []*, we should allow [][] as well. There's ambiguity with []() - it looks=
=20
> like a beginning of lambda, so that should not be treated like lifted for=
m=20
> of operator ().
>
Grammatically, it may be unambiguous, but it is inconsistent with the rest=
=20
of C++.
The syntax should be `[]<function name>`. The name of the + operator=20
function is `operator +`. Therefore, it should be `[]operator +`. Plus, it=
=20
allows you to do proper scoping where appropriate, such as=20
`[]some_namespace::operator +`, which is already standard C++ grammar for=
=20
the name of the + operator function in `some_namespace`.
> =F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UTC=
+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:
>
>> Nice. So that would also work with the [] operator? [][]. :-)
>>
>>
>> Sent from my BlackBerry(R) PlayBook(tm)
>> www.blackberry.com
>>
>> ------------------------------
>> *From:* "grigor...@gmail.com" <grigor...@gmail.com>
>> *To:* "std-pr...@isocpp.org" <std-pr...@isocpp.org>
>> *CC:* "grigor...@gmail.com" <grigor...@gmail.com>
>> *Sent:* 23 November, 2012 6:43 PM
>> *Subject:* [std-proposals] Re: Proposal for additional generic behaviour=
=20
>> when dealing with functions
>>
>> By the way if we allow [] with operators then we would have a really=20
>> concise way of passing operators to functions, for example
>> =20
>> accumulate(v.begin(), v.end(), []*); // instead of multiply<>
>>
>> way of capturing an overload set. I haven't seen any further developmen=
t=20
>> of that idea, but it seems like a really nice way to simplify usage of=
=20
>> functions as function parameters without fundamental changes.
>>
>>> =20
>> =20
>> =20
>> =20
>
--=20
------=_Part_82_25001282.1353755722037
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
On Saturday, November 24, 2012 1:48:41 AM UTC-8, grigor...@gmail.com wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div>While [][] looks funny, I=
see no ambiguity here. So if we allow []+ and []*, we should allow [][] as=
well. There's ambiguity with []() - it looks like a beginning of lambda, s=
o that should not be treated like lifted form of operator ().</div></blockq=
uote><div><br>Grammatically, it may be unambiguous, but it is inconsistent =
with the rest of C++.<br><br>The syntax should be `[]<function name>`=
.. The name of the + operator function is `operator +`. Therefore, it should=
be `[]operator +`. Plus, it allows you to do proper scoping where appropri=
ate, such as `[]some_namespace::operator +`, which is already standard C++ =
grammar for the name of the + operator function in `some_namespace`.<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><br>=F3=D5=C2=CF=
=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UTC+2 =CB=CF=D2=
=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
><div>Nice. So that would also work with the [] operator? [][]. :-)<d=
iv><br><br><div>Sent from my BlackBerry® PlayBook™<br><a href=3D"=
http://www.blackberry.com" target=3D"_blank">www.blackberry.com</a></div>
<br><hr><div><b>From:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gma=
il.com</a>><br><b>To:</b> "<a>std-pr...@isocpp.org</a>" <<a>std-pr...=
@isocpp.org</a>><br>
<b>CC:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gmail.com</a>><=
br><b>Sent:</b> 23 November, 2012 6:43 PM<br>
<b>Subject:</b> [std-proposals] Re: Proposal for additional generic behavio=
ur when dealing with functions<br></div><br><div>By the way if we allow [] =
with operators then we would have a really concise way of passing operators=
to functions, for example</div>
<div> </div><div><font face=3D"courier new,monospace">accumulate(v.beg=
in(), v.end(), []*); // instead of multiply<></font></div><div><br><s=
pan style=3D"font-family:arial,sans-serif"> way of capturing an overlo=
ad set. I haven't seen any further development of that idea, but it seems l=
ike a really nice way to simplify usage of functions as function parameters=
without fundamental changes.</span></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><pre><font face=3D"Arial"></font></pre></blockquote>
<br>
<br>
<br>
</div></div>
</blockquote></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_82_25001282.1353755722037--
.
Author: grigorij1981@gmail.com
Date: Sat, 24 Nov 2012 04:44:11 -0800 (PST)
Raw View
------=_Part_67_32677650.1353761051477
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 13:15:22 UTC+2=
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Nicol Bolas =CE=C1=D0=C9=D3=C1=D7:
>
> On Saturday, November 24, 2012 1:48:41 AM UTC-8, grigor...@gmail.comwrote=
:
>>
>> While [][] looks funny, I see no ambiguity here. So if we allow []+ and=
=20
>> []*, we should allow [][] as well. There's ambiguity with []() - it look=
s=20
>> like a beginning of lambda, so that should not be treated like lifted fo=
rm=20
>> of operator ().
>>
>
> Grammatically, it may be unambiguous, but it is inconsistent with the res=
t=20
> of C++.
>
> The syntax should be `[]<function name>`. The name of the + operator=20
> function is `operator +`. Therefore, it should be `[]operator +`. Plus, i=
t=20
> allows you to do proper scoping where appropriate, such as=20
> `[]some_namespace::operator +`, which is already standard C++ grammar for=
=20
> the name of the + operator function in `some_namespace`.
>
=20
Strictly speaking even []operator+ should not work for built-in operator +,=
=20
as it is not a function. If we aim for consistency then if operator + (1,2)=
is=20
not a valid expression then ([]operator+)(1,2) should not be one.
And I'm not proposing that []operator + should be disallowed. I'm saying=20
that if we have shorthand syntax for calling a user-declared operator, then=
=20
it would be logical to have shorthand syntax for passing operator to other=
=20
functions.
=20
--=20
------=_Part_67_32677650.1353761051477
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<div>=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 13:15:22 =
UTC+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Nicol Bolas =CE=C1=D0=C9=D3=C1=D7:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;">On Saturday, November 24, 2012 1:48:41 AM UTC-8, <=
a>grigor...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div>While [][=
] looks funny, I see no ambiguity here. So if we allow []+ and []*, we shou=
ld allow [][] as well. There's ambiguity with []() - it looks like a beginn=
ing of lambda, so that should not be treated like lifted form of operator (=
).</div></blockquote><div><br>Grammatically, it may be unambiguous, but it =
is inconsistent with the rest of C++.<br><br>The syntax should be `[]<fu=
nction name>`. The name of the + operator function is `operator +`. Ther=
efore, it should be `[]operator +`. Plus, it allows you to do proper scopin=
g where appropriate, such as `[]some_namespace::operator +`, which is alrea=
dy standard C++ grammar for the name of the + operator function in `some_na=
mespace`.<br></div></blockquote></div><div> </div><div>Strictly speaki=
ng even <font face=3D"courier new,monospace">[]operator+ </font><=
font face=3D"arial,sans-serif">should not work for built-in operator +, as =
it is not a function. If we aim for consistency then if </font><font f=
ace=3D"courier new,monospace">operator + (1,2) </font><font face=3D"arial,s=
ans-serif">is not a valid expression then</font><font face=3D"cou=
rier new,monospace"> ([]operator+)(1,2) </font><font face=3D"arial,san=
s-serif">should not be one.</font></div><div>And I'm not proposing tha=
t []operator + should be disallowed. I'm saying that if we have shorthand s=
yntax for calling a user-declared operator, then it would be logi=
cal to have shorthand syntax for passing operator to other functions.</div>=
<div><br> </div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_67_32677650.1353761051477--
.
Author: Scott Prager <splinterofchaos@gmail.com>
Date: Sun, 25 Nov 2012 05:07:08 -0800 (PST)
Raw View
------=_Part_5_24837635.1353848828748
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
On Saturday, November 24, 2012 4:48:41 AM UTC-5, grigor...@gmail.com wrote:
>
> While [][] looks funny, I see no ambiguity here. So if we allow []+ and=
=20
> []*, we should allow [][] as well....
>
How would one differentiate between multiplication and dereferencing? Or=20
unary plus and minus with the binary?
=20
>
> =F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UTC=
+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:
>
>> Nice. So that would also work with the [] operator? [][]. :-)
>>
>>
>> Sent from my BlackBerry(R) PlayBook(tm)
>> www.blackberry.com
>>
>> ------------------------------
>> *From:* "grigor...@gmail.com" <grigor...@gmail.com>
>> *To:* "std-pr...@isocpp.org" <std-pr...@isocpp.org>
>> *CC:* "grigor...@gmail.com" <grigor...@gmail.com>
>> *Sent:* 23 November, 2012 6:43 PM
>> *Subject:* [std-proposals] Re: Proposal for additional generic behaviour=
=20
>> when dealing with functions
>>
>> By the way if we allow [] with operators then we would have a really=20
>> concise way of passing operators to functions, for example
>> =20
>> accumulate(v.begin(), v.end(), []*); // instead of multiply<>
>>
>> way of capturing an overload set. I haven't seen any further developmen=
t=20
>> of that idea, but it seems like a really nice way to simplify usage of=
=20
>> functions as function parameters without fundamental changes.
>>
>>> =20
>> =20
>> =20
>> =20
>
--=20
------=_Part_5_24837635.1353848828748
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, November 24, 2012 4:48:41 AM UTC-5, grigor...@gmail.co=
m wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>While [][] looks =
funny, I see no ambiguity here. So if we allow []+ and []*, we should allow=
[][] as well....</div></blockquote><div><br>How would one differentiate be=
tween multiplication and dereferencing? Or unary plus and minus with the bi=
nary?<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>=
=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UTC+2=
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:=
1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-st=
yle:solid"><div>Nice. So that would also work with the [] operator? [=
][]. :-)<div><br><br><div>Sent from my BlackBerry® PlayBook™<br><=
a href=3D"http://www.blackberry.com" target=3D"_blank">www.blackberry.com</=
a></div>
<br><hr><div><b>From:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gma=
il.com</a>><br><b>To:</b> "<a>std-pr...@isocpp.org</a>" <<a>std-pr...=
@isocpp.org</a>><br>
<b>CC:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gmail.com</a>><=
br><b>Sent:</b> 23 November, 2012 6:43 PM<br>
<b>Subject:</b> [std-proposals] Re: Proposal for additional generic behavio=
ur when dealing with functions<br></div><br><div>By the way if we allow [] =
with operators then we would have a really concise way of passing operators=
to functions, for example</div>
<div> </div><div><font face=3D"courier new,monospace">accumulate(v.beg=
in(), v.end(), []*); // instead of multiply<></font></div><div><br><s=
pan style=3D"font-family:arial,sans-serif"> way of capturing an overlo=
ad set. I haven't seen any further development of that idea, but it seems l=
ike a really nice way to simplify usage of functions as function parameters=
without fundamental changes.</span></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><pre><font face=3D"Arial"></font></pre></blockquote>
<br>
<br>
<br>
</div></div>
</blockquote></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_5_24837635.1353848828748--
.
Author: grigorij1981@gmail.com
Date: Sun, 25 Nov 2012 06:18:24 -0800 (PST)
Raw View
------=_Part_47_9718227.1353853104545
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
In the context where unary function object is expected []* would act as=20
dereference operation and in the context where binary function object is=20
expected as []* would act as multiplication.
This is natural as []*function *essentially captures an overload set of=20
function.
=EE=C5=C4=A6=CC=D1, 25 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 15:07:08 UTC+2=
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Scott Prager =CE=C1=D0=C9=D3=C1=D7:
>
>
> On Saturday, November 24, 2012 4:48:41 AM UTC-5, grigor...@gmail.comwrote=
:
>>
>> While [][] looks funny, I see no ambiguity here. So if we allow []+ and=
=20
>> []*, we should allow [][] as well....
>>
>
> How would one differentiate between multiplication and dereferencing? Or=
=20
> unary plus and minus with the binary?
> =20
>
>>
>> =F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:30:09 UT=
C+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:
>>
>>> Nice. So that would also work with the [] operator? [][]. :-)
>>>
>>>
>>> Sent from my BlackBerry(R) PlayBook(tm)
>>> www.blackberry.com
>>>
>>> ------------------------------
>>> *From:* "grigor...@gmail.com" <grigor...@gmail.com>
>>> *To:* "std-pr...@isocpp.org" <std-pr...@isocpp.org>
>>> *CC:* "grigor...@gmail.com" <grigor...@gmail.com>
>>> *Sent:* 23 November, 2012 6:43 PM
>>> *Subject:* [std-proposals] Re: Proposal for additional generic=20
>>> behaviour when dealing with functions
>>>
>>> By the way if we allow [] with operators then we would have a really=20
>>> concise way of passing operators to functions, for example
>>> =20
>>> accumulate(v.begin(), v.end(), []*); // instead of multiply<>
>>>
>>> way of capturing an overload set. I haven't seen any further=20
>>> development of that idea, but it seems like a really nice way to simpli=
fy=20
>>> usage of functions as function parameters without fundamental changes.
>>>
>>>> =20
>>> =20
>>> =20
>>> =20
>>
--=20
------=_Part_47_9718227.1353853104545
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<div>In the context where unary function object is expected []* would act a=
s dereference operation and in the context where binary function object is =
expected as []* would act as multiplication.</div><div>This is natural as [=
]<em>function </em>essentially captures an overload set of function.</div><=
div><br>=EE=C5=C4=A6=CC=D1, 25 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 15:07:=
08 UTC+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Scott Prager =CE=C1=D0=C9=D3=C1=D7:=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><br><br>On Saturday, November 24, 2012 4=
:48:41 AM UTC-5, <a>grigor...@gmail.com</a> wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div>While [][] looks funny, I see no ambiguity here. So if we allow []=
+ and []*, we should allow [][] as well....</div></blockquote><div><br>How =
would one differentiate between multiplication and dereferencing? Or unary =
plus and minus with the binary?<br> </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
><div><br>=F3=D5=C2=CF=D4=C1, 24 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 08:3=
0:09 UTC+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE Tony V E =CE=C1=D0=C9=D3=C1=D7:</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;"><div>Nice. So that would also work w=
ith the [] operator? [][]. :-)<div><br><br><div>Sent from my BlackBerry®=
; PlayBook™<br><a href=3D"http://www.blackberry.com" target=3D"_blank=
">www.blackberry.com</a></div>
<br><hr><div><b>From:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gma=
il.com</a>><br><b>To:</b> "<a>std-pr...@isocpp.org</a>" <<a>std-pr...=
@isocpp.org</a>><br>
<b>CC:</b> "<a>grigor...@gmail.com</a>" <<a>grigor...@gmail.com</a>><=
br><b>Sent:</b> 23 November, 2012 6:43 PM<br>
<b>Subject:</b> [std-proposals] Re: Proposal for additional generic behavio=
ur when dealing with functions<br></div><br><div>By the way if we allow [] =
with operators then we would have a really concise way of passing operators=
to functions, for example</div>
<div> </div><div><font face=3D"courier new,monospace">accumulate(v.beg=
in(), v.end(), []*); // instead of multiply<></font></div><div><br><s=
pan style=3D"font-family: arial,sans-serif;"> way of capturing an over=
load set. I haven't seen any further development of that idea, but it seems=
like a really nice way to simplify usage of functions as function paramete=
rs without fundamental changes.</span></div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><pre><font face=3D"Arial"></font></pre></block=
quote>
<br>
<br>
<br>
</div></div>
</blockquote></blockquote></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_47_9718227.1353853104545--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Sun, 25 Nov 2012 07:10:29 -0800 (PST)
Raw View
------=_Part_197_31143428.1353856229484
Content-Type: text/plain; charset=ISO-8859-1
It really should be []operator+, not []+. Secondly, this is really getting
away from the original proposal that I've written, which is for just names.
--
------=_Part_197_31143428.1353856229484
Content-Type: text/html; charset=ISO-8859-1
It really should be []operator+, not []+. Secondly, this is really getting away from the original proposal that I've written, which is for just names.
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_197_31143428.1353856229484--
.
Author: grigorij1981@gmail.com
Date: Sun, 25 Nov 2012 07:17:58 -0800 (PST)
Raw View
------=_Part_28_8268256.1353856678220
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
I disagree with the first remark, but I agree that this is somewhat=20
off-topic.=20
=EE=C5=C4=A6=CC=D1, 25 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2012 =D2. 17:10:29 UTC+2=
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE DeadMG =CE=C1=D0=C9=D3=C1=D7:
> It really should be []operator+, not []+. Secondly, this is really gettin=
g=20
> away from the original proposal that I've written, which is for just name=
s.
--=20
------=_Part_28_8268256.1353856678220
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<div>I disagree with the first remark, but I agree that this is s=
omewhat off-topic. </div><div><br>=EE=C5=C4=A6=CC=D1, 25 =CC=C9=D3=D4=CF=D0=
=C1=C4=C1 2012 =D2. 17:10:29 UTC+2 =CB=CF=D2=C9=D3=D4=D5=D7=C1=DE DeadMG =
=CE=C1=D0=C9=D3=C1=D7:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">It really should b=
e []operator+, not []+. Secondly, this is really getting away from the orig=
inal proposal that I've written, which is for just names.</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_28_8268256.1353856678220--
.