------=_Part_612_5090159.1353962394775
Content-Type: text/plain; charset=ISO-8859-1

Richard, are you still willing to write the proporsal about providing
operator... for user definied types? I will surely need some help with
wording of the proporsal and also I think it is inaproperiate to use your
ideas without your approval.

Firstly, I think the the template function/method approach has one major
adavantage: it is not introducing any new language features expect the
operator..., while the initial approach required addition of ...N for
providing "1,2,...,N-1,N" pacsk expression and special pack-method syntax
for declaring the operator itself. I think this may greatly improve chances
of adopoting the proporsal into standard.

Secondly, it is cleary suggest that the each member of pack expression is
threated as separated function, so if the invocation of operator...$N has
side effect, then it will be invoced twice. This is not big advantage,
beacause the same result may be achived via allowing only return-only
functions.

Of course it has it own flaws. The major problem is the size of generated
pack expression. The operator... template should not be instiatiated with
paramter argument greater than size of pack expression. This may be avoided
via using enable_if hackery. This leads us to the second problem - the
initial approach has much more preatier and intuitive syntax than the
template approach.

--




------=_Part_612_5090159.1353962394775
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Richard, are you still willing to write the proporsal about providing opera=
tor... for user definied types? I will surely need some help with wording o=
f the proporsal and also I think it is inaproperiate to use your ideas with=
out your approval.<br><br>Firstly, I think the the template function/method=
 approach has one major adavantage: it is not introducing any new language =
features expect the operator..., while the initial approach required additi=
on of ...N for providing "1,2,...,N-1,N" pacsk expression and special pack-=
method syntax for declaring the operator itself. I think this may greatly i=
mprove chances of adopoting the proporsal into standard.<br><br>Secondly, i=
t is cleary suggest that the each member of pack expression is threated as =
separated function, so if the invocation of operator...$N has side effect, =
then it will be invoced twice. This is not big advantage, beacause the same=
 result may be achived via allowing only return-only functions.<br><br><div=
 style=3D"text-align: left;">Of course it has it own flaws. The major probl=
em is the size of generated pack expression. The operator... template shoul=
d not be instiatiated with paramter argument greater than size of pack expr=
ession. This may be avoided via using enable_if hackery. This leads us to t=
he second problem - the initial approach has much more preatier and intuiti=
ve syntax than the template approach.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_612_5090159.1353962394775--

.

--047d7b343e36718b3704cf6d4605
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 26, 2012 at 12:39 PM, <tomaszkam@gmail.com> wrote:

> Richard, are you still willing to write the proporsal about providing
> operator... for user definied types? I will surely need some help with
> wording of the proporsal and also I think it is inaproperiate to use your
> ideas without your approval.
>

Yes, I am, and I'm also happy to collaborate with you on such a proposal.
I'll contact you off-list and we can discuss authoring the paper...


> Firstly, I think the the template function/method approach has one major
> adavantage: it is not introducing any new language features expect the
> operator..., while the initial approach required addition of ...N for
> providing "1,2,...,N-1,N" pacsk expression and special pack-method syntax
> for declaring the operator itself. I think this may greatly improve chances
> of adopoting the proporsal into standard.
>
> Secondly, it is cleary suggest that the each member of pack expression is
> threated as separated function, so if the invocation of operator...$N has
> side effect, then it will be invoced twice. This is not big advantage,
> beacause the same result may be achived via allowing only return-only
> functions.
>
> Of course it has it own flaws. The major problem is the size of generated
> pack expression. The operator... template should not be instiatiated with
> paramter argument greater than size of pack expression. This may be avoided
> via using enable_if hackery. This leads us to the second problem - the
> initial approach has much more preatier and intuitive syntax than the
> template approach.
>
> --
>
>
>
>

--




--047d7b343e36718b3704cf6d4605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 26, 2012 at 12:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmail.com</a>&gt;</span> w=
rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Richard, are you still willing to write the proporsal about providing opera=
tor... for user definied types? I will surely need some help with wording o=
f the proporsal and also I think it is inaproperiate to use your ideas with=
out your approval.<br>
</blockquote><div><br></div><div>Yes, I am, and I&#39;m also happy to colla=
borate with you on such a proposal. I&#39;ll contact you off-list and we ca=
n discuss authoring the paper...</div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Firstly, I think the the template function/method approach has one major ad=
avantage: it is not introducing any new language features expect the operat=
or..., while the initial approach required addition of ...N for providing &=
quot;1,2,...,N-1,N&quot; pacsk expression and special pack-method syntax fo=
r declaring the operator itself. I think this may greatly improve chances o=
f adopoting the proporsal into standard.<br>
<br>Secondly, it is cleary suggest that the each member of pack expression =
is threated as separated function, so if the invocation of operator...$N ha=
s side effect, then it will be invoced twice. This is not big advantage, be=
acause the same result may be achived via allowing only return-only functio=
ns.<br>
<br><div style=3D"text-align:left">Of course it has it own flaws. The major=
 problem is the size of generated pack expression. The operator... template=
 should not be instiatiated with paramter argument greater than size of pac=
k expression. This may be avoided via using enable_if hackery. This leads u=
s to the second problem - the initial approach has much more preatier and i=
ntuitive syntax than the template approach.<span class=3D"HOEnZb"><font col=
or=3D"#888888"><br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b343e36718b3704cf6d4605--

.

I apologize for not providing any input earlier on this thread (been
working on a generic lambda implementation using clang in the little
spare time (https://github.com/faisalv/clang-glambda) that I have had)
- but I am certainly interested in this feature (although I need to
seriously sit down and take a closer look at it before I can provide
useful feedback) - so if there is anything I can do to help - please
let me know - and I'll do my best.

thanks for taking this forward!

Faisal Vali



On Mon, Nov 26, 2012 at 4:15 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> On Mon, Nov 26, 2012 at 12:39 PM, <tomaszkam@gmail.com> wrote:
>>
>> Richard, are you still willing to write the proporsal about providing
>> operator... for user definied types? I will surely need some help with
>> wording of the proporsal and also I think it is inaproperiate to use your
>> ideas without your approval.
>
>
> Yes, I am, and I'm also happy to collaborate with you on such a proposal.
> I'll contact you off-list and we can discuss authoring the paper...
>
>>
>> Firstly, I think the the template function/method approach has one major
>> adavantage: it is not introducing any new language features expect the
>> operator..., while the initial approach required addition of ...N for
>> providing "1,2,...,N-1,N" pacsk expression and special pack-method syntax
>> for declaring the operator itself. I think this may greatly improve chances
>> of adopoting the proporsal into standard.
>>
>> Secondly, it is cleary suggest that the each member of pack expression is
>> threated as separated function, so if the invocation of operator...$N has
>> side effect, then it will be invoced twice. This is not big advantage,
>> beacause the same result may be achived via allowing only return-only
>> functions.
>>
>> Of course it has it own flaws. The major problem is the size of generated
>> pack expression. The operator... template should not be instiatiated with
>> paramter argument greater than size of pack expression. This may be avoided
>> via using enable_if hackery. This leads us to the second problem - the
>> initial approach has much more preatier and intuitive syntax than the
>> template approach.
>>
>> --
>>
>>
>>
>
>
> --
>
>
>

--




.