--001a1141e5b0c4ec0c05339754a3
Content-Type: text/plain; charset=UTF-8

I am looking for the reason why lambda expressions are explicitly
not defining a default constructor (at least depending on the arguments
constructors).

I cannot find a specific reason for that so far.
Does anyone here have a source about this point?


Otherwise I would like to propose to add

    ClosureType() = default;

to the definition of the closure generated by a lambda, if it's not already
proposed somewhere.

This would help working with closures in generic context where we assume
that the callable type is regular (it's not enough but it helps);

For example with this kind of code:


template< class T, class Callable >
struct FatForwardIterator
{
  T value;
  Callable incr; // deactivate the default constructor if it's a closure
  //... etc

  FatForwardIterator& operator++()
  {
    // ...
    value = incr(value);
    return *this;
  }
};
// let's assume that the proposal to generate default comparisons is on...


template< class T, class Callable >
auto make_fat_iterator( T initial_value, Callable incr )
{
  return FatForwardIterator<T, Callable>{ initial_value, incr };
}

template< class IteratorType>
void some_algorithm( IteratorType begin, IteratorType end )
{
  IteratorType previous; // error: IteratorType do not have a default
constructor.
  do
  {
    previous = begin;
    ++begin;
    // ... use previous
  }
  while( begin != end );
}


void foo()
{
  auto times2 = [](auto value){  return value * 2; };
  auto begin = make_fat_iterator( 1, times2 );
  auto end = make_fat_iterator( 8, times2 );

  // ...
  some_algorithm( begin, end ); // fails to compile
}

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2BsXVdUUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com.

--001a1141e5b0c4ec0c05339754a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am looking for the reason why lambda expressions are exp=
licitly<div>not defining a default constructor (at least depending on the a=
rguments constructors).</div><div><br></div><div>I cannot find a specific r=
eason for that so far.</div><div>Does anyone here have a source about this =
point?</div><div><br></div><div><br></div><div>Otherwise I would like to pr=
opose to add=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0 ClosureType() =3D=
 default;=C2=A0</div><div><br></div><div>to the definition of the closure g=
enerated by a lambda, if it&#39;s not already proposed somewhere.</div><div=
><br></div><div>This would help working with closures in generic context wh=
ere we assume</div><div>that the callable type is regular (it&#39;s not eno=
ugh but it helps);</div><div><br></div><div>For example with this kind of c=
ode:</div><div><br></div><div><div><br></div><div>template&lt; class T, cla=
ss Callable &gt;</div><div>struct FatForwardIterator</div><div>{</div><div>=
=C2=A0 T value;</div><div>=C2=A0 Callable incr; // deactivate the default c=
onstructor if it&#39;s a closure</div><div>=C2=A0 //... etc</div><div><br><=
/div><div>=C2=A0 FatForwardIterator&amp; operator++()</div><div>=C2=A0 {</d=
iv><div>=C2=A0 =C2=A0 // ...</div><div>=C2=A0 =C2=A0 value =3D incr(value);=
</div><div>=C2=A0 =C2=A0 return *this;</div><div>=C2=A0 }</div><div>};</div=
><div>// let&#39;s assume that the proposal to generate default comparisons=
 is on...</div><div><br></div><div><br></div><div><div>template&lt; class T=
, class Callable &gt;</div><div>auto make_fat_iterator( T initial_value, Ca=
llable incr )</div><div>{</div><div>=C2=A0 return FatForwardIterator&lt;T, =
Callable&gt;{ initial_value, incr };</div><div>}</div></div><div><br></div>=
<div>template&lt; class IteratorType&gt;</div><div>void some_algorithm( Ite=
ratorType begin, IteratorType end )</div><div>{</div><div>=C2=A0 IteratorTy=
pe previous; // error: IteratorType do not have a default constructor.</div=
><div>=C2=A0 do</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 previous =3D beg=
in;</div><div>=C2=A0 =C2=A0 ++begin;</div><div>=C2=A0 =C2=A0 // ... use pre=
vious</div><div>=C2=A0 }</div><div>=C2=A0 while( begin !=3D end );</div><di=
v>}</div><div><br></div><div><br></div><div>void foo()</div><div>{</div><di=
v>=C2=A0 auto times2 =3D [](auto value){ =C2=A0return value * 2; };</div><d=
iv>=C2=A0 auto begin =3D make_fat_iterator( 1, times2 );</div><div>=C2=A0 a=
uto end =3D make_fat_iterator( 8, times2 );</div><div><br></div><div>=C2=A0=
 // ...=C2=A0</div><div>=C2=A0 some_algorithm( begin, end ); // fails to co=
mpile</div><div>}</div></div><div><br></div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2BsXVdUUcSn=
mgrzr4u6viuVk5WQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZ=
Q_JpyVwcV0%2BsXVdUUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com</a>.<br />

--001a1141e5b0c4ec0c05339754a3--

.

On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:
> I am looking for the reason why lambda expressions are explicitly
> not defining a default constructor (at least depending on the arguments
> constructors).
>
> I cannot find a specific reason for that so far.
> Does anyone here have a source about this point?

If the lambda has captures, it's either insane or impossible to
default-construct it.
Treating non-capturing lambdas differently would require motivation that ha=
sn't
appeared thus far, at least not in proposal form.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYnh2_0dePfnbU%2Bk%3D3%2Bew1yid2t0%3Dv_Yb9=
VCjjhCUVzCQ%40mail.gmail.com.

.

--001a114b416c8c557d053397aa1a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 16:29, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:

> On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wr=
ote:
> > I am looking for the reason why lambda expressions are explicitly
> > not defining a default constructor (at least depending on the arguments
> > constructors).
> >
> > I cannot find a specific reason for that so far.
> > Does anyone here have a source about this point?
>
> If the lambda has captures, it's either insane or impossible to
> default-construct it.


Why? I do not see any justification or explanation of what is "insane" so
far.
I do not see why a =3Ddefault; could not be used
to rely on capture's type default constructors, deleting the default
constructor if it would not be possible for a normal type either.

If we had used a user-defined callable type instead of a lambda in the
example I gave, it would have worked as expected.
Is there a reason for this lack of homogeneity?


>

Treating non-capturing lambdas differently would require motivation that
> hasn't
> appeared thus far, at least not in proposal form.
>

I agree that both cases should have the exact same behaviour, but this is
not really my point.


>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYnh2_=
0dePfnbU%2Bk%3D3%2Bew1yid2t0%3Dv_Yb9VCjjhCUVzCQ%40mail.gmail.com
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91ONDgJNp5pc1513%3Ddk-infkAMqbQFbqXoT%2BNFtB=
Qe6M2RA%40mail.gmail.com.

--001a114b416c8c557d053397aa1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 16:29, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte &lt;<a href=3D=
"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt; wrote:<br>
&gt; I am looking for the reason why lambda expressions are explicitly<br>
&gt; not defining a default constructor (at least depending on the argument=
s<br>
&gt; constructors).<br>
&gt;<br>
&gt; I cannot find a specific reason for that so far.<br>
&gt; Does anyone here have a source about this point?<br>
<br>
</span>If the lambda has captures, it&#39;s either insane or impossible to<=
br>
default-construct it.</blockquote><div><br></div><div>Why? I do not see any=
 justification or explanation of what is &quot;insane&quot; so far.</div><d=
iv>I do not see why a =3Ddefault; could not be used=C2=A0</div><div>to rely=
 on capture&#39;s type default constructors, deleting the default construct=
or if it would not be possible for a normal type either.</div><div><br></di=
v><div>If we had used a user-defined callable type instead of a lambda in t=
he example I gave, it would have worked as expected.</div><div>Is there a r=
eason for this lack of homogeneity?</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Treating non-capturing lambdas differently would require motivation that ha=
sn&#39;t<br>
appeared thus far, at least not in proposal form.<br></blockquote><div><br>=
</div><div>I agree that both cases should have the exact same behaviour, bu=
t this is not really my point.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYnh2_0dePfnbU%2Bk%3D3%2Bew1yid=
2t0%3Dv_Yb9VCjjhCUVzCQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYnh2=
_0dePfnbU%2Bk%3D3%2Bew1yid2t0%3Dv_Yb9VCjjhCUVzCQ%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONDgJNp5pc1513%3Ddk-infkAMqbQFb=
qXoT%2BNFtBQe6M2RA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONDgJNp=
5pc1513%3Ddk-infkAMqbQFbqXoT%2BNFtBQe6M2RA%40mail.gmail.com</a>.<br />

--001a114b416c8c557d053397aa1a--

.

--001a1136c1e0963b55053397c1a8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 4:49 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:

> Why? I do not see any justification or explanation of what is "insane" so
far.

> I do not see why a =3Ddefault; could not be used

Do I understand correctly that you would expect that to fail when captures
were not default-constructible?

And what about captures by references? *What *would they be initialized
with?

Cheers,
V.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg0qVNfpi12bi_xKBw64q96xOoGw%3DR-SaiOKp8VT9=
ewFbQ%40mail.gmail.com.

--001a1136c1e0963b55053397c1a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 4:49 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br><div><br></div><div>&gt; Why? I do not see any jus=
tification or explanation of what is &quot;insane&quot; so far.</div><div><=
br></div><div>&gt; I do not see why a =3Ddefault; could not be used=C2=A0</=
div><div><br></div><div>Do I understand correctly that you would expect tha=
t to fail when captures were not default-constructible?</div><div><br></div=
><div>And what about captures by references? <i>What </i>would they be init=
ialized with?</div><div><br></div><div>Cheers,</div><div>V.</div></div></di=
v></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0qVNfpi12bi_xKBw64q96xOoGw%3DR=
-SaiOKp8VT9ewFbQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0qVNfpi1=
2bi_xKBw64q96xOoGw%3DR-SaiOKp8VT9ewFbQ%40mail.gmail.com</a>.<br />

--001a1136c1e0963b55053397c1a8--

.

On 24 May 2016 at 17:49, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:
>
>
> On 24 May 2016 at 16:29, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>>
>> On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> w=
rote:
>> > I am looking for the reason why lambda expressions are explicitly
>> > not defining a default constructor (at least depending on the argument=
s
>> > constructors).
>> >
>> > I cannot find a specific reason for that so far.
>> > Does anyone here have a source about this point?
>>
>> If the lambda has captures, it's either insane or impossible to
>> default-construct it.
>
>
> Why? I do not see any justification or explanation of what is "insane" so
> far.

If the lambda has captures, those captures have values. A default
constructed lambda
will not have those same values. It's questionable whether it is of
the same type, and my
answer to that question is no.

> I do not see why a =3Ddefault; could not be used
> to rely on capture's type default constructors, deleting the default
> constructor if it would not be possible for a normal type either.

Sure it could, but the problem isn't as much of whether the captures
are default-constructible,
but of what values they should have.

>> Treating non-capturing lambdas differently would require motivation that
>> hasn't
>> appeared thus far, at least not in proposal form.
> I agree that both cases should have the exact same behaviour, but this is
> not really my point.

That "agreement" is not quite right, because I'm not suggesting that
those cases should have
the exact same behavior.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUb1Yg18WXqbEW%2BoFmvK7hqNvfW8VmwjH_Ebunkba=
Tpg%3DA%40mail.gmail.com.

.

--001a114b416c71b44d053397de42
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 16:56, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Tue, May 24, 2016 at 4:49 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail=
..com>
> wrote:
>
> > Why? I do not see any justification or explanation of what is "insane"
> so far.
>
> > I do not see why a =3Ddefault; could not be used
>
> Do I understand correctly that you would expect that to fail when capture=
s
> were not default-constructible?
>
>
Yes.


> And what about captures by references? *What *would they be initialized
> with?
>
>
The current behaviour (though I didn't check the exact wording) makes the
closure copyable even when capturing
by reference.
It is unspecified (if my memory is correct) if data have to be stored when
capturing by reference,
but when an implementation needs to store the implementation of the
reference capture,
it imply the the actual stored data behave like (or is actually) a pointer.
Pointers can be default constructed.


Cheers,
> V.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0qVNf=
pi12bi_xKBw64q96xOoGw%3DR-SaiOKp8VT9ewFbQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0qVN=
fpi12bi_xKBw64q96xOoGw%3DR-SaiOKp8VT9ewFbQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OMS-3RYKJ30jWUBAxXxsjqTBcrtL1FAO-humbxPrTa=
09Q%40mail.gmail.com.

--001a114b416c71b44d053397de42
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 16:56, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, May 2=
4, 2016 at 4:49 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</=
span> wrote:<br><div><br></div><div>&gt; Why? I do not see any justificatio=
n or explanation of what is &quot;insane&quot; so far.</div><div><br></div>=
<div>&gt; I do not see why a =3Ddefault; could not be used=C2=A0</div><div>=
<br></div></span><div>Do I understand correctly that you would expect that =
to fail when captures were not default-constructible?</div><div><br></div><=
/div></div></div></blockquote><div><br></div><div>Yes.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div></div><div>And what about captures by ref=
erences? <i>What </i>would they be initialized with?</div><div><br></div></=
div></div></div></blockquote><div><br></div><div>The current behaviour (tho=
ugh I didn&#39;t check the exact wording) makes the closure copyable even w=
hen capturing</div><div>by reference.</div><div>It is unspecified (if my me=
mory is correct) if data have to be stored when capturing by reference,</di=
v><div>but when an implementation needs to store the implementation of the =
reference capture,</div><div>it imply the the actual stored data behave lik=
e (or is actually) a pointer.</div><div>Pointers can be default constructed=
..</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div>=
<div>Cheers,</div><div>V.</div></div></div></div><span class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0qVNfpi12bi_xKBw64q96xOoGw%3DR=
-SaiOKp8VT9ewFbQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAA7YVg0qVNfpi12bi_xKBw64q96xOoGw%3DR-SaiOKp8VT9ewFbQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OMS-3RYKJ30jWUBAxXxsjqTBcrtL1FA=
O-humbxPrTa09Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OMS-3RYKJ30=
jWUBAxXxsjqTBcrtL1FAO-humbxPrTa09Q%40mail.gmail.com</a>.<br />

--001a114b416c71b44d053397de42--

.

--001a11c3207099e69b05339806d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 5:04 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:

And what about captures by references? *What *would they be initialized
>> with?
>>
>>
> The current behaviour (though I didn't check the exact wording) makes the
> closure copyable even when capturing
> by reference.
> It is unspecified (if my memory is correct) if data have to be stored whe=
n
> capturing by reference,
> but when an implementation needs to store the implementation of the
> reference capture,
> it imply the the actual stored data behave like (or is actually) a pointe=
r.
> Pointers can be default constructed.
>

Is that a way of saying that captures by reference would be bound to
non-existing objects? Here is an excerpt from [dcl.ref] that makes this
problematic:

A reference shall be initialized to refer to a valid object or function. [
Note: in particular, a null reference cannot exist in a well-defined
program, because the only way to create such a reference would be to bind
it to the =E2=80=9Cobject=E2=80=9D obtained by indirection through a null p=
ointer, which
causes undefined behavior. As described in 9.6, a reference cannot be bound
directly to a bit-field. =E2=80=94 end note ]
[end]

Cheers,
V.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg3oH23ZGhhfcooqtj4jD%2Bfk0fG320db0YuO3eVi%=
3DOGC0Q%40mail.gmail.com.

--001a11c3207099e69b05339806d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 5:04 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div>And what about captures by references? <i>What </i>would they=
 be initialized with?</div><div><br></div></div></div></div></blockquote><d=
iv><br></div><div>The current behaviour (though I didn&#39;t check the exac=
t wording) makes the closure copyable even when capturing</div><div>by refe=
rence.</div><div>It is unspecified (if my memory is correct) if data have t=
o be stored when capturing by reference,</div><div>but when an implementati=
on needs to store the implementation of the reference capture,</div><div>it=
 imply the the actual stored data behave like (or is actually) a pointer.</=
div><div>Pointers can be default constructed.</div></div></div></div></bloc=
kquote><div>=C2=A0</div><div>Is that a way of saying that captures by refer=
ence would be bound to non-existing objects? Here is an excerpt from [dcl.r=
ef] that makes this problematic:</div><div><br></div><div>A reference shall=
 be initialized to refer to a valid object or
function. [ Note: in particular, a null reference cannot exist in a well-de=
fined program, because the only way
to create such a reference would be to bind it to the =E2=80=9Cobject=E2=80=
=9D obtained by indirection through a null pointer,
which causes undefined behavior. As described in 9.6, a reference cannot be=
 bound directly to a bit-field.
=E2=80=94 end note ]=C2=A0<br></div><div>[end]</div><div><br></div><div>Che=
ers,</div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3oH23ZGhhfcooqtj4jD%2Bfk0fG320=
db0YuO3eVi%3DOGC0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3oH23Z=
Ghhfcooqtj4jD%2Bfk0fG320db0YuO3eVi%3DOGC0Q%40mail.gmail.com</a>.<br />

--001a11c3207099e69b05339806d6--

.

--047d7b5d2a78234bbc0533980a1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 17:02, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:

> On 24 May 2016 at 17:49, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wr=
ote:
> >
> >
> > On 24 May 2016 at 16:29, Ville Voutilainen <ville.voutilainen@gmail.com=
>
> > wrote:
> >>
> >> On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com>
> wrote:
> >> > I am looking for the reason why lambda expressions are explicitly
> >> > not defining a default constructor (at least depending on the
> arguments
> >> > constructors).
> >> >
> >> > I cannot find a specific reason for that so far.
> >> > Does anyone here have a source about this point?
> >>
> >> If the lambda has captures, it's either insane or impossible to
> >> default-construct it.
> >
> >
> > Why? I do not see any justification or explanation of what is "insane" =
so
> > far.
>
> If the lambda has captures, those captures have values. A default
> constructed lambda
> will not have those same values. It's questionable whether it is of
> the same type, and my
> answer to that question is no.
>
>
Why would captured types be of different types if you are using the same
closure type?


> > I do not see why a =3Ddefault; could not be used
> > to rely on capture's type default constructors, deleting the default
> > constructor if it would not be possible for a normal type either.
>
> Sure it could, but the problem isn't as much of whether the captures
> are default-constructible,
> but of what values they should have.
>
>
Is'nt default construction's value when available a reasonnable value?


> >> Treating non-capturing lambdas differently would require motivation th=
at
> >> hasn't
> >> appeared thus far, at least not in proposal form.
> > I agree that both cases should have the exact same behaviour, but this =
is
> > not really my point.
>
> That "agreement" is not quite right, because I'm not suggesting that
> those cases should have
> the exact same behavior.
>
>
If default construction of captured types is used, then the behaviour is
uniform
and I do not consider non-capturing lambda expressions to be a special case=
..
This is what I meant. I'm not totally sure if there is a disagreement here.

Jo=C3=ABl Lamotte

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91ONnAdJBRa%2BZEJ0e2VxTOAWbHN11gh2y58qCHKboq=
wJu7w%40mail.gmail.com.

--047d7b5d2a78234bbc0533980a1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 17:02, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 24 May 2016 at 17:49, Klaim - Jo=C3=ABl Lamotte &lt;<a href=3D=
"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On 24 May 2016 at 16:29, Ville Voutilainen &lt;<a href=3D"mailto:ville=
..voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 24 May 2016 at 17:25, Klaim - Jo=C3=ABl Lamotte &lt;<a href=3D"=
mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; I am looking for the reason why lambda expressions are explic=
itly<br>
&gt;&gt; &gt; not defining a default constructor (at least depending on the=
 arguments<br>
&gt;&gt; &gt; constructors).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I cannot find a specific reason for that so far.<br>
&gt;&gt; &gt; Does anyone here have a source about this point?<br>
&gt;&gt;<br>
&gt;&gt; If the lambda has captures, it&#39;s either insane or impossible t=
o<br>
&gt;&gt; default-construct it.<br>
&gt;<br>
&gt;<br>
&gt; Why? I do not see any justification or explanation of what is &quot;in=
sane&quot; so<br>
&gt; far.<br>
<br>
</span>If the lambda has captures, those captures have values. A default<br=
>
constructed lambda<br>
will not have those same values. It&#39;s questionable whether it is of<br>
the same type, and my<br>
answer to that question is no.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>Why would capt=
ured types be of different types if you are using the same closure type?</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; I =
do not see why a =3Ddefault; could not be used<br>
&gt; to rely on capture&#39;s type default constructors, deleting the defau=
lt<br>
&gt; constructor if it would not be possible for a normal type either.<br>
<br>
</span>Sure it could, but the problem isn&#39;t as much of whether the capt=
ures<br>
are default-constructible,<br>
but of what values they should have.<br><br></blockquote><div><br></div><di=
v>Is&#39;nt default construction&#39;s value when available a reasonnable v=
alue?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>
&gt;&gt; Treating non-capturing lambdas differently would require motivatio=
n that<br>
&gt;&gt; hasn&#39;t<br>
&gt;&gt; appeared thus far, at least not in proposal form.<br>
&gt; I agree that both cases should have the exact same behaviour, but this=
 is<br>
&gt; not really my point.<br>
<br>
</span>That &quot;agreement&quot; is not quite right, because I&#39;m not s=
uggesting that<br>
those cases should have<br>
the exact same behavior.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>If default con=
struction of captured types is used, then the behaviour is uniform</div><di=
v>and I do not consider non-capturing lambda expressions to be a special ca=
se.</div><div>This is what I meant. I&#39;m not totally sure if there is a =
disagreement here.</div><div><br></div><div>Jo=C3=ABl Lamotte</div><div><br=
></div><div><br></div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONnAdJBRa%2BZEJ0e2VxTOAWbHN11gh=
2y58qCHKboqwJu7w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONnAdJBRa=
%2BZEJ0e2VxTOAWbHN11gh2y58qCHKboqwJu7w%40mail.gmail.com</a>.<br />

--047d7b5d2a78234bbc0533980a1c--

.

On 24 May 2016 at 18:16, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:
>> If the lambda has captures, those captures have values. A default
>> constructed lambda
>> will not have those same values. It's questionable whether it is of
>> the same type, and my
>> answer to that question is no.
>>
>
> Why would captured types be of different types if you are using the same
> closure type?

Because if the captured types have different values, the closure types
are not same, by design.

>> > I do not see why a =3Ddefault; could not be used
>> > to rely on capture's type default constructors, deleting the default
>> > constructor if it would not be possible for a normal type either.
>>
>> Sure it could, but the problem isn't as much of whether the captures
>> are default-constructible,
>> but of what values they should have.
>>
>
> Is'nt default construction's value when available a reasonnable value?

No. And it doesn't work for reference captures anyway.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUa0NBwSSLf2sAdgdvyrkZ7LKDu60DgWYrcpK1h_b%3=
DHLJA%40mail.gmail.com.

.

--001a11c3b60256dce10533981477
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 17:15, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Tue, May 24, 2016 at 5:04 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail=
..com>
> wrote:
>
> And what about captures by references? *What *would they be initialized
>>> with?
>>>
>>>
>> The current behaviour (though I didn't check the exact wording) makes th=
e
>> closure copyable even when capturing
>> by reference.
>> It is unspecified (if my memory is correct) if data have to be stored
>> when capturing by reference,
>> but when an implementation needs to store the implementation of the
>> reference capture,
>> it imply the the actual stored data behave like (or is actually) a
>> pointer.
>> Pointers can be default constructed.
>>
>
> Is that a way of saying that captures by reference would be bound to
> non-existing objects? Here is an excerpt from [dcl.ref] that makes this
> problematic:
>
> A reference shall be initialized to refer to a valid object or function. =
[
> Note: in particular, a null reference cannot exist in a well-defined
> program, because the only way to create such a reference would be to bind
> it to the =E2=80=9Cobject=E2=80=9D obtained by indirection through a null=
 pointer, which
> causes undefined behavior. As described in 9.6, a reference cannot be bou=
nd
> directly to a bit-field. =E2=80=94 end note ]
> [end]
>
>
Interesting. So even if I propose a zero-intiialization for reference
capture types, it would conflict with this.



> Cheers,
> V.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3oH23=
ZGhhfcooqtj4jD%2Bfk0fG320db0YuO3eVi%3DOGC0Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3oH2=
3ZGhhfcooqtj4jD%2Bfk0fG320db0YuO3eVi%3DOGC0Q%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OO1io2-XObK3hDSGVoDGoZ2Qan0rFJwoFVoqvsPMCg=
cJw%40mail.gmail.com.

--001a11c3b60256dce10533981477
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 17:15, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote">On Tue, May 2=
4, 2016 at 5:04 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</=
span> wrote:</div></span><div class=3D"gmail_quote"><span class=3D""><br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div>And what about captures by references? <i>What=
 </i>would they be initialized with?</div><div><br></div></div></div></div>=
</blockquote><div><br></div><div>The current behaviour (though I didn&#39;t=
 check the exact wording) makes the closure copyable even when capturing</d=
iv><div>by reference.</div><div>It is unspecified (if my memory is correct)=
 if data have to be stored when capturing by reference,</div><div>but when =
an implementation needs to store the implementation of the reference captur=
e,</div><div>it imply the the actual stored data behave like (or is actuall=
y) a pointer.</div><div>Pointers can be default constructed.</div></div></d=
iv></div></blockquote><div>=C2=A0</div></span><div>Is that a way of saying =
that captures by reference would be bound to non-existing objects? Here is =
an excerpt from [dcl.ref] that makes this problematic:</div><div><br></div>=
<div>A reference shall be initialized to refer to a valid object or
function. [ Note: in particular, a null reference cannot exist in a well-de=
fined program, because the only way
to create such a reference would be to bind it to the =E2=80=9Cobject=E2=80=
=9D obtained by indirection through a null pointer,
which causes undefined behavior. As described in 9.6, a reference cannot be=
 bound directly to a bit-field.
=E2=80=94 end note ]=C2=A0<br></div><div>[end]</div><div><br></div></div></=
div></div></blockquote><div><br></div><div>Interesting. So even if I propos=
e a zero-intiialization for reference capture types, it would conflict with=
 this.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></div><spa=
n class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3oH23ZGhhfcooqtj4jD%2Bfk0fG320=
db0YuO3eVi%3DOGC0Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAA7YVg3oH23ZGhhfcooqtj4jD%2Bfk0fG320db0YuO3eVi%3DOGC0Q%40mail.gma=
il.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OO1io2-XObK3hDSGVoDGoZ2Qan0rFJw=
oFVoqvsPMCgcJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OO1io2-XObK=
3hDSGVoDGoZ2Qan0rFJwoFVoqvsPMCgcJw%40mail.gmail.com</a>.<br />

--001a11c3b60256dce10533981477--

.

--001a11c3b60268fcce0533981b44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 17:19, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:

>
>
> On 24 May 2016 at 17:15, Viacheslav Usov <via.usov@gmail.com> wrote:
>
>> On Tue, May 24, 2016 at 5:04 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmai=
l.com>
>> wrote:
>>
>> And what about captures by references? *What *would they be initialized
>>>> with?
>>>>
>>>>
>>> The current behaviour (though I didn't check the exact wording) makes
>>> the closure copyable even when capturing
>>> by reference.
>>> It is unspecified (if my memory is correct) if data have to be stored
>>> when capturing by reference,
>>> but when an implementation needs to store the implementation of the
>>> reference capture,
>>> it imply the the actual stored data behave like (or is actually) a
>>> pointer.
>>> Pointers can be default constructed.
>>>
>>
>> Is that a way of saying that captures by reference would be bound to
>> non-existing objects? Here is an excerpt from [dcl.ref] that makes this
>> problematic:
>>
>> A reference shall be initialized to refer to a valid object or function.
>> [ Note: in particular, a null reference cannot exist in a well-defined
>> program, because the only way to create such a reference would be to bin=
d
>> it to the =E2=80=9Cobject=E2=80=9D obtained by indirection through a nul=
l pointer, which
>> causes undefined behavior. As described in 9.6, a reference cannot be bo=
und
>> directly to a bit-field. =E2=80=94 end note ]
>> [end]
>>
>>
> Interesting. So even if I propose a zero-intiialization for reference
> capture types, it would conflict with this.
>
>
So let's exclude captures by reference from this proposal idea then.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OPu1EAQzG28skcsk8uANoZ8MMz_U6n1e-jiFNmj3iw=
fag%40mail.gmail.com.

--001a11c3b60268fcce0533981b44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 17:19, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"=
">On 24 May 2016 at 17:15, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=3D=
"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><span><div class=3D"gmail_quote">On Tue, May 24, 2016 at 5=
:04 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
jklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</span> wrote:=
</div></span><div class=3D"gmail_quote"><span><br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>And what about captures by references? <i>What </i>would they be init=
ialized with?</div><div><br></div></div></div></div></blockquote><div><br><=
/div><div>The current behaviour (though I didn&#39;t check the exact wordin=
g) makes the closure copyable even when capturing</div><div>by reference.</=
div><div>It is unspecified (if my memory is correct) if data have to be sto=
red when capturing by reference,</div><div>but when an implementation needs=
 to store the implementation of the reference capture,</div><div>it imply t=
he the actual stored data behave like (or is actually) a pointer.</div><div=
>Pointers can be default constructed.</div></div></div></div></blockquote><=
div>=C2=A0</div></span><div>Is that a way of saying that captures by refere=
nce would be bound to non-existing objects? Here is an excerpt from [dcl.re=
f] that makes this problematic:</div><div><br></div><div>A reference shall =
be initialized to refer to a valid object or
function. [ Note: in particular, a null reference cannot exist in a well-de=
fined program, because the only way
to create such a reference would be to bind it to the =E2=80=9Cobject=E2=80=
=9D obtained by indirection through a null pointer,
which causes undefined behavior. As described in 9.6, a reference cannot be=
 bound directly to a bit-field.
=E2=80=94 end note ]=C2=A0<br></div><div>[end]</div><div><br></div></div></=
div></div></blockquote><div><br></div></span><div>Interesting. So even if I=
 propose a zero-intiialization for reference capture types, it would confli=
ct with this.</div><span class=3D""><div><br></div></span></div></div></div=
></blockquote><div><br></div><div>So let&#39;s exclude captures by referenc=
e from this proposal idea then.=C2=A0</div><div><br></div><div><br></div></=
div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OPu1EAQzG28skcsk8uANoZ8MMz_U6n1=
e-jiFNmj3iwfag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OPu1EAQzG28=
skcsk8uANoZ8MMz_U6n1e-jiFNmj3iwfag%40mail.gmail.com</a>.<br />

--001a11c3b60268fcce0533981b44--

.

--047d7b5d2a7829619405339830ef
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 17:18, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:

> On 24 May 2016 at 18:16, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wr=
ote:
> >> If the lambda has captures, those captures have values. A default
> >> constructed lambda
> >> will not have those same values. It's questionable whether it is of
> >> the same type, and my
> >> answer to that question is no.
> >>
> >
> > Why would captured types be of different types if you are using the sam=
e
> > closure type?
>
> Because if the captured types have different values, the closure types
> are not same, by design.
>
>
My understanding so far is not what you describe.
The closure type is always the same for one lambda expression,
but it's stored values can be whatever is possible values of the captured
types.
For example:

#include <typeindex>
#include <cassert>

template<class T>
auto make_func(T value)
{
   return [=3D]{ return value; };
}


int main()
{
   assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234))); // succeed
}


That is, I make a clear difference beween the lambda expression and the
generated
anonymous closure type, which is still a type.


> >> > I do not see why a =3Ddefault; could not be used
> >> > to rely on capture's type default constructors, deleting the default
> >> > constructor if it would not be possible for a normal type either.
> >>
> >> Sure it could, but the problem isn't as much of whether the captures
> >> are default-constructible,
> >> but of what values they should have.
> >>
> >
> > Is'nt default construction's value when available a reasonnable value?
>
> No. And it doesn't work for reference captures anyway.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa0NBw=
SSLf2sAdgdvyrkZ7LKDu60DgWYrcpK1h_b%3DHLJA%40mail.gmail.com
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OOZsRXgx5eGG4ef8KsoaWjQm5xcbdzwqB1S1Csm9%3=
DQz_w%40mail.gmail.com.

--047d7b5d2a7829619405339830ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 17:18, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"">On 2=
4 May 2016 at 18:16, Klaim - Jo=C3=ABl Lamotte &lt;<a href=3D"mailto:mjklai=
m@gmail.com">mjklaim@gmail.com</a>&gt; wrote:<br>
&gt;&gt; If the lambda has captures, those captures have values. A default<=
br>
&gt;&gt; constructed lambda<br>
&gt;&gt; will not have those same values. It&#39;s questionable whether it =
is of<br>
&gt;&gt; the same type, and my<br>
&gt;&gt; answer to that question is no.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Why would captured types be of different types if you are using the sa=
me<br>
&gt; closure type?<br>
<br>
</span>Because if the captured types have different values, the closure typ=
es<br>
are not same, by design.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>My understandi=
ng so far is not what you describe.</div><div>The closure type is always th=
e same for one lambda expression,</div><div>but it&#39;s stored values can =
be whatever is possible values of the captured types.</div><div>For example=
:</div><div><br></div><div><div>#include &lt;typeindex&gt;</div><div>#inclu=
de &lt;cassert&gt;</div><div><br></div><div>template&lt;class T&gt;</div><d=
iv>auto make_func(T value)</div><div>{</div><div>=C2=A0 =C2=A0return [=3D]{=
 return value; };</div><div>}</div><div><br></div><div><br></div><div>int m=
ain()</div><div>{</div><div>=C2=A0 =C2=A0assert(typeid(make_func(42)) =3D=
=3D typeid(make_func(1234))); // succeed</div><div>}</div></div><div><br></=
div><div><br></div><div>That is, I make a clear difference beween the lambd=
a expression and the generated=C2=A0</div><div>anonymous closure type, whic=
h is still a type.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"">
&gt;&gt; &gt; I do not see why a =3Ddefault; could not be used<br>
&gt;&gt; &gt; to rely on capture&#39;s type default constructors, deleting =
the default<br>
&gt;&gt; &gt; constructor if it would not be possible for a normal type eit=
her.<br>
&gt;&gt;<br>
&gt;&gt; Sure it could, but the problem isn&#39;t as much of whether the ca=
ptures<br>
&gt;&gt; are default-constructible,<br>
&gt;&gt; but of what values they should have.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Is&#39;nt default construction&#39;s value when available a reasonnabl=
e value?<br>
<br>
</span>No. And it doesn&#39;t work for reference captures anyway.<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa0NBwSSLf2sAdgdvyrkZ7LK=
Du60DgWYrcpK1h_b%3DHLJA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa0N=
BwSSLf2sAdgdvyrkZ7LKDu60DgWYrcpK1h_b%3DHLJA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OOZsRXgx5eGG4ef8KsoaWjQm5xcbdzw=
qB1S1Csm9%3DQz_w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OOZsRXgx5=
eGG4ef8KsoaWjQm5xcbdzwqB1S1Csm9%3DQz_w%40mail.gmail.com</a>.<br />

--047d7b5d2a7829619405339830ef--

.

------=_Part_725_2123439801.1464103895660
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Since user-defined types with reference members are not defaut=20
constructible, by-reference capturing lambdas should not be=20
default-constructible, I guess.
Concerning values of default-constructed members, for example :

// We're in a generic context and F is the type of a lambda.
F f; // should default construct members, so undefined value for integral=
=20
types and pointers
F f{}; // should zero-initialize members (by constructing members with {})

Jeremy

Le mardi 24 mai 2016 16:25:40 UTC+2, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit=
 :
>
> I am looking for the reason why lambda expressions are explicitly
> not defining a default constructor (at least depending on the arguments=
=20
> constructors).
>
> I cannot find a specific reason for that so far.
> Does anyone here have a source about this point?
>
>
> Otherwise I would like to propose to add=20
>
>     ClosureType() =3D default;=20
>
> to the definition of the closure generated by a lambda, if it's not=20
> already proposed somewhere.
>
> This would help working with closures in generic context where we assume
> that the callable type is regular (it's not enough but it helps);
>
> For example with this kind of code:
>
>
> template< class T, class Callable >
> struct FatForwardIterator
> {
>   T value;
>   Callable incr; // deactivate the default constructor if it's a closure
>   //... etc
>
>   FatForwardIterator& operator++()
>   {
>     // ...
>     value =3D incr(value);
>     return *this;
>   }
> };
> // let's assume that the proposal to generate default comparisons is on..=
..
>
>
> template< class T, class Callable >
> auto make_fat_iterator( T initial_value, Callable incr )
> {
>   return FatForwardIterator<T, Callable>{ initial_value, incr };
> }
>
> template< class IteratorType>
> void some_algorithm( IteratorType begin, IteratorType end )
> {
>   IteratorType previous; // error: IteratorType do not have a default=20
> constructor.
>   do
>   {
>     previous =3D begin;
>     ++begin;
>     // ... use previous
>   }
>   while( begin !=3D end );
> }
>
>
> void foo()
> {
>   auto times2 =3D [](auto value){  return value * 2; };
>   auto begin =3D make_fat_iterator( 1, times2 );
>   auto end =3D make_fat_iterator( 8, times2 );
>
>   // ...=20
>   some_algorithm( begin, end ); // fails to compile
> }
>
>
>
--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dcd439ad-d758-4765-a37d-45688f719fc3%40isocpp.or=
g.

------=_Part_725_2123439801.1464103895660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Since user-defined types with reference members are not de=
faut constructible, by-reference capturing lambdas should not be default-co=
nstructible, I guess.<div><div>Concerning values of default-constructed mem=
bers, for example :</div><div><br></div><div>// We&#39;re in a generic cont=
ext and F is the type of a lambda.</div><div>F f; // should default constru=
ct members, so undefined value for integral types and pointers</div><div>F =
f{}; // should zero-initialize members (by constructing members with {})</d=
iv><div><br></div><div>Jeremy</div><div><br>Le mardi 24 mai 2016 16:25:40 U=
TC+2, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit=C2=A0:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr">I am looking for the reason why lambd=
a expressions are explicitly<div>not defining a default constructor (at lea=
st depending on the arguments constructors).</div><div><br></div><div>I can=
not find a specific reason for that so far.</div><div>Does anyone here have=
 a source about this point?</div><div><br></div><div><br></div><div>Otherwi=
se I would like to propose to add=C2=A0</div><div><br></div><div>=C2=A0 =C2=
=A0 ClosureType() =3D default;=C2=A0</div><div><br></div><div>to the defini=
tion of the closure generated by a lambda, if it&#39;s not already proposed=
 somewhere.</div><div><br></div><div>This would help working with closures =
in generic context where we assume</div><div>that the callable type is regu=
lar (it&#39;s not enough but it helps);</div><div><br></div><div>For exampl=
e with this kind of code:</div><div><br></div><div><div><br></div><div>temp=
late&lt; class T, class Callable &gt;</div><div>struct FatForwardIterator</=
div><div>{</div><div>=C2=A0 T value;</div><div>=C2=A0 Callable incr; // dea=
ctivate the default constructor if it&#39;s a closure</div><div>=C2=A0 //..=
.. etc</div><div><br></div><div>=C2=A0 FatForwardIterator&amp; operator++()<=
/div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 // ...</div><div>=C2=A0 =C2=A0 v=
alue =3D incr(value);</div><div>=C2=A0 =C2=A0 return *this;</div><div>=C2=
=A0 }</div><div>};</div><div>// let&#39;s assume that the proposal to gener=
ate default comparisons is on...</div><div><br></div><div><br></div><div><d=
iv>template&lt; class T, class Callable &gt;</div><div>auto make_fat_iterat=
or( T initial_value, Callable incr )</div><div>{</div><div>=C2=A0 return Fa=
tForwardIterator&lt;T, Callable&gt;{ initial_value, incr };</div><div>}</di=
v></div><div><br></div><div>template&lt; class IteratorType&gt;</div><div>v=
oid some_algorithm( IteratorType begin, IteratorType end )</div><div>{</div=
><div>=C2=A0 IteratorType previous; // error: IteratorType do not have a de=
fault constructor.</div><div>=C2=A0 do</div><div>=C2=A0 {</div><div>=C2=A0 =
=C2=A0 previous =3D begin;</div><div>=C2=A0 =C2=A0 ++begin;</div><div>=C2=
=A0 =C2=A0 // ... use previous</div><div>=C2=A0 }</div><div>=C2=A0 while( b=
egin !=3D end );</div><div>}</div><div><br></div><div><br></div><div>void f=
oo()</div><div>{</div><div>=C2=A0 auto times2 =3D [](auto value){ =C2=A0ret=
urn value * 2; };</div><div>=C2=A0 auto begin =3D make_fat_iterator( 1, tim=
es2 );</div><div>=C2=A0 auto end =3D make_fat_iterator( 8, times2 );</div><=
div><br></div><div>=C2=A0 // ...=C2=A0</div><div>=C2=A0 some_algorithm( beg=
in, end ); // fails to compile</div><div>}</div></div><div><br></div><div><=
br></div></div>
</blockquote></div></div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dcd439ad-d758-4765-a37d-45688f719fc3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dcd439ad-d758-4765-a37d-45688f719fc3=
%40isocpp.org</a>.<br />

------=_Part_725_2123439801.1464103895660--

.

On 24 May 2016 at 18:26, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:
> My understanding so far is not what you describe.
> The closure type is always the same for one lambda expression,
> but it's stored values can be whatever is possible values of the captured
> types.

[expr.prim.lambda]/4:

"The type of the lambda-expression (which is also the type of the
closure object) is a unique, unnamed
non-union class type =E2=80=94 called the closure type =E2=80=94 whose prop=
erties are
described below."

> For example:
>
> #include <typeindex>
> #include <cassert>
>
> template<class T>
> auto make_func(T value)
> {
>    return [=3D]{ return value; };
> }
>
>
> int main()
> {
>    assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234))); // succe=
ed
> }

That looks like a bug to me. The lambdas returned from different
specializations of make_func are not
unique types.

> That is, I make a clear difference beween the lambda expression and the
> generated
> anonymous closure type, which is still a type.

The wording seems to disagree with you.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUa%3D8emeBYAP-3BHtvt%3DQiw3RDjwPEn4zsoHrsr=
v%2BreB1g%40mail.gmail.com.

.

--001a114430a47bec0f053398753c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 17:34, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:

> On 24 May 2016 at 18:26, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wr=
ote:
> > My understanding so far is not what you describe.
> > The closure type is always the same for one lambda expression,
> > but it's stored values can be whatever is possible values of the captur=
ed
> > types.
>
> [expr.prim.lambda]/4:
>
> "The type of the lambda-expression (which is also the type of the
> closure object) is a unique, unnamed
> non-union class type =E2=80=94 called the closure type =E2=80=94 whose pr=
operties are
> described below."
>
> > For example:
> >
> > #include <typeindex>
> > #include <cassert>
> >
> > template<class T>
> > auto make_func(T value)
> > {
> >    return [=3D]{ return value; };
> > }
> >
> >
> > int main()
> > {
> >    assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234))); // suc=
ceed
> > }
>
> That looks like a bug to me. The lambdas returned from different
> specializations of make_func are not
> unique types.
>
>
I do not see how types could be generated for each possible values (which
depends
on the runtime). Or am I misunderstanding your point?


> > That is, I make a clear difference beween the lambda expression and the
> > generated
> > anonymous closure type, which is still a type.
>
> The wording seems to disagree with you.
>
>
I read that the lambda expression is a unique unnamed closure type.
I do not read that it's type is relative to the values of the captured
objects.
However it does imply it's type it is relative to the _type_ of these
captured objects
and that the initial value of the instance of the closure type does have an
initial value relative
to the captured objects values.



> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa%3D8=
emeBYAP-3BHtvt%3DQiw3RDjwPEn4zsoHrsrv%2BreB1g%40mail.gmail.com
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OPXTvsphdwzEOFip9T4qfVwFUX52eE4%2BOhFNazZC=
9mAiA%40mail.gmail.com.

--001a114430a47bec0f053398753c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 17:34, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 24 May 2016 at 18:26, Klaim - Jo=C3=ABl Lamotte &lt;<a href=3D=
"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt; wrote:<br>
&gt; My understanding so far is not what you describe.<br>
&gt; The closure type is always the same for one lambda expression,<br>
&gt; but it&#39;s stored values can be whatever is possible values of the c=
aptured<br>
&gt; types.<br>
<br>
</span>[expr.prim.lambda]/4:<br>
<br>
&quot;The type of the lambda-expression (which is also the type of the<br>
closure object) is a unique, unnamed<br>
non-union class type =E2=80=94 called the closure type =E2=80=94 whose prop=
erties are<br>
described below.&quot;<br>
<span class=3D""><br>
&gt; For example:<br>
&gt;<br>
&gt; #include &lt;typeindex&gt;<br>
&gt; #include &lt;cassert&gt;<br>
&gt;<br>
&gt; template&lt;class T&gt;<br>
&gt; auto make_func(T value)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 return [=3D]{ return value; };<br>
&gt; }<br>
&gt;<br>
&gt;<br>
&gt; int main()<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234=
))); // succeed<br>
&gt; }<br>
<br>
</span>That looks like a bug to me. The lambdas returned from different<br>
specializations of make_func are not<br>
unique types.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>I do not see h=
ow types could be generated for each possible values (which depends</div><d=
iv>on the runtime). Or am I misunderstanding your point?</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span class=3D"">
&gt; That is, I make a clear difference beween the lambda expression and th=
e<br>
&gt; generated<br>
&gt; anonymous closure type, which is still a type.<br>
<br>
</span>The wording seems to disagree with you.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>I read that th=
e lambda expression is a unique unnamed closure type.</div><div>I do not re=
ad that it&#39;s type is relative to the values of the captured objects.</d=
iv><div>However it does imply it&#39;s type it is relative to the _type_ of=
 these captured objects</div><div>and that the initial value of the instanc=
e of the closure type does have an initial value relative</div><div>to the =
captured objects values.</div><div><br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><span class=3D"">
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa%3D8emeBYAP-3BHtvt%3DQ=
iw3RDjwPEn4zsoHrsrv%2BreB1g%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2R=
Ua%3D8emeBYAP-3BHtvt%3DQiw3RDjwPEn4zsoHrsrv%2BreB1g%40mail.gmail.com</a>.<b=
r>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OPXTvsphdwzEOFip9T4qfVwFUX52eE4=
%2BOhFNazZC9mAiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OPXTvsphd=
wzEOFip9T4qfVwFUX52eE4%2BOhFNazZC9mAiA%40mail.gmail.com</a>.<br />

--001a114430a47bec0f053398753c--

.

--001a11c33e6c9235f5053398a4e3
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 5:34 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:


> > template<class T>
> > auto make_func(T value)
> > {
> >    return [=]{ return value; };
> > }
> >
> >
> > int main()
> > {
> >    assert(typeid(make_func(42)) == typeid(make_func(1234))); // succeed
> > }
>
> That looks like a bug to me. The lambdas returned from
> different specializations of make_func are not unique types.
>

I do not see different specializations here. make_func<int> is used in both
cases.

I do not think I can follow the argument of either of you at this point,
though. The original proposal has already been reduced to
capture-by-value-only lambdas. Making that default constructible,
contingent on default constructibility of the captured types, should be
rather trivial. The question is, is there any really useful effect
achievable through this and not achievable otherwise that is worth the
effort? I am not convinced.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2%3D1yOuD-w78g%2BX5SrjaNfaHh3Sp%3DfKi%2Btgb5p5DpTn8A%40mail.gmail.com.

--001a11c33e6c9235f5053398a4e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 5:34 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">&gt; template&lt;class T&gt;<br>
&gt; auto make_func(T value)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 return [=3D]{ return value; };<br>
&gt; }<br>
&gt;<br>
&gt;<br>
&gt; int main()<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234=
))); // succeed<br>
&gt; }<br>
<br>
That looks like a bug to me. The lambdas returned from different=C2=A0speci=
alizations of make_func are not=C2=A0unique types.<br></blockquote><div><br=
></div><div>I do not see different specializations here. make_func&lt;int&g=
t; is used in both cases.</div><div><br></div><div>I do not think I can fol=
low the argument of either of you at this point, though. The original propo=
sal has already been reduced to capture-by-value-only lambdas. Making that =
default constructible, contingent on default constructibility of the captur=
ed types, should be rather trivial. The question is, is there any really us=
eful effect achievable through this and not achievable otherwise that is wo=
rth the effort? I am not convinced.</div><div><br></div><div>Cheers,</div><=
div>V.</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2%3D1yOuD-w78g%2BX5SrjaNfaHh3S=
p%3DfKi%2Btgb5p5DpTn8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2%=
3D1yOuD-w78g%2BX5SrjaNfaHh3Sp%3DfKi%2Btgb5p5DpTn8A%40mail.gmail.com</a>.<br=
 />

--001a11c33e6c9235f5053398a4e3--

.

On 24 May 2016 at 18:46, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrot=
e:
>> > For example:
>> >
>> > #include <typeindex>
>> > #include <cassert>
>> >
>> > template<class T>
>> > auto make_func(T value)
>> > {
>> >    return [=3D]{ return value; };
>> > }
>> >
>> >
>> > int main()
>> > {
>> >    assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234))); // su=
cceed
>> > }
>>
>> That looks like a bug to me. The lambdas returned from different
>> specializations of make_func are not
>> unique types.
>>
>
> I do not see how types could be generated for each possible values (which
> depends
> on the runtime). Or am I misunderstanding your point?

Argh, sorry, I completely misread the example. I see what you mean now.

>> > That is, I make a clear difference beween the lambda expression and th=
e
>> > generated
>> > anonymous closure type, which is still a type.
>>
>> The wording seems to disagree with you.
>>
>
> I read that the lambda expression is a unique unnamed closure type.
> I do not read that it's type is relative to the values of the captured
> objects.

Correct.

> However it does imply it's type it is relative to the _type_ of these
> captured objects
> and that the initial value of the instance of the closure type does have =
an
> initial value relative
> to the captured objects values.

Right. So, despite my momentary adventures to the crazy-land, we have
three issues here:

1) currently, it's not possible for a capturing lambda to have
captures that have default-constructed
values, they are the result of copy-initialization. Changing that is a
breaking change, because some
lunatic might rely on that. I don't have practical examples of that.

2) reference-capturing lambdas can't be default-constructed, nor can
lambdas which capture
non-default-constructible types. So not all lambdas can be
default-constructed. That doesn't seem
to be a huge issue. Not all lambdas can be copied, either, as that
won't work with captures of move-only
type.

3) for lambdas that don't depend on run-time values, users can
currently rely on the lambda only ever
having the values that were captured when the lambda was created.
Allowing default-construction with
some other values breaks that expectation. Again, I don't know whether
that's significant.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYPgSeJDAXh8_%3DML92%3Dhr0naDSFbwooFSpfRoM=
DUJtMBg%40mail.gmail.com.

.

> Il giorno 24 mag 2016, alle ore 17:34, Ville Voutilainen <ville.voutilain=
en@gmail.com> ha scritto:
>=20
> On 24 May 2016 at 18:26, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wr=
ote:
>> My understanding so far is not what you describe.
>> The closure type is always the same for one lambda expression,
>> but it's stored values can be whatever is possible values of the capture=
d
>> types.
>=20
> [expr.prim.lambda]/4:
>=20
> "The type of the lambda-expression (which is also the type of the
> closure object) is a unique, unnamed
> non-union class type =E2=80=94 called the closure type =E2=80=94 whose pr=
operties are
> described below."
>=20
>> For example:
>>=20
>> #include <typeindex>
>> #include <cassert>
>>=20
>> template<class T>
>> auto make_func(T value)
>> {
>>   return [=3D]{ return value; };
>> }
>>=20
>>=20
>> int main()
>> {
>>   assert(typeid(make_func(42)) =3D=3D typeid(make_func(1234))); // succe=
ed
>> }
>=20
> That looks like a bug to me. The lambdas returned from different
> specializations of make_func are not
> unique types.
>=20
>> That is, I make a clear difference beween the lambda expression and the
>> generated
>> anonymous closure type, which is still a type.
>=20
> The wording seems to disagree with you.
>=20

For what matters for this thread, the example can be rephrased=20
without templates, since it is calling the same instantiation of the=20
function anyway. If you change T, the type will be different, indeed.


Consider:

auto make_func(int value)
{
  return [=3D]{ return value; };
}

Then call make_func(42) and make_func(1337).
How can you expect the lambda to change its type?
The captured value is a runtime effect of the execution of the program,
it cannot affect the type in this way. The return type of make_func
has to be always the same by definition. Functions have a well-defined type=
..

Klaim=E2=80=99s claim (eheh) is correct. Types of lambda functions are uniq=
uely determined
independently from the captured *values*.

To return to the main issue, in my opinion it is perfectly sensible to prov=
ide
a default constructor to the closure type *when a user defined type with th=
e
same members of the same type as captures would be able to have one*.

E.g.:

struct NC { NC(int x); };

{
  int x;
  NC nc{42}; =20

  auto f =3D [x]{ return x; };
  auto g =3D [nc]{ return nc; };
}

In this case, decltype(f) should have a default constructor because =E2=80=
=98int=E2=80=99 can be default
constructed, while decltype(g) should not, because the NC struct is not def=
ault constructible.

It is perfectly coherent with how closure types are translated under the ho=
od:

struct f_lambda_t
{
  auto operator()() const {
     return x;
  }
private:
  int x;
};

struct g_lambda_t
{
  auto operator()() const {
     return x;
  }
private:
  NC x;
};

If you add f_lambda_t() =3D default; and g_lambda_t() =3D default;, respect=
ively, you
obtain what the original email was asking. For user defined types it would =
be perfectly
legal and well-defined. Also, someone brought up the issue about reference =
captures.
There is no issue. Put a reference in the struct above and the default cons=
tructor would
not be generated.

In a generic context, to me it is very annoying that closure types are not =
regular when
all the captured types are regular.

Bye,
Nicola



--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7507DCF8-0FC3-4E9B-ABC6-FBCEF91381D8%40gmail.com=
..

.

--001a11449c065d5bc7053398d79b
Content-Type: text/plain; charset=UTF-8

On 24 May 2016 at 11:06, Nicola Gigante <nicola.gigante@gmail.com> wrote:

> To return to the main issue, in my opinion it is perfectly sensible to
> provide
> a default constructor to the closure type *when a user defined type with
> the
> same members of the same type as captures would be able to have one*.
>

Why?  No one has yet provided motivation for this, and given that it is
fairly painful to get the type of the lambda to declare another one (you
need to pass it to a template or decltype), having a capturing lambda where
the values are either the ones captured or ones that are default
constructed doesn't seem all that useful.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10Sn_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com.

--001a11449c065d5bc7053398d79b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 24 May 2016 at 11:06, Nicola=
 Gigante <span dir=3D"ltr">&lt;<a href=3D"mailto:nicola.gigante@gmail.com" =
target=3D"_blank">nicola.gigante@gmail.com</a>&gt;</span> wrote:<br><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>To return to the ma=
in issue, in my opinion it is perfectly sensible to provide<br>
a default constructor to the closure type *when a user defined type with th=
e<br>
same members of the same type as captures would be able to have one*.<br></=
div></blockquote></div><br>Why?=C2=A0 No one has yet provided motivation fo=
r this, and given that it is fairly painful to get the type of the lambda t=
o declare another one (you need to pass it to a template or decltype), havi=
ng a capturing lambda where the values are either the ones captured or ones=
 that are default constructed doesn&#39;t seem all that useful.</div><div c=
lass=3D"gmail_extra">-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0=
<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blank">=
+1-847-691-1404</a></div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10S=
n_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
MNO%3DifeLz%2BTmNdkyJ33GH10Sn_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com</a>.<br=
 />

--001a11449c065d5bc7053398d79b--

.

--001a113f399a3c5c1e053398e6e9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 4:25 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:

> IteratorType previous; // error: IteratorType do not have a default
constructor.

This is your real problem. Not that lambdas are not default constructible.
Your algorithm requires a default constructible iterator. This is not a
general requirement for iterators. I am sure there is a way to have a
default constructible iterator even if encapsulates something not default
constructible.

I do not see how this can motivate your proposal.

Cheers,
V.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg1P0SQz0PSKuDPwVF3i5PibasFEADoBGao4kkB92rJ=
f%3DQ%40mail.gmail.com.

--001a113f399a3c5c1e053398e6e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 4:25 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br><div><br></div><div>&gt; IteratorType previous; //=
 error: IteratorType do not have a default constructor.</div><div><br></div=
><div>This is your real problem. Not that lambdas are not default construct=
ible. Your algorithm requires a default constructible iterator. This is not=
 a general requirement for iterators. I am sure there is a way to have a de=
fault constructible iterator even if encapsulates something not default con=
structible.</div><div><br></div><div>I do not see how this can motivate you=
r proposal.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br></d=
iv></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1P0SQz0PSKuDPwVF3i5PibasFEADoB=
Gao4kkB92rJf%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1P0SQz0P=
SKuDPwVF3i5PibasFEADoBGao4kkB92rJf%3DQ%40mail.gmail.com</a>.<br />

--001a113f399a3c5c1e053398e6e9--

.

--001a114691b297d2580533991046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 May 2016 at 18:17, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Tue, May 24, 2016 at 4:25 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail=
..com>
> wrote:
>
> > IteratorType previous; // error: IteratorType do not have a default
> constructor.
>
> This is your real problem. Not that lambdas are not default constructible=
..
> Your algorithm requires a default constructible iterator. This is not a
> general requirement for iterators. I am sure there is a way to have a
> default constructible iterator even if encapsulates something not default
> constructible.
>
> I do not see how this can motivate your proposal.
>

Well, this example is directly inspired by Stepanov's book "Element's of
Programming", page 106 (find_adjacent_mismatch_forward()),
where such a default initialization seems necessary.

Jo=C3=ABl Lamotte

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91ONLXF6TMOPoKoELR_L6oF3j-dn%3DvmrbwCByPs1Ha=
P8PvA%40mail.gmail.com.

--001a114691b297d2580533991046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 24 May 2016 at 18:17, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, May 24=
, 2016 at 4:25 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</=
span> wrote:<br><div><br></div><div>&gt; IteratorType previous; // error: I=
teratorType do not have a default constructor.</div><div><br></div></span><=
div>This is your real problem. Not that lambdas are not default constructib=
le. Your algorithm requires a default constructible iterator. This is not a=
 general requirement for iterators. I am sure there is a way to have a defa=
ult constructible iterator even if encapsulates something not default const=
ructible.</div><div><br></div><div>I do not see how this can motivate your =
proposal.</div></blockquote></div><br>Well, this example is directly inspir=
ed by Stepanov&#39;s book &quot;Element&#39;s of Programming&quot;, page 10=
6 (find_adjacent_mismatch_forward()),</div><div class=3D"gmail_extra">where=
 such a default initialization seems necessary.</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">Jo=C3=ABl Lamotte</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONLXF6TMOPoKoELR_L6oF3j-dn%3Dvm=
rbwCByPs1HaP8PvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONLXF6TMO=
PoKoELR_L6oF3j-dn%3DvmrbwCByPs1HaP8PvA%40mail.gmail.com</a>.<br />

--001a114691b297d2580533991046--

.

--001a1144237000a55a05339918f2
Content-Type: text/plain; charset=UTF-8

On 24 May 2016 at 18:13, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 24 May 2016 at 11:06, Nicola Gigante <nicola.gigante@gmail.com> wrote:
>
>> To return to the main issue, in my opinion it is perfectly sensible to
>> provide
>> a default constructor to the closure type *when a user defined type with
>> the
>> same members of the same type as captures would be able to have one*.
>>
>
> Why?  No one has yet provided motivation for this, and given that it is
> fairly painful to get the type of the lambda to declare another one (you
> need to pass it to a template or decltype), having a capturing lambda where
> the values are either the ones captured or ones that are default
> constructed doesn't seem all that useful.
>

By "No one has yet provided motivation for this" do you mean that the
initial example is not representative
of usual generic code development and usage?



> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10Sn_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10Sn_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OM0r7NvGRgSZERaZSWePg9b%2B6bu%2B2SEAN7CzVywOQpfag%40mail.gmail.com.

--001a1144237000a55a05339918f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 May 2016 at 18:13, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><span class=3D"">On 24 May 2016 at 11:06, Nicola Gigante <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nicola.gigante@gmail.com" target=3D"_blank">=
nicola.gigante@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div>To return to the main issue, in my opinion it is pe=
rfectly sensible to provide<br>
a default constructor to the closure type *when a user defined type with th=
e<br>
same members of the same type as captures would be able to have one*.<br></=
div></blockquote></div><br></span>Why?=C2=A0 No one has yet provided motiva=
tion for this, and given that it is fairly painful to get the type of the l=
ambda to declare another one (you need to pass it to a template or decltype=
), having a capturing lambda where the values are either the ones captured =
or ones that are default constructed doesn&#39;t seem all that useful.</div=
></div></blockquote><div><br></div><div>By &quot;No one has yet provided mo=
tivation for this&quot; do you mean that the initial example is not represe=
ntative</div><div>of usual generic code development and usage?</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra">-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Ne=
vin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilover=
lord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0<a href=3D=
"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blank">+1-847-691=
-1404</a></div></div></div></div></div>
</div></div><span class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10S=
n_pGcrfcy0j7V%2B94B4hQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CAGg_6%2BMNO%3DifeLz%2BTmNdkyJ33GH10Sn_pGcrfcy0j7V%2B94B4hQ%=
40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OM0r7NvGRgSZERaZSWePg9b%2B6bu%2=
B2SEAN7CzVywOQpfag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OM0r7Nv=
GRgSZERaZSWePg9b%2B6bu%2B2SEAN7CzVywOQpfag%40mail.gmail.com</a>.<br />

--001a1144237000a55a05339918f2--

.

--001a11340bd49e9c6d0533991f07
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

n 24 May 2016 at 11:31, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrote=
:

>
>
> On 24 May 2016 at 18:13, Nevin Liber <nevin@eviloverlord.com> wrote:
>
>> On 24 May 2016 at 11:06, Nicola Gigante <nicola.gigante@gmail.com> wrote=
:
>>
>>> To return to the main issue, in my opinion it is perfectly sensible to
>>> provide
>>> a default constructor to the closure type *when a user defined type wit=
h
>>> the
>>> same members of the same type as captures would be able to have one*.
>>>
>>
>> Why?  No one has yet provided motivation for this, and given that it is
>> fairly painful to get the type of the lambda to declare another one (you
>> need to pass it to a template or decltype), having a capturing lambda wh=
ere
>> the values are either the ones captured or ones that are default
>> constructed doesn't seem all that useful.
>>
>
> By "No one has yet provided motivation for this" do you mean that the
> initial example is not representative
> of usual generic code development and usage?
>

I can't imagine generic code where I want an object in only one of two
states, one of which I have very little control in setting up.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGg_6%2BMQGffx53YLsD889EQBowJsq-wDhmNdV9OQb%3Dk=
vgNthrQ%40mail.gmail.com.

--001a11340bd49e9c6d0533991f07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra">n 24 May 2016 at 11:31, Kla=
im - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"mailto:mjklaim@gmai=
l.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</span> wrote:<br><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On 24 May 2016=
 at 18:13, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><span>On 24=
 May 2016 at 11:06, Nicola Gigante <span dir=3D"ltr">&lt;<a href=3D"mailto:=
nicola.gigante@gmail.com" target=3D"_blank">nicola.gigante@gmail.com</a>&gt=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>To retu=
rn to the main issue, in my opinion it is perfectly sensible to provide<br>
a default constructor to the closure type *when a user defined type with th=
e<br>
same members of the same type as captures would be able to have one*.<br></=
div></blockquote></div><br></span>Why?=C2=A0 No one has yet provided motiva=
tion for this, and given that it is fairly painful to get the type of the l=
ambda to declare another one (you need to pass it to a template or decltype=
), having a capturing lambda where the values are either the ones captured =
or ones that are default constructed doesn&#39;t seem all that useful.</div=
></div></blockquote><div><br></div></span><div>By &quot;No one has yet prov=
ided motivation for this&quot; do you mean that the initial example is not =
representative</div><div>of usual generic code development and usage?</div>=
</div></div></div></blockquote><div><br></div><div>I can&#39;t imagine gene=
ric code where I want an object in only one of two states, one of which I h=
ave very little control in setting up.</div></div>-- <br><div><div dir=3D"l=
tr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt; =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18=
476911404" target=3D"_blank">+1-847-691-1404</a></div></div></div></div></d=
iv>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMQGffx53YLsD889EQBowJsq-wDhm=
NdV9OQb%3DkvgNthrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMQGf=
fx53YLsD889EQBowJsq-wDhmNdV9OQb%3DkvgNthrQ%40mail.gmail.com</a>.<br />

--001a11340bd49e9c6d0533991f07--

.

------=_Part_862_1607851035.1464107835846
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le mardi 24 mai 2016 18:29:46 UTC+2, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit=
 :
>
>
> On 24 May 2016 at 18:17, Viacheslav Usov <via....@gmail.com <javascript:>=
>=20
> wrote:
>
>> On Tue, May 24, 2016 at 4:25 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail=
..com=20
>> <javascript:>> wrote:
>>
>> > IteratorType previous; // error: IteratorType do not have a default=20
>> constructor.
>>
>> This is your real problem. Not that lambdas are not default=20
>> constructible. Your algorithm requires a default constructible iterator.=
=20
>> This is not a general requirement for iterators. I am sure there is a wa=
y=20
>> to have a default constructible iterator even if encapsulates something =
not=20
>> default constructible.
>>
>> I do not see how this can motivate your proposal.
>>
>
> Well, this example is directly inspired by Stepanov's book "Element's of=
=20
> Programming", page 106 (find_adjacent_mismatch_forward()),
> where such a default initialization seems necessary.
>
>
Note that in "Elements of programming" such a default constructed value is=
=20
said to be in a "partially-formed state", i.e. it's only assignable or=20
destructible.
So this means that it doesn't matter if the members are default-constructed=
=20
with an undefined value. The main purpose is to have a virtually free=20
default-construction.
=20

> Jo=C3=ABl Lamotte
>
>
>
--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5b592591-ef29-4ef2-bb6a-a93c4f6208dd%40isocpp.or=
g.

------=_Part_862_1607851035.1464107835846
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 24 mai 2016 18:29:46 UTC+2, Klaim - Jo=C3=
=ABl Lamotte a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On 24 May 2016 at 18=
:17, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"cdwQxRgkDgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">via....@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span>On Tue, May 24, 2016 at 4:25 P=
M, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"cdwQxRgkDgAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">mjk...@gmail.com</a>&gt;</spa=
n> wrote:<br><div><br></div><div>&gt; IteratorType previous; // error: Iter=
atorType do not have a default constructor.</div><div><br></div></span><div=
>This is your real problem. Not that lambdas are not default constructible.=
 Your algorithm requires a default constructible iterator. This is not a ge=
neral requirement for iterators. I am sure there is a way to have a default=
 constructible iterator even if encapsulates something not default construc=
tible.</div><div><br></div><div>I do not see how this can motivate your pro=
posal.</div></blockquote></div><br>Well, this example is directly inspired =
by Stepanov&#39;s book &quot;Element&#39;s of Programming&quot;, page 106 (=
find_adjacent_mismatch_<wbr>forward()),</div><div>where such a default init=
ialization seems necessary.</div><div><br></div></div></blockquote><div><br=
></div><div>Note that in &quot;Elements of programming&quot; such a default=
 constructed value is said to be in a &quot;partially-formed state&quot;, i=
..e. it&#39;s only assignable or destructible.</div><div>So this means that =
it doesn&#39;t matter if the members are default-constructed with an undefi=
ned value. The main purpose is to have a virtually free default-constructio=
n.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>Jo=C3=ABl Lamotte</div><div><br></div><div><br>=
</div></div>
</blockquote></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b592591-ef29-4ef2-bb6a-a93c4f6208dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b592591-ef29-4ef2-bb6a-a93c4f6208dd=
%40isocpp.org</a>.<br />

------=_Part_862_1607851035.1464107835846--

.

--001a11c32070aad24105339933e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 6:29 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:

> Well, this example is directly inspired by Stepanov's book "Element's of
Programming", page 106 (find_adjacent_mismatch_forward()), where such a
default initialization seems necessary.

Again. I cannot see how that motivates a need for default constructible
lambdas. Lambda is not a forward iterator, and it does not need to be one.
If you want to wrap a lambda in an forward iterator, you can do so
*without* default
constructibility of lambdas.

Cheers,
V.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg39K7vsB%2BzZP2ytZoMaHim_BbjFc0uLVEdNjd0F%=
2BkztXA%40mail.gmail.com.

--001a11c32070aad24105339933e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 6:29 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br><div><br></div><div>&gt; Well, this example is dir=
ectly inspired by Stepanov&#39;s book &quot;Element&#39;s of Programming&qu=
ot;, page 106 (find_adjacent_mismatch_forward()), where such a default init=
ialization seems necessary.</div><div><br></div><div>Again. I cannot see ho=
w that motivates a need for default constructible lambdas. Lambda is not a =
forward iterator, and it does not need to be one. If you want to wrap a lam=
bda in an forward iterator, you can do so <i>without</i>=C2=A0default const=
ructibility of lambdas.</div><div><br></div><div>Cheers,</div><div>V.</div>=
</div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg39K7vsB%2BzZP2ytZoMaHim_BbjFc0=
uLVEdNjd0F%2BkztXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg39K7vs=
B%2BzZP2ytZoMaHim_BbjFc0uLVEdNjd0F%2BkztXA%40mail.gmail.com</a>.<br />

--001a11c32070aad24105339933e2--

.

------=_Part_6262_404781695.1464110630212
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The initial example is, well, just an example.
The real motivation is to be able to manipulate lambdas as a Regular values=
..
It should be easy to use lambdas and compose them with the rest of the=20
language.
For example, if I design an new type and want it to be comparable (=3D=3D),=
 its=20
members should be comparable. If I want this new type to be default=20
constructible (for example, if I want to store instances in an array, or be=
=20
able to cheaply construct objects before having their values), its members=
=20
should be default constructible.
If I'm doing generic programming and one of the members of this new type is=
=20
an instance of a Callable type, there's no way for me to know if it's a=20
lambda or user-defined type (and from a generic point of view, I don't=20
care).
But the problem is, if this callable member is a user-defined type and it's=
=20
default-constructible, the equivalent lambda won't.

Example:

// This is default constructible (if M is default-constructible).
template<typename M>
struct udf_incr {
  M m;
  M operator()(M const& n) const {return n * m;}
};

int m{2};
// This is not.
auto lambda_incr =3D [=3D](auto n) {return n * m;}

// concepts: Regular T, RegularFunction<T (T)> F
template<typename T, typename F>
struct advance_t {
  // advance_t is default constructible if T and F are=20
default-constructible.
  T value;
  F incr_fun;
  void operator()() {
     value =3D incr_fun(value);
  }
};

Now, advance_t<int, udf_incr<int>> is default constructible, but=20
advance_t<int, decltype(lambda_incr)> is not, even if they are semantically=
=20
equivalent.
The same problem occurs with comparison if I add operator=3D=3D to udf_incr=
..

The point is, in generic code it's not possible to use lambdas with types=
=20
designed to be Regular, and it seems feasible to correct this.

Le mardi 24 mai 2016 18:39:35 UTC+2, Viacheslav Usov a =C3=A9crit :
>
> On Tue, May 24, 2016 at 6:29 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.=
com=20
> <javascript:>> wrote:
>
> > Well, this example is directly inspired by Stepanov's book "Element's o=
f=20
> Programming", page 106 (find_adjacent_mismatch_forward()), where such a=
=20
> default initialization seems necessary.
>
> Again. I cannot see how that motivates a need for default constructible=
=20
> lambdas. Lambda is not a forward iterator, and it does not need to be one=
..=20
> If you want to wrap a lambda in an forward iterator, you can do so=20
> *without* default constructibility of lambdas.
>
> Cheers,
> V.
>

--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6a390bde-e9e1-4066-b515-892d88716932%40isocpp.or=
g.

------=_Part_6262_404781695.1464110630212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The initial example is, well, just an example.<div>The rea=
l motivation is to be able to manipulate lambdas as a Regular values.</div>=
<div>It should be easy to use lambdas and compose them with the rest of the=
 language.</div><div>For example, if I design an new type and want it to be=
 comparable (=3D=3D), its members should be comparable. If I want this new =
type to be default constructible (for example, if I want to store instances=
 in an array, or be able to cheaply construct objects before having their v=
alues), its members should be default constructible.</div><div>If I&#39;m d=
oing generic programming and one of the members of this new type is an inst=
ance of a Callable type, there&#39;s no way for me to know if it&#39;s a la=
mbda or user-defined type (and from a generic point of view, I don&#39;t ca=
re).</div><div>But the problem is, if this callable member is a user-define=
d type and it&#39;s default-constructible, the equivalent lambda won&#39;t.=
</div><div><br></div><div>Example:</div><div><br></div><div>// This is defa=
ult constructible (if M is default-constructible).</div><div>template&lt;ty=
pename M&gt;</div><div>struct udf_incr {</div><div>=C2=A0 M m;</div><div>=
=C2=A0 M operator()(M const&amp; n) const {return n * m;}</div><div>};</div=
><div><br></div><div>int m{2};</div><div>// This is not.</div><div>auto lam=
bda_incr =3D [=3D](auto n) {return n * m;}</div><div><br></div><div>// conc=
epts: Regular T, RegularFunction&lt;T (T)&gt; F</div><div>template&lt;typen=
ame T, typename F&gt;</div><div>struct advance_t {</div><div>=C2=A0 // adva=
nce_t is default constructible if T and F are default-constructible.</div><=
div>=C2=A0 T value;</div><div>=C2=A0 F incr_fun;</div><div>=C2=A0 void oper=
ator()() {</div><div>=C2=A0 =C2=A0 =C2=A0value =3D incr_fun(value);</div><d=
iv>=C2=A0 }</div><div>};</div><div><br></div><div>Now, advance_t&lt;int, ud=
f_incr&lt;int&gt;&gt; is default constructible, but advance_t&lt;int, declt=
ype(lambda_incr)&gt; is not, even if they are semantically equivalent.</div=
><div>The same problem occurs with comparison if I add operator=3D=3D to ud=
f_incr.</div><div><br></div><div>The point is, in generic code it&#39;s not=
 possible to use lambdas with types designed to be Regular, and it seems fe=
asible to correct this.</div><div><br>Le mardi 24 mai 2016 18:39:35 UTC+2, =
Viacheslav Usov a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, May 24, 2016=
 at 6:29 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"p3zbuaEkDgAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;">mjk...@gmail.com</a=
>&gt;</span> wrote:<br><div><br></div><div>&gt; Well, this example is direc=
tly inspired by Stepanov&#39;s book &quot;Element&#39;s of Programming&quot=
;, page 106 (find_adjacent_mismatch_<wbr>forward()), where such a default i=
nitialization seems necessary.</div><div><br></div><div>Again. I cannot see=
 how that motivates a need for default constructible lambdas. Lambda is not=
 a forward iterator, and it does not need to be one. If you want to wrap a =
lambda in an forward iterator, you can do so <i>without</i>=C2=A0default co=
nstructibility of lambdas.</div><div><br></div><div>Cheers,</div><div>V.</d=
iv></div></div></div>
</blockquote></div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6a390bde-e9e1-4066-b515-892d88716932%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a390bde-e9e1-4066-b515-892d88716932=
%40isocpp.org</a>.<br />

------=_Part_6262_404781695.1464110630212--

.

--089e0111bc56f8a307053399f108
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Currently a lambda may rely on its captured by copy values to have not
changed unless it itself changed them.

If you allow default construction, this invariant will break. Maybe bad.

Am 24.05.2016 16:25 schrieb "Klaim - Jo=C3=ABl Lamotte" <mjklaim@gmail.com>=
:
>
> I am looking for the reason why lambda expressions are explicitly
> not defining a default constructor (at least depending on the arguments
constructors).
>
> I cannot find a specific reason for that so far.
> Does anyone here have a source about this point?
>
>
> Otherwise I would like to propose to add
>
>     ClosureType() =3D default;
>
> to the definition of the closure generated by a lambda, if it's not
already proposed somewhere.
>
> This would help working with closures in generic context where we assume
> that the callable type is regular (it's not enough but it helps);
>
> For example with this kind of code:
>
>
> template< class T, class Callable >
> struct FatForwardIterator
> {
>   T value;
>   Callable incr; // deactivate the default constructor if it's a closure
>   //... etc
>
>   FatForwardIterator& operator++()
>   {
>     // ...
>     value =3D incr(value);
>     return *this;
>   }
> };
> // let's assume that the proposal to generate default comparisons is on..=
..
>
>
> template< class T, class Callable >
> auto make_fat_iterator( T initial_value, Callable incr )
> {
>   return FatForwardIterator<T, Callable>{ initial_value, incr };
> }
>
> template< class IteratorType>
> void some_algorithm( IteratorType begin, IteratorType end )
> {
>   IteratorType previous; // error: IteratorType do not have a default
constructor.
>   do
>   {
>     previous =3D begin;
>     ++begin;
>     // ... use previous
>   }
>   while( begin !=3D end );
> }
>
>
> void foo()
> {
>   auto times2 =3D [](auto value){  return value * 2; };
>   auto begin =3D make_fat_iterator( 1, times2 );
>   auto end =3D make_fat_iterator( 8, times2 );
>
>   // ...
>   some_algorithm( begin, end ); // fails to compile
> }
>
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdU=
ZQ_JpyVwcV0%2BsXVdUUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com
..

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANu6V4VEBfkXnmPYGn6gW%3DKgSqB3NPFNuWJ%2BMtDgUM%=
2Bfp8ZWqw%40mail.gmail.com.

--089e0111bc56f8a307053399f108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Currently a lambda may rely on its captured by copy values t=
o have not changed unless it itself changed them.</p>
<p dir=3D"ltr">If you allow default construction, this invariant will break=
.. Maybe bad.</p>
<p dir=3D"ltr">Am 24.05.2016 16:25 schrieb &quot;Klaim - Jo=C3=ABl Lamotte&=
quot; &lt;<a href=3D"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt;:<b=
r>
&gt;<br>
&gt; I am looking for the reason why lambda expressions are explicitly<br>
&gt; not defining a default constructor (at least depending on the argument=
s constructors).<br>
&gt;<br>
&gt; I cannot find a specific reason for that so far.<br>
&gt; Does anyone here have a source about this point?<br>
&gt;<br>
&gt;<br>
&gt; Otherwise I would like to propose to add=C2=A0<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 ClosureType() =3D default;=C2=A0<br>
&gt;<br>
&gt; to the definition of the closure generated by a lambda, if it&#39;s no=
t already proposed somewhere.<br>
&gt;<br>
&gt; This would help working with closures in generic context where we assu=
me<br>
&gt; that the callable type is regular (it&#39;s not enough but it helps);<=
br>
&gt;<br>
&gt; For example with this kind of code:<br>
&gt;<br>
&gt;<br>
&gt; template&lt; class T, class Callable &gt;<br>
&gt; struct FatForwardIterator<br>
&gt; {<br>
&gt; =C2=A0 T value;<br>
&gt; =C2=A0 Callable incr; // deactivate the default constructor if it&#39;=
s a closure<br>
&gt; =C2=A0 //... etc<br>
&gt;<br>
&gt; =C2=A0 FatForwardIterator&amp; operator++()<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 // ...<br>
&gt; =C2=A0 =C2=A0 value =3D incr(value);<br>
&gt; =C2=A0 =C2=A0 return *this;<br>
&gt; =C2=A0 }<br>
&gt; };<br>
&gt; // let&#39;s assume that the proposal to generate default comparisons =
is on...<br>
&gt;<br>
&gt;<br>
&gt; template&lt; class T, class Callable &gt;<br>
&gt; auto make_fat_iterator( T initial_value, Callable incr )<br>
&gt; {<br>
&gt; =C2=A0 return FatForwardIterator&lt;T, Callable&gt;{ initial_value, in=
cr };<br>
&gt; }<br>
&gt;<br>
&gt; template&lt; class IteratorType&gt;<br>
&gt; void some_algorithm( IteratorType begin, IteratorType end )<br>
&gt; {<br>
&gt; =C2=A0 IteratorType previous; // error: IteratorType do not have a def=
ault constructor.<br>
&gt; =C2=A0 do<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 previous =3D begin;<br>
&gt; =C2=A0 =C2=A0 ++begin;<br>
&gt; =C2=A0 =C2=A0 // ... use previous<br>
&gt; =C2=A0 }<br>
&gt; =C2=A0 while( begin !=3D end );<br>
&gt; }<br>
&gt;<br>
&gt;<br>
&gt; void foo()<br>
&gt; {<br>
&gt; =C2=A0 auto times2 =3D [](auto value){ =C2=A0return value * 2; };<br>
&gt; =C2=A0 auto begin =3D make_fat_iterator( 1, times2 );<br>
&gt; =C2=A0 auto end =3D make_fat_iterator( 8, times2 );<br>
&gt;<br>
&gt; =C2=A0 // ...=C2=A0<br>
&gt; =C2=A0 some_algorithm( begin, end ); // fails to compile<br>
&gt; }<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2BsXVd=
UUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2BsXVdUUcSnmgrzr4u6viuV=
k5WQ%40mail.gmail.com</a>.<br>
</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4VEBfkXnmPYGn6gW%3DKgSqB3NPFNuW=
J%2BMtDgUM%2Bfp8ZWqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4VEBf=
kXnmPYGn6gW%3DKgSqB3NPFNuWJ%2BMtDgUM%2Bfp8ZWqw%40mail.gmail.com</a>.<br />

--089e0111bc56f8a307053399f108--

.

--001a11427e34f1134c05339a00f8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This also means that even though the corresponding member of the lambda is
nonconst, a compiler can constant propagate copy captured members if the
lambda body hasn't changed the closure copy data member.

Allowing default constructing members destroys this nice optimization
opportunity.

Am 24.05.2016 19:32 schrieb "Johannes Schaub" <
schaub.johannes@googlemail.com>:
>
> Currently a lambda may rely on its captured by copy values to have not
changed unless it itself changed them.
>
> If you allow default construction, this invariant will break. Maybe bad.
>
> Am 24.05.2016 16:25 schrieb "Klaim - Jo=C3=ABl Lamotte" <mjklaim@gmail.co=
m>:
> >
> > I am looking for the reason why lambda expressions are explicitly
> > not defining a default constructor (at least depending on the arguments
constructors).
> >
> > I cannot find a specific reason for that so far.
> > Does anyone here have a source about this point?
> >
> >
> > Otherwise I would like to propose to add
> >
> >     ClosureType() =3D default;
> >
> > to the definition of the closure generated by a lambda, if it's not
already proposed somewhere.
> >
> > This would help working with closures in generic context where we assum=
e
> > that the callable type is regular (it's not enough but it helps);
> >
> > For example with this kind of code:
> >
> >
> > template< class T, class Callable >
> > struct FatForwardIterator
> > {
> >   T value;
> >   Callable incr; // deactivate the default constructor if it's a closur=
e
> >   //... etc
> >
> >   FatForwardIterator& operator++()
> >   {
> >     // ...
> >     value =3D incr(value);
> >     return *this;
> >   }
> > };
> > // let's assume that the proposal to generate default comparisons is
on...
> >
> >
> > template< class T, class Callable >
> > auto make_fat_iterator( T initial_value, Callable incr )
> > {
> >   return FatForwardIterator<T, Callable>{ initial_value, incr };
> > }
> >
> > template< class IteratorType>
> > void some_algorithm( IteratorType begin, IteratorType end )
> > {
> >   IteratorType previous; // error: IteratorType do not have a default
constructor.
> >   do
> >   {
> >     previous =3D begin;
> >     ++begin;
> >     // ... use previous
> >   }
> >   while( begin !=3D end );
> > }
> >
> >
> > void foo()
> > {
> >   auto times2 =3D [](auto value){  return value * 2; };
> >   auto begin =3D make_fat_iterator( 1, times2 );
> >   auto end =3D make_fat_iterator( 8, times2 );
> >
> >   // ...
> >   some_algorithm( begin, end ); // fails to compile
> > }
> >
> >
> > --
> > 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.
> > To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdU=
ZQ_JpyVwcV0%2BsXVdUUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com
..

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANu6V4UJ2Z7-fvrw8YhYmwcvSH_RTeBMWq%3D4xVcBxgY3V=
Go9aw%40mail.gmail.com.

--001a11427e34f1134c05339a00f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">This also means that even though the corresponding member of=
 the lambda is nonconst, a compiler can constant propagate copy captured me=
mbers if the lambda body hasn&#39;t changed the closure copy data member.</=
p>
<p dir=3D"ltr">Allowing default constructing members destroys this nice opt=
imization opportunity. </p>
<p dir=3D"ltr">Am 24.05.2016 19:32 schrieb &quot;Johannes Schaub&quot; &lt;=
<a href=3D"mailto:schaub.johannes@googlemail.com">schaub.johannes@googlemai=
l.com</a>&gt;:<br>
&gt;<br>
&gt; Currently a lambda may rely on its captured by copy values to have not=
 changed unless it itself changed them.<br>
&gt;<br>
&gt; If you allow default construction, this invariant will break. Maybe ba=
d.<br>
&gt;<br>
&gt; Am 24.05.2016 16:25 schrieb &quot;Klaim - Jo=C3=ABl Lamotte&quot; &lt;=
<a href=3D"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>&gt;:<br>
&gt; &gt;<br>
&gt; &gt; I am looking for the reason why lambda expressions are explicitly=
<br>
&gt; &gt; not defining a default constructor (at least depending on the arg=
uments constructors).<br>
&gt; &gt;<br>
&gt; &gt; I cannot find a specific reason for that so far.<br>
&gt; &gt; Does anyone here have a source about this point?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Otherwise I would like to propose to add=C2=A0<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 ClosureType() =3D default;=C2=A0<br>
&gt; &gt;<br>
&gt; &gt; to the definition of the closure generated by a lambda, if it&#39=
;s not already proposed somewhere.<br>
&gt; &gt;<br>
&gt; &gt; This would help working with closures in generic context where we=
 assume<br>
&gt; &gt; that the callable type is regular (it&#39;s not enough but it hel=
ps);<br>
&gt; &gt;<br>
&gt; &gt; For example with this kind of code:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; template&lt; class T, class Callable &gt;<br>
&gt; &gt; struct FatForwardIterator<br>
&gt; &gt; {<br>
&gt; &gt; =C2=A0 T value;<br>
&gt; &gt; =C2=A0 Callable incr; // deactivate the default constructor if it=
&#39;s a closure<br>
&gt; &gt; =C2=A0 //... etc<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 FatForwardIterator&amp; operator++()<br>
&gt; &gt; =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 // ...<br>
&gt; &gt; =C2=A0 =C2=A0 value =3D incr(value);<br>
&gt; &gt; =C2=A0 =C2=A0 return *this;<br>
&gt; &gt; =C2=A0 }<br>
&gt; &gt; };<br>
&gt; &gt; // let&#39;s assume that the proposal to generate default compari=
sons is on...<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; template&lt; class T, class Callable &gt;<br>
&gt; &gt; auto make_fat_iterator( T initial_value, Callable incr )<br>
&gt; &gt; {<br>
&gt; &gt; =C2=A0 return FatForwardIterator&lt;T, Callable&gt;{ initial_valu=
e, incr };<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; template&lt; class IteratorType&gt;<br>
&gt; &gt; void some_algorithm( IteratorType begin, IteratorType end )<br>
&gt; &gt; {<br>
&gt; &gt; =C2=A0 IteratorType previous; // error: IteratorType do not have =
a default constructor.<br>
&gt; &gt; =C2=A0 do<br>
&gt; &gt; =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 previous =3D begin;<br>
&gt; &gt; =C2=A0 =C2=A0 ++begin;<br>
&gt; &gt; =C2=A0 =C2=A0 // ... use previous<br>
&gt; &gt; =C2=A0 }<br>
&gt; &gt; =C2=A0 while( begin !=3D end );<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; void foo()<br>
&gt; &gt; {<br>
&gt; &gt; =C2=A0 auto times2 =3D [](auto value){ =C2=A0return value * 2; };=
<br>
&gt; &gt; =C2=A0 auto begin =3D make_fat_iterator( 1, times2 );<br>
&gt; &gt; =C2=A0 auto end =3D make_fat_iterator( 8, times2 );<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 // ...=C2=A0<br>
&gt; &gt; =C2=A0 some_algorithm( begin, end ); // fails to compile<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; -- <br>
&gt; &gt; You received this message because you are subscribed to the Googl=
e Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; &gt; To unsubscribe from this group and stop receiving emails from it,=
 send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-propos=
als@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; &gt; To view this discussion on the web visit <a href=3D"https://group=
s.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2=
BsXVdUUcSnmgrzr4u6viuVk5WQ%40mail.gmail.com">https://groups.google.com/a/is=
ocpp.org/d/msgid/std-proposals/CAOU91ONZtVMdUZQ_JpyVwcV0%2BsXVdUUcSnmgrzr4u=
6viuVk5WQ%40mail.gmail.com</a>.<br>
</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4UJ2Z7-fvrw8YhYmwcvSH_RTeBMWq%3=
D4xVcBxgY3VGo9aw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4UJ2Z7-fv=
rw8YhYmwcvSH_RTeBMWq%3D4xVcBxgY3VGo9aw%40mail.gmail.com</a>.<br />

--001a11427e34f1134c05339a00f8--

.

------=_Part_520_13605294.1464112503343
Content-Type: multipart/alternative;
 boundary="----=_Part_521_2039412147.1464112503344"

------=_Part_521_2039412147.1464112503344
Content-Type: text/plain; charset=UTF-8

On Tuesday, May 24, 2016 at 1:23:50 PM UTC-4, jmo...@aldebaran.com wrote:
>
> The initial example is, well, just an example.
> The real motivation is to be able to manipulate lambdas as a Regular
> values.
>

I think the question you're missing is "why do you want to?"

If you have a function which takes a function object to be called later,
why would you want to manipulate such parameters "as a Regular values"?

Functions are *not* regular values. While some callable types may fit the
Regular concept, they do *not* fit the actual *semantics* behind that
concept.

Also, let's say I write this:

auto val = 30
auto lamb = [val]() {...}

That `...` part currently can be written under the assumption that the
captured `val` will *always* be 30. However, under your rules, it won't. It
may be 30, or it may be a default-constructed `int` (ie: undefined).

That's bad.

Sure, this example is rather simplistic. But `val` could be anything. It
could be a raw pointer for the lambda to access. Those will not produce
reasonable results under default construction.

The whole point of making lambdas a closure is that what they close over is
well-defined. By allowing lambdas to be default constructed, the values
they close over are no longer well-defined.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9c3baf8c-5b47-4c1d-afa6-6852888daa94%40isocpp.org.

------=_Part_521_2039412147.1464112503344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 24, 2016 at 1:23:50 PM UTC-4, jmo...@aldeb=
aran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">The initial example is, well, just an example.<div>The real motivation is=
 to be able to manipulate lambdas as a Regular values.</div></div></blockqu=
ote><div><br>I think the question you&#39;re missing is &quot;why do you wa=
nt to?&quot;<br><br>If you have a function which takes a function object to=
 be called later, why would you want to manipulate such parameters &quot;as=
 a Regular values&quot;?</div><br>Functions are <i>not</i> regular values. =
While some callable types may fit the Regular concept, they do <i>not</i> f=
it the actual <i>semantics</i> behind that concept.<br><br>Also, let&#39;s =
say I write this:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> val </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">30</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> lamb </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-b=
y-prettify">val</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">]()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...}</span=
></div></code></div><br>That `...` part currently can be written under the =
assumption that the captured `val` will <i>always</i> be 30. However, under=
 your rules, it won&#39;t. It may be 30, or it may be a default-constructed=
 `int` (ie: undefined).<br><br>That&#39;s bad.<br><br>Sure, this example is=
 rather simplistic. But `val` could be anything. It could be a raw pointer =
for the lambda to access. Those will not produce reasonable results under d=
efault construction.<br><br>The whole point of making lambdas a closure is =
that what they close over is well-defined. By allowing lambdas to be defaul=
t constructed, the values they close over are no longer well-defined.<br></=
div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9c3baf8c-5b47-4c1d-afa6-6852888daa94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9c3baf8c-5b47-4c1d-afa6-6852888daa94=
%40isocpp.org</a>.<br />

------=_Part_521_2039412147.1464112503344--

------=_Part_520_13605294.1464112503343--

.

--001a114f6014d05e1f05339a54f6
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
>
> Again. I cannot see how that motivates a need for default constructible
> lambdas.
>

It's never strictly a need, it's just a convenience.

It can also be argued that it is consistent with user-defined class types
for any lambda where a corresponding type that had the capture types as
datamembers would be a default constructible type (i.e. not for reference
types, etc.), as was mentioned. I would personally say that it makes more
sense to start with what's consistent with the rest of the language and
only diverge from that if there is some kind of logical inconsistency. In
other words, when adding a new feature such as lambdas (a little late now,
I know), the burden, IMO, should be on *opponents* to argue why there
should *not* be consistent rules with other types, as opposed to the
proposal author needing to provide motivating cases for consistency.
Language consistency should be a starting point because when features
differ, those are more differences that users need to know about, making
the language harder to learn and intuit (and in practice, it usually makes
it harder to write sensible generic code).

FWIW, even though I lean towards more consistency with other class types, I
have only personally found default-construction for captureless lambdas to
be desirable in my particular use-cases, and that's all that I personally
care for. Perhaps this is a more compelling example:

// Use a lambda as a stateless deleter function
std::unique_ptr<some_type, decltype([](some_type* ptr) {
some_deletion_function(ptr); })> object(create_some_type());

Of course, you can't use a lambda in an unevaluated context currently, nor
can one directly appear in a template argument, though there is/will be a
pre-Oulu proposal to allow these to take place (leaving in the originally
intended restriction that they do not appear in function declarations,
IIRC). Even without that proposal there are similar uses, though they are a
little less compelling since they aren't simple one-liners.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk2i97m%2BtRrTdJ4_sjq7xn8u7LRWLo0a6_HrUQhUw4KKg%40mail.gmail.com.

--001a114f6014d05e1f05339a54f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 9:39 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>Again. I cannot see how that =
motivates a need for default constructible lambdas.</div></div></div></div>=
</blockquote><div><br></div><div>It&#39;s never strictly a need, it&#39;s j=
ust a convenience.</div><div><br></div><div>It can also be argued that it i=
s consistent with user-defined class types for any lambda where a correspon=
ding type that had the capture types as datamembers would be a default cons=
tructible type (i.e. not for reference types, etc.), as was mentioned. I wo=
uld personally say that it makes more sense to start with what&#39;s consis=
tent with the rest of the language and only diverge from that if there is s=
ome kind of logical inconsistency. In other words, when adding a new featur=
e such as lambdas (a little late now, I know), the burden, IMO, should be o=
n *opponents* to argue why there should *not* be consistent rules with othe=
r types, as opposed to the proposal author needing to provide motivating ca=
ses for consistency. Language consistency should be a starting point becaus=
e when features differ, those are more differences that users need to know =
about, making the language harder to learn and intuit (and in practice, it =
usually makes it harder to write sensible generic code).</div><div><br></di=
v><div>FWIW, even though I lean towards more consistency with other class t=
ypes, I have only personally found default-construction for captureless lam=
bdas to be desirable in my particular use-cases, and that&#39;s all that I =
personally care for. Perhaps this is a more compelling example:</div><div><=
br></div><div>// Use a lambda as a stateless deleter function</div><div>std=
::unique_ptr&lt;some_type, decltype([](some_type* ptr) { some_deletion_func=
tion(ptr); })&gt; object(create_some_type());</div><div><br></div><div>Of c=
ourse, you can&#39;t use a lambda in an unevaluated context currently, nor =
can one directly appear in a template argument, though there is/will be a p=
re-Oulu proposal to allow these to take place (leaving in the originally in=
tended restriction that they do not appear in function declarations, IIRC).=
 Even without that proposal there are similar uses, though they are a littl=
e less compelling since they aren&#39;t simple one-liners.</div></div></div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEk2i97m%2BtRrTdJ4_sjq7xn8u7LRWL=
o0a6_HrUQhUw4KKg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk2i97m%2=
BtRrTdJ4_sjq7xn8u7LRWLo0a6_HrUQhUw4KKg%40mail.gmail.com</a>.<br />

--001a114f6014d05e1f05339a54f6--

.

--001a113f399a3d505005339a5b1e
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 7:23 PM, <jmonnon@aldebaran.com> wrote:

> The real motivation is to be able to manipulate lambdas as a Regular
values.

This is a very general statement. Just having default constructibility
won't do it. And unless you (or somebody else) make a consistent proposal
for lambdas as fully regular values, the value of default constructibility *per
se* is questionable. It may be that C++ will *never* have the other things
that make lambdas fully regular.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1dpj7Hnm-ksvsgDWrAjGGfWpkeE5A3unuQEx3pibnLpA%40mail.gmail.com.

--001a113f399a3d505005339a5b1e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 7:23 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jmonn=
on@aldebaran.com" target=3D"_blank">jmonnon@aldebaran.com</a>&gt;</span> wr=
ote:<br><div><br></div><div>&gt; The real motivation is to be able to manip=
ulate lambdas as a Regular values.</div><div><br></div><div>This is a very =
general statement. Just having default constructibility won&#39;t do it. An=
d unless you (or somebody else) make a consistent proposal for lambdas as f=
ully regular values, the value of default constructibility <i>per se</i>=C2=
=A0is questionable. It may be that C++ will <i>never</i>=C2=A0have the othe=
r things that make lambdas fully regular.</div><div><br></div><div>Cheers,<=
/div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1dpj7Hnm-ksvsgDWrAjGGfWpkeE5A3=
unuQEx3pibnLpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1dpj7Hnm-k=
svsgDWrAjGGfWpkeE5A3unuQEx3pibnLpA%40mail.gmail.com</a>.<br />

--001a113f399a3d505005339a5b1e--

.

--001a1140568acb175205339a7b59
Content-Type: text/plain; charset=UTF-8

On 24 May 2016 at 13:00, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via.usov@gmail.com>
> wrote:
>>
>>
>> FWIW, even though I lean towards more consistency with other class types,
> I have only personally found default-construction for captureless lambdas
> to be desirable in my particular use-cases, and that's all that I
> personally care for. Perhaps this is a more compelling example:
>
> // Use a lambda as a stateless deleter function
> std::unique_ptr<some_type, decltype([](some_type* ptr) {
> some_deletion_function(ptr); })> object(create_some_type());
>

Not particularly, as captureless lambdas are a different beast, because
there is no difference between a copy constructed one and a default
constructed one, as they have no state.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPuOaJVAhFemXvBW%3DxZxGa0%3DPXPeWwupzqaaF%2B8NNturQ%40mail.gmail.com.

--001a1140568acb175205339a7b59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 24 May 2016 at 13:00, &#39;Matt Calabrese&#39; via ISO =
C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std=
-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</=
span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D"">On Tue, May 24, 2016 at 9:39 AM, Via=
cheslav Usov <span dir=3D"ltr">&lt;<a href=3D"mailto:via.usov@gmail.com" ta=
rget=3D"_blank">via.usov@gmail.com</a>&gt;</span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div><br></div></div></div></div></blockquote></span><div>FWIW, e=
ven though I lean towards more consistency with other class types, I have o=
nly personally found default-construction for captureless lambdas to be des=
irable in my particular use-cases, and that&#39;s all that I personally car=
e for. Perhaps this is a more compelling example:</div><div><br></div><div>=
// Use a lambda as a stateless deleter function</div><div>std::unique_ptr&l=
t;some_type, decltype([](some_type* ptr) { some_deletion_function(ptr); })&=
gt; object(create_some_type());</div></div></div></div></blockquote><div><b=
r></div><div>Not particularly, as captureless lambdas are a different beast=
, because there is no difference between a copy constructed one and a defau=
lt constructed one, as they have no state.</div></div>-- <br><div class=3D"=
gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &q=
uot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404<=
/div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPuOaJVAhFemXvBW%3DxZxGa0%3DP=
XPeWwupzqaaF%2B8NNturQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
PuOaJVAhFemXvBW%3DxZxGa0%3DPXPeWwupzqaaF%2B8NNturQ%40mail.gmail.com</a>.<br=
 />

--001a1140568acb175205339a7b59--

.

--001a11c16e92b9283b05339a7eb1
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 10:55 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, May 24, 2016 at 1:23:50 PM UTC-4, jmo...@aldebaran.com wrote:
>>
>> The initial example is, well, just an example.
>> The real motivation is to be able to manipulate lambdas as a Regular
>> values.
>>
>
> I think the question you're missing is "why do you want to?"
>
> If you have a function which takes a function object to be called later,
> why would you want to manipulate such parameters "as a Regular values"?
>
> Functions are *not* regular values. While some callable types may fit the
> Regular concept, they do *not* fit the actual *semantics* behind that
> concept.
>

Not to get side-tracked, but function objects can indeed be Regular and
meet all of the semantic requirements of Regular types. This is often the
case. Function pointers are Regular as are many user-defined function
objects. Which are the semantic requirements that you claim function
objects cannot meet? operator() is no different from any other kind of
associated function of a concept and its existence as a requirement does
not have any kind of effect on the ability for a model to be Regular. If
this is unclear, just change the name of the associated function from
"operator()" to "foo". Would you say that a concept with an associated
function called "foo" cannot be Regular? Assuming you agree that such a
type can be Regular, why would simply naming the function "operator()"
instead of "foo" change anything?

That said, I think default construction as a requirement for Regular types
was a mistake anyway because it's not really a requirement for any
algorithms, it's just a convenience. Still it is often useful for
convenience.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dr30WfPaJOmOisdEStp2tf3sCs0qBwMh9ig9Kyxzpqfg%40mail.gmail.com.

--001a11c16e92b9283b05339a7eb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 10:55 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Tuesday, May 24, 2016 at 1:23:50 PM UTC-4, <a href=3D"mailto:jmo..=
..@aldebaran.com" target=3D"_blank">jmo...@aldebaran.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The initial example is, wel=
l, just an example.<div>The real motivation is to be able to manipulate lam=
bdas as a Regular values.</div></div></blockquote></span><div><br>I think t=
he question you&#39;re missing is &quot;why do you want to?&quot;<br><br>If=
 you have a function which takes a function object to be called later, why =
would you want to manipulate such parameters &quot;as a Regular values&quot=
;?</div><br>Functions are <i>not</i> regular values. While some callable ty=
pes may fit the Regular concept, they do <i>not</i> fit the actual <i>seman=
tics</i> behind that concept.<br></div></blockquote><div><br></div><div>Not=
 to get side-tracked, but function objects can indeed be Regular and meet a=
ll of the semantic requirements of Regular types. This is often the case. F=
unction pointers are Regular as are many user-defined function objects. Whi=
ch are the semantic requirements that you claim function objects cannot mee=
t? operator() is no different from any other kind of associated function of=
 a concept and its existence as a requirement does not have any kind of eff=
ect on the ability for a model to be Regular. If this is unclear, just chan=
ge the name of the associated function from &quot;operator()&quot; to &quot=
;foo&quot;. Would you say that a concept with an associated function called=
 &quot;foo&quot; cannot be Regular? Assuming you agree that such a type can=
 be Regular, why would simply naming the function &quot;operator()&quot; in=
stead of &quot;foo&quot; change anything?</div><div><br></div><div>That sai=
d, I think default construction as a requirement for Regular types was a mi=
stake anyway because it&#39;s not really a requirement for any algorithms, =
it&#39;s just a convenience. Still it is often useful for convenience.</div=
></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dr30WfPaJOmOisdEStp2tf3sCs0q=
BwMh9ig9Kyxzpqfg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dr30Wf=
PaJOmOisdEStp2tf3sCs0qBwMh9ig9Kyxzpqfg%40mail.gmail.com</a>.<br />

--001a11c16e92b9283b05339a7eb1--

.

--001a114267aa9e36af05339ac2c4
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 11:10 AM, Nevin Liber <nevin@eviloverlord.com>
wrote:

> On 24 May 2016 at 13:00, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>
>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via.usov@gmail.com>
>> wrote:
>>>
>>>
>>> FWIW, even though I lean towards more consistency with other class
>> types, I have only personally found default-construction for captureless
>> lambdas to be desirable in my particular use-cases, and that's all that I
>> personally care for. Perhaps this is a more compelling example:
>>
>> // Use a lambda as a stateless deleter function
>> std::unique_ptr<some_type, decltype([](some_type* ptr) {
>> some_deletion_function(ptr); })> object(create_some_type());
>>
>
> Not particularly, as captureless lambdas are a different beast, because
> there is no difference between a copy constructed one and a default
> constructed one, as they have no state.
>

I'm not sure what the "not particularly" is referring to here. Are you
saying that this is *not* a compelling example for default construction of
a lambda? I agree that stateless lambdas are different in that they don't
really raise any questions about whether or not the default-constructed
value is useful. I personally only really care about allowing
default-construction for captureless lambdas because those are the only
cases that I personally encounter. Other similar motivating examples for
default-constructible captureless lambdas are comparator functions for
associative containers, etc..

I was only talking more generally with respect to default-construction of
lambdas that have captures just on the principle that consistency should be
considered important by default whenever proposing new language features,
and that opponents should be the ones expected to have to argue *against*
consistency if it's somehow a problem. I understand that starting with
consistency is not an opinion that all people share, but it's useful to
realize that that is where some people are coming from in discussions like
this, which some people miss.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3De_r0Aij8q1d1OM5TsnSppXogKAMGAhSnLNOsMr9bABg%40mail.gmail.com.

--001a114267aa9e36af05339ac2c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 11:10 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
 class=3D"">On 24 May 2016 at 13:00, &#39;Matt Calabrese&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><span class=3D""><span>On Tue, May 24, 2016 at 9:39=
 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=3D"mailto:via.usov@gmail=
..com" target=3D"_blank">via.usov@gmail.com</a>&gt;</span> wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><br></div></div></div></div></blockquote></span></spa=
n><span class=3D""><div>FWIW, even though I lean towards more consistency w=
ith other class types, I have only personally found default-construction fo=
r captureless lambdas to be desirable in my particular use-cases, and that&=
#39;s all that I personally care for. Perhaps this is a more compelling exa=
mple:</div><div><br></div><div>// Use a lambda as a stateless deleter funct=
ion</div><div>std::unique_ptr&lt;some_type, decltype([](some_type* ptr) { s=
ome_deletion_function(ptr); })&gt; object(create_some_type());</div></span>=
</div></div></div></blockquote><div><br></div><div>Not particularly, as cap=
tureless lambdas are a different beast, because there is no difference betw=
een a copy constructed one and a default constructed one, as they have no s=
tate.</div></div></div></div></blockquote><div><br></div><div>I&#39;m not s=
ure what the &quot;not particularly&quot; is referring to here. Are you say=
ing that this is *not* a compelling example for default construction of a l=
ambda? I agree that stateless lambdas are different in that they don&#39;t =
really raise any questions about whether or not the default-constructed val=
ue is useful. I personally only really care about allowing default-construc=
tion for captureless lambdas because those are the only cases that I person=
ally encounter. Other similar motivating examples for default-constructible=
 captureless lambdas are comparator functions for associative containers, e=
tc..</div><div><br></div><div>I was only talking more generally with respec=
t to default-construction of lambdas that have captures just on the princip=
le that consistency should be considered important by default whenever prop=
osing new language features, and that opponents should be the ones expected=
 to have to argue *against* consistency if it&#39;s somehow a problem. I un=
derstand that starting with consistency is not an opinion that all people s=
hare, but it&#39;s useful to realize that that is where some people are com=
ing from in discussions like this, which some people miss.</div></div></div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3De_r0Aij8q1d1OM5TsnSppXogKAM=
GAhSnLNOsMr9bABg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3De_r0A=
ij8q1d1OM5TsnSppXogKAMGAhSnLNOsMr9bABg%40mail.gmail.com</a>.<br />

--001a114267aa9e36af05339ac2c4--

.

--001a113ff554cdbfab05339b1d30
Content-Type: text/plain; charset=UTF-8

>
> // Use a lambda as a stateless deleter function
>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {
>>> some_deletion_function(ptr); })> object(create_some_type());
>>>
>>
>> Not particularly, as captureless lambdas are a different beast, because
>> there is no difference between a copy constructed one and a default
>> constructed one, as they have no state.
>>
>
> I'm not sure what the "not particularly" is referring to here.
>

It doesn't address the capturing lambda case.


> Are you saying that this is *not* a compelling example for default
> construction of a lambda?
>

It's a decent use case, although you have to change other parts of the
language to make it work (you cannot have a lambda expression in an
unevaluated operand).

Most uses I've seen for unique_ptr tend to be as members of a class, but
putting a lambda in a header makes it way too easy for an accidental ODR
violation.  Other use cases, such as calling factory functions, are solved
by decltype and auto.


> I was only talking more generally with respect to default-construction of
> lambdas that have captures just on the principle that consistency should be
> considered important by default whenever proposing new language features,
> and that opponents should be the ones expected to have to argue *against*
> consistency if it's somehow a problem. I understand that starting with
> consistency is not an opinion that all people share, but it's useful to
> realize that that is where some people are coming from in discussions like
> this, which some people miss.
>

Whenever consistency is brought up, the obvious question is "consistency
with what?"  "Regular type" is not a concept in the standard.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP9%2BOn1enK3zK5JoqOeX94cugL9m-YBphc0q2QHfLQofA%40mail.gmail.com.

--001a113ff554cdbfab05339b1d30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><span><div>// Use a lambda as a stateless deleter functi=
on</div><div>std::unique_ptr&lt;some_type, decltype([](some_type* ptr) { so=
me_deletion_function(ptr); })&gt; object(create_some_type());</div></span><=
/div></div></div></blockquote><div><br></div><div>Not particularly, as capt=
ureless lambdas are a different beast, because there is no difference betwe=
en a copy constructed one and a default constructed one, as they have no st=
ate.</div></div></div></div></blockquote><div><br></div></span><div>I&#39;m=
 not sure what the &quot;not particularly&quot; is referring to here. </div=
></div></div></div></blockquote><div><br></div><div>It doesn&#39;t address =
the capturing lambda case.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>Are you saying that this is *not* a compelling example for default co=
nstruction of a lambda?</div></div></div></div></blockquote><div><br></div>=
<div>It&#39;s a decent use case, although you have to change other parts of=
 the language to make it work (you cannot have a lambda expression in an un=
evaluated operand).</div><div><br></div><div>Most uses I&#39;ve seen for un=
ique_ptr tend to be as members of a class, but putting a lambda in a header=
 makes it way too easy for an accidental ODR violation.=C2=A0 Other use cas=
es, such as calling factory functions, are solved by decltype and auto.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>I was only talking more =
generally with respect to default-construction of lambdas that have capture=
s just on the principle that consistency should be considered important by =
default whenever proposing new language features, and that opponents should=
 be the ones expected to have to argue *against* consistency if it&#39;s so=
mehow a problem. I understand that starting with consistency is not an opin=
ion that all people share, but it&#39;s useful to realize that that is wher=
e some people are coming from in discussions like this, which some people m=
iss.<br></div></div></div></div></blockquote><div><br></div><div>Whenever c=
onsistency is brought up, the obvious question is &quot;consistency with wh=
at?&quot; =C2=A0&quot;Regular type&quot; is not a concept in the standard.<=
/div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div=
 dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hre=
f=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.co=
m</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP9%2BOn1enK3zK5JoqOeX94cugL9=
m-YBphc0q2QHfLQofA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP9%2=
BOn1enK3zK5JoqOeX94cugL9m-YBphc0q2QHfLQofA%40mail.gmail.com</a>.<br />

--001a113ff554cdbfab05339b1d30--

.

------=_Part_7966_1032530083.1464132702774
Content-Type: multipart/alternative;
 boundary="----=_Part_7967_467480184.1464132702774"

------=_Part_7967_467480184.1464132702774
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>
> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com=20
> <javascript:>> wrote:
>>
>> Again. I cannot see how that motivates a need for default constructible=
=20
>> lambdas.
>>
>
> It's never strictly a need, it's just a convenience.
> [...]
> FWIW, even though I lean towards more consistency with other class types,=
=20
> I have only personally found default-construction for captureless lambdas=
=20
> to be desirable in my particular use-cases, and that's all that I=20
> personally care for. Perhaps this is a more compelling example:
>
> // Use a lambda as a stateless deleter function
> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
> some_deletion_function(ptr); })> object(create_some_type());
>

This is a use-case I have also encountered in the wild. I would very much=
=20
like this (lambdas in unevaluated contexts, default-construction of=20
captureless closure types) to Just Work.

Default-construction of *captureful* close types seems 100% dangerous and=
=20
bad.

    int main() {
        int y =3D 42;
        auto x =3D [z=3Dy](){ printf("%d\n", z); };
        decltype(x) x2;
        x2();  // does this print the "value" of a default-initialized int?=
=20
that's super dangerous!
    }

We definitely shouldn't provide the user-programmer with any constructs=20
that allow him to shoot himself in the foot this badly, especially when=20
there's no motivating use-case for the feature.

I would say that there's one minorly thought-provoking corner case in=20
between "captureless" and "captureful":

    int main() {
        auto x =3D [z=3D42](){ printf("%d\n", z); };
        decltype(x) x2;  // ought this to compile?
        x2();  // ought this to print 42?
    }

My opinion is that "no, it certainly oughtn't to print 42", based on my=20
(correct?) belief that the meaning of [z=3DFOO] is not altered in any way b=
y=20
whether or not FOO is a constant-expression. In my ideal world, the above=
=20
code would *refuse to compile*, because decltype(x) is quite definitely a=
=20
*captureful* closure type.

Captureless closure types are already semantically more featureful than=20
captureful closure types; namely, they provide an implicit conversion to=20
function-pointer type. Providing a default constructor for captureless=20
closure types would be logically in keeping with that existing behavior,=20
IMO.

I see that existing behavior of captureless closure types as basically=20
analogous to the way each new C++ standard adds new accessors to=20
std::true_type:
- ::value
- default constructor + operator bool
- default constructor + operator()
It's convenient to be able to use std::true_type as if it "means" true,=20
even though technically they're different things.

For captureless closure types, we're only at the start of that journey. So=
=20
far we've added only
- operator <function-type>
but I think it makes sense to add
- default constructor
as well. This will enable user-programmers to more conveniently use=20
captureless closure types as if they "mean" functions, even though=20
technically they're different things.

=E2=80=93Arthur

>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e0838864-bcaf-4bc6-84c6-fa0cd1f3ee3f%40isocpp.or=
g.

------=_Part_7967_467480184.1464132702774
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabr=
ese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Tue, May 24, 2016 at 9:39 AM, Viacheslav Us=
ov <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"F8qYHAspDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">via....@gmail.com</a>&gt;</span> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Again.=
 I cannot see how that motivates a need for default constructible lambdas.<=
/div></div></div></div></blockquote><div><br></div><div>It&#39;s never stri=
ctly a need, it&#39;s just a convenience.</div><div>[...]</div><div>FWIW, e=
ven though I lean towards more consistency with other class types, I have o=
nly personally found default-construction for captureless lambdas to be des=
irable in my particular use-cases, and that&#39;s all that I personally car=
e for. Perhaps this is a more compelling example:</div><div><br></div><div>=
// Use a lambda as a stateless deleter function</div><div>std::unique_ptr&l=
t;some_type, decltype([](some_type* ptr) { some_deletion_function(ptr); })&=
gt; object(create_some_type());</div></div></div></div></blockquote><div><b=
r></div><div>This is a use-case I have also encountered in the wild. I woul=
d very much like this (lambdas in unevaluated contexts, default-constructio=
n of captureless closure types) to Just Work.</div><div><br></div><div>Defa=
ult-construction of <b><i>captureful</i></b> close types seems 100% dangero=
us and bad.</div><div><br></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 int main() {</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3Dy]=
(){ printf(&quot;%d\n&quot;, z); };</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =
=C2=A0// does this print the &quot;value&quot; of a default-initialized int=
? that&#39;s super dangerous!</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 }</font></div><div><br></div><div>We definitely sho=
uldn&#39;t provide the user-programmer with any constructs that allow him t=
o shoot himself in the foot this badly, especially when there&#39;s no moti=
vating use-case for the feature.</div><div><br></div><div>I would say that =
there&#39;s one minorly thought-provoking corner case in between &quot;capt=
ureless&quot; and &quot;captureful&quot;:</div><div><br></div><div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 int main() {</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto =
x =3D [z=3D42](){ printf(&quot;%d\n&quot;, z); };<br></font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x=
2; =C2=A0// ought this to compile?</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// ought this to pri=
nt 42?</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
 }</font></div></div><div><br></div><div>My opinion is that &quot;no, it ce=
rtainly oughtn&#39;t to print 42&quot;, based on my (correct?) belief that =
the meaning of <font face=3D"courier new, monospace">[z=3DFOO]</font> is no=
t altered in any way by whether or not <font face=3D"courier new, monospace=
">FOO</font> is a constant-expression. In my ideal world, the above code wo=
uld <i><b>refuse to compile</b></i>, because <font face=3D"courier new, mon=
ospace">decltype(x)</font> is quite definitely a <i><b>captureful</b></i> c=
losure type.</div><div><br></div><div><div>Captureless closure types are al=
ready semantically more featureful than captureful closure types; namely, t=
hey provide an implicit conversion to function-pointer type. Providing a de=
fault constructor for captureless closure types would be logically in keepi=
ng with that existing behavior, IMO.</div><div><br></div><div>I see that ex=
isting behavior of captureless closure types as basically analogous to the =
way each new C++ standard adds new accessors to std::true_type:</div></div>=
<div>- ::value</div><div>- default constructor + operator bool</div><div>- =
default constructor + operator()</div><div>It&#39;s convenient to be able t=
o use <font face=3D"courier new, monospace">std::true_type</font> as if it =
&quot;means&quot; <font face=3D"courier new, monospace">true</font>, even t=
hough technically they&#39;re different things.</div><div><br></div><div>Fo=
r captureless closure types, we&#39;re only at the start of that journey. S=
o far we&#39;ve added only</div><div>- operator &lt;function-type&gt;</div>=
<div>but I think it makes sense to add</div><div>- default constructor</div=
><div>as well. This will enable user-programmers to more conveniently use c=
aptureless closure types as if they &quot;mean&quot; functions, even though=
 technically they&#39;re different things.</div><div><br></div><div>=E2=80=
=93Arthur</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0838864-bcaf-4bc6-84c6-fa0cd1f3ee3f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e0838864-bcaf-4bc6-84c6-fa0cd1f3ee3f=
%40isocpp.org</a>.<br />

------=_Part_7967_467480184.1464132702774--

------=_Part_7966_1032530083.1464132702774--

.

------=_Part_3733_427019205.1464134533211
Content-Type: multipart/alternative;
 boundary="----=_Part_3734_617686419.1464134533211"

------=_Part_3734_617686419.1464134533211
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 24, 2016 at 7:31:42 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>
>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=20
>> wrote:
>>>
>>> Again. I cannot see how that motivates a need for default constructible=
=20
>>> lambdas.
>>>
>>
>> It's never strictly a need, it's just a convenience.
>> [...]
>> FWIW, even though I lean towards more consistency with other class types=
,=20
>> I have only personally found default-construction for captureless lambda=
s=20
>> to be desirable in my particular use-cases, and that's all that I=20
>> personally care for. Perhaps this is a more compelling example:
>>
>> // Use a lambda as a stateless deleter function
>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>> some_deletion_function(ptr); })> object(create_some_type());
>>
>
> This is a use-case I have also encountered in the wild. I would very much=
=20
> like this (lambdas in unevaluated contexts, default-construction of=20
> captureless closure types) to Just Work.
>
> Default-construction of *captureful* close types seems 100% dangerous and=
=20
> bad.
>
>     int main() {
>         int y =3D 42;
>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>         decltype(x) x2;
>         x2();  // does this print the "value" of a default-initialized=20
> int? that's super dangerous!
>     }
>
> We definitely shouldn't provide the user-programmer with any constructs=
=20
> that allow him to shoot himself in the foot this badly, especially when=
=20
> there's no motivating use-case for the feature.
>
> I would say that there's one minorly thought-provoking corner case in=20
> between "captureless" and "captureful":
>
>     int main() {
>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>         decltype(x) x2;  // ought this to compile?
>         x2();  // ought this to print 42?
>     }
>
> My opinion is that "no, it certainly oughtn't to print 42", based on my=
=20
> (correct?) belief that the meaning of [z=3DFOO] is not altered in any way=
=20
> by whether or not FOO is a constant-expression. In my ideal world, the=20
> above code would *refuse to compile*, because decltype(x) is quite=20
> definitely a *captureful* closure type.
>
> Captureless closure types are already semantically more featureful than=
=20
> captureful closure types; namely, they provide an implicit conversion to=
=20
> function-pointer type. Providing a default constructor for captureless=20
> closure types would be logically in keeping with that existing behavior,=
=20
> IMO.
>
> I see that existing behavior of captureless closure types as basically=20
> analogous to the way each new C++ standard adds new accessors to=20
> std::true_type:
> - ::value
> - default constructor + operator bool
> - default constructor + operator()
> It's convenient to be able to use std::true_type as if it "means" true,=
=20
> even though technically they're different things.
>
> For captureless closure types, we're only at the start of that journey. S=
o=20
> far we've added only
> - operator <function-type>
> but I think it makes sense to add
> - default constructor
> as well. This will enable user-programmers to more conveniently use=20
> captureless closure types as if they "mean" functions, even though=20
> technically they're different things.
>
> =E2=80=93Arthur
>

That all sounds very reasonable. I particularly like not trying to create a=
=20
third class of lambdas which capture constants rather than external=20
variables.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f89430ce-17a7-4efe-b604-38776cc6d0a0%40isocpp.or=
g.

------=_Part_3734_617686419.1464134533211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 24, 2016 at 7:31:42 PM UTC-4, Arthur O&#39=
;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote">On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">via....@gmail.com</a>&gt;</span> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Aga=
in. I cannot see how that motivates a need for default constructible lambda=
s.</div></div></div></div></blockquote><div><br></div><div>It&#39;s never s=
trictly a need, it&#39;s just a convenience.</div><div>[...]</div><div>FWIW=
, even though I lean towards more consistency with other class types, I hav=
e only personally found default-construction for captureless lambdas to be =
desirable in my particular use-cases, and that&#39;s all that I personally =
care for. Perhaps this is a more compelling example:</div><div><br></div><d=
iv>// Use a lambda as a stateless deleter function</div><div>std::unique_pt=
r&lt;some_type, decltype([](some_type* ptr) { some_deletion_function(ptr); =
})&gt; object(create_some_type());</div></div></div></div></blockquote><div=
><br></div><div>This is a use-case I have also encountered in the wild. I w=
ould very much like this (lambdas in unevaluated contexts, default-construc=
tion of captureless closure types) to Just Work.</div><div><br></div><div>D=
efault-construction of <b><i>captureful</i></b> close types seems 100% dang=
erous and bad.</div><div><br></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 int main() {</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=
=3Dy](){ printf(&quot;%d\n&quot;, z); };</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2=
(); =C2=A0// does this print the &quot;value&quot; of a default-initialized=
 int? that&#39;s super dangerous!</font></div><div><font face=3D"courier ne=
w, monospace">=C2=A0 =C2=A0 }</font></div><div><br></div><div>We definitely=
 shouldn&#39;t provide the user-programmer with any constructs that allow h=
im to shoot himself in the foot this badly, especially when there&#39;s no =
motivating use-case for the feature.</div><div><br></div><div>I would say t=
hat there&#39;s one minorly thought-provoking corner case in between &quot;=
captureless&quot; and &quot;captureful&quot;:</div><div><br></div><div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int main() {</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=
uto x =3D [z=3D42](){ printf(&quot;%d\n&quot;, z); };<br></font></div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(=
x) x2; =C2=A0// ought this to compile?</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// ought this to=
 print 42?</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 }</font></div></div><div><br></div><div>My opinion is that &quot;no,=
 it certainly oughtn&#39;t to print 42&quot;, based on my (correct?) belief=
 that the meaning of <font face=3D"courier new, monospace">[z=3DFOO]</font>=
 is not altered in any way by whether or not <font face=3D"courier new, mon=
ospace">FOO</font> is a constant-expression. In my ideal world, the above c=
ode would <i><b>refuse to compile</b></i>, because <font face=3D"courier ne=
w, monospace">decltype(x)</font> is quite definitely a <i><b>captureful</b>=
</i> closure type.</div><div><br></div><div><div>Captureless closure types =
are already semantically more featureful than captureful closure types; nam=
ely, they provide an implicit conversion to function-pointer type. Providin=
g a default constructor for captureless closure types would be logically in=
 keeping with that existing behavior, IMO.</div><div><br></div><div>I see t=
hat existing behavior of captureless closure types as basically analogous t=
o the way each new C++ standard adds new accessors to std::true_type:</div>=
</div><div>- ::value</div><div>- default constructor + operator bool</div><=
div>- default constructor + operator()</div><div>It&#39;s convenient to be =
able to use <font face=3D"courier new, monospace">std::true_type</font> as =
if it &quot;means&quot; <font face=3D"courier new, monospace">true</font>, =
even though technically they&#39;re different things.</div><div><br></div><=
div>For captureless closure types, we&#39;re only at the start of that jour=
ney. So far we&#39;ve added only</div><div>- operator &lt;function-type&gt;=
</div><div>but I think it makes sense to add</div><div>- default constructo=
r</div><div>as well. This will enable user-programmers to more conveniently=
 use captureless closure types as if they &quot;mean&quot; functions, even =
though technically they&#39;re different things.</div><div><br></div><div>=
=E2=80=93Arthur</div></div></blockquote><div><br>That all sounds very reaso=
nable. I particularly like not trying to create a third class of lambdas wh=
ich capture constants rather than external variables.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f89430ce-17a7-4efe-b604-38776cc6d0a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f89430ce-17a7-4efe-b604-38776cc6d0a0=
%40isocpp.org</a>.<br />

------=_Part_3734_617686419.1464134533211--

------=_Part_3733_427019205.1464134533211--

.

--001a113f29a812e4ec0533a0abbd
Content-Type: text/plain; charset=UTF-8

On 24 May 2016 at 18:31, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

> This is a use-case I have also encountered in the wild. I would very much
> like this (lambdas in unevaluated contexts, default-construction of
> captureless closure types) to Just Work.
>

Then how do you prevent:

#ifndef HEADER_H_
#define HEADER_H_

struct A
{
    std::unique_ptr<B, decltype([](auto* p){delete_delete_delete(p);})> u;
    std::set<C, decltype([](auto const&l, auto const& r){return l > r;})> s;
}

#endif /* HEADER_H_ */

from being an accidental ODR violation when someone includes this in two
translation units?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPWQaigKT2RejJ%3DWENs5-cCwYHqSNRkNfqz0YqRU%3DRyog%40mail.gmail.com.

--001a113f29a812e4ec0533a0abbd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 24 May 2016 at 18:31, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This is=
 a use-case I have also encountered in the wild. I would very much like thi=
s (lambdas in unevaluated contexts, default-construction of captureless clo=
sure types) to Just Work.</div><div></div></blockquote></div><br>Then how d=
o you prevent:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">#ifndef HEADER_H_</div><div class=3D"gmail_extra">#define HEADER_H=
_</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">stru=
ct A</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=C2=
=A0 =C2=A0 std::unique_ptr&lt;B, decltype([](auto* p){delete_delete_delete(=
p);})&gt; u;</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 std::set&lt;C, d=
ecltype([](auto const&amp;l, auto const&amp; r){return l &gt; r;})&gt; s;</=
div><div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">#endif /* HEADER_H_ */</div><div class=3D"gmail_=
extra"><br clear=3D"all"><div>from being an accidental ODR violation when s=
omeone includes this in two translation units?</div>-- <br><div class=3D"gm=
ail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quo=
t;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</d=
iv></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPWQaigKT2RejJ%3DWENs5-cCwYHq=
SNRkNfqz0YqRU%3DRyog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPW=
QaigKT2RejJ%3DWENs5-cCwYHqSNRkNfqz0YqRU%3DRyog%40mail.gmail.com</a>.<br />

--001a113f29a812e4ec0533a0abbd--

.

This is a multi-part message in MIME format.
--------------85AC63ACCBDB49C974FDA79D
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 25.05.2016 um 03:33 schrieb Nevin Liber:
>
> On 24 May 2016 at 18:31, Arthur O'Dwyer <arthur.j.odwyer@gmail.com
> <mailto:arthur.j.odwyer@gmail.com>> wrote:
>
>     This is a use-case I have also encountered in the wild. I would
>     very much like this (lambdas in unevaluated contexts,
>     default-construction of captureless closure types) to Just Work.
>
>
> Then how do you prevent:
>
> #ifndef HEADER_H_
> #define HEADER_H_
>
> struct A
> {
>     std::unique_ptr<B, decltype([](auto* p){delete_delete_delete(p);})> u;
>     std::set<C, decltype([](auto const&l, auto const& r){return l >
> r;})> s;
> }
>
> #endif /* HEADER_H_ */
>
> from being an accidental ODR violation when someone includes this in
> two translation units?
Clang uses file:line:column of the place of definition to distinguish
closure types regardless of translation unit. I see no reason why your
example should cause an ODR violation. It's just a matter of specifying
in the standard whether it should be one or not so it's not
implementation dependent.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ab7e1ab2-1558-23e6-8315-aff8d48dcc4e%40gmail.com.

--------------85AC63ACCBDB49C974FDA79D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 25.05.2016 um 03:33 schrieb Nevin Liber:<br>
    <blockquote
cite=3D"mid:CAGg_6+PWQaigKT2RejJ=3DWENs5-cCwYHqSNRkNfqz0YqRU=3DRyog@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On 24 May 2016 at 18:31, Arthur
            O'Dwyer <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank"=
>arthur.j.odwyer@gmail.com</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>This is a use-case I have also encountered in the
                wild. I would very much like this (lambdas in
                unevaluated contexts, default-construction of
                captureless closure types) to Just Work.</div>
            </blockquote>
          </div>
          <br>
          Then how do you prevent:</div>
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">#ifndef HEADER_H_</div>
        <div class=3D"gmail_extra">#define HEADER_H_</div>
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">struct A</div>
        <div class=3D"gmail_extra">{</div>
        <div class=3D"gmail_extra">=C2=A0 =C2=A0 std::unique_ptr&lt;B,
          decltype([](auto* p){delete_delete_delete(p);})&gt; u;</div>
        <div class=3D"gmail_extra">=C2=A0 =C2=A0 std::set&lt;C, decltype([]=
(auto
          const&amp;l, auto const&amp; r){return l &gt; r;})&gt; s;</div>
        <div class=3D"gmail_extra">}</div>
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">#endif /* HEADER_H_ */</div>
        <div class=3D"gmail_extra"><br clear=3D"all">
          <div>from being an accidental ODR violation when someone
            includes this in two translation units?</div>
        </div>
      </div>
    </blockquote>
    Clang uses <a class=3D"moz-txt-link-freetext" href=3D"file:line:column"=
>file:line:column</a> of the place of definition to
    distinguish closure types regardless of translation unit. I see no
    reason why your example should cause an ODR violation. It's just a
    matter of specifying in the standard whether it should be one or not
    so it's not implementation dependent.<br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab7e1ab2-1558-23e6-8315-aff8d48dcc4e%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab7e1ab2-1558-23e6-8315-aff8d48dcc4e%=
40gmail.com</a>.<br />

--------------85AC63ACCBDB49C974FDA79D--

.

--94eb2c06fad609287d0533a55a03
Content-Type: text/plain; charset=UTF-8

On 24 May 2016 7:23 p.m., "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Am 25.05.2016 um 03:33 schrieb Nevin Liber:
>>
>>
>> On 24 May 2016 at 18:31, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
>>>
>>> This is a use-case I have also encountered in the wild. I would very
much like this (lambdas in unevaluated contexts, default-construction of
captureless closure types) to Just Work.
>>
>>
>> Then how do you prevent:
>>
>> #ifndef HEADER_H_
>> #define HEADER_H_
>>
>> struct A
>> {
>>     std::unique_ptr<B, decltype([](auto* p){delete_delete_delete(p);})>
u;
>>     std::set<C, decltype([](auto const&l, auto const& r){return l >
r;})> s;
>> }
>>
>> #endif /* HEADER_H_ */
>>
>> from being an accidental ODR violation when someone includes this in two
translation units?
>
> Clang uses file:line:column of the place of definition to distinguish
closure types regardless of translation unit.

Well, actually, clang uses the mangling system for the target (typically
the vendor-neutral Itanium C++ ABI) to give the closure type the same name
across translation units; typically this involves sequentially numbering
the lambdas in each context where they can appear. (File:line:column would
not be correct since that is not required to be the same in each such
definition -- think about compiling preprocessed source for a practical
case where this happens.)

> I see no reason why your example should cause an ODR violation. It's just
a matter of specifying in the standard whether it should be one or not so
it's not implementation dependent.

The standard is already clear that it would not be: under the terms of the
odr, since you used the same token sequence to write the class definition
(and met the side conditions for lookup results), the implementation is
required to make your program act as if there is only one definition of the
class, that is merely somehow visible from multiple translation units at
once.

> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ab7e1ab2-1558-23e6-8315-aff8d48dcc4e%40gmail.com
..

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqncfPKn9ekLWVH5uyB6y_iqBMt5f1EtQ7A4BT8equrhTw%40mail.gmail.com.

--94eb2c06fad609287d0533a55a03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 24 May 2016 7:23 p.m., &quot;Miro Knejp&quot; &lt;<a href=
=3D"mailto:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Am 25.05.2016 um 03:33 schrieb Nevin Liber:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 24 May 2016 at 18:31, Arthur O&#39;Dwyer &lt;<a href=3D"mailto:=
arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This is a use-case I have also encountered in the wild. I woul=
d very much like this (lambdas in unevaluated contexts, default-constructio=
n of captureless closure types) to Just Work.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Then how do you prevent:<br>
&gt;&gt;<br>
&gt;&gt; #ifndef HEADER_H_<br>
&gt;&gt; #define HEADER_H_<br>
&gt;&gt;<br>
&gt;&gt; struct A<br>
&gt;&gt; {<br>
&gt;&gt; =C2=A0 =C2=A0 std::unique_ptr&lt;B, decltype([](auto* p){delete_de=
lete_delete(p);})&gt; u;<br>
&gt;&gt; =C2=A0 =C2=A0 std::set&lt;C, decltype([](auto const&amp;l, auto co=
nst&amp; r){return l &gt; r;})&gt; s;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; #endif /* HEADER_H_ */<br>
&gt;&gt;<br>
&gt;&gt; from being an accidental ODR violation when someone includes this =
in two translation units?<br>
&gt;<br>
&gt; Clang uses file:line:column of the place of definition to distinguish =
closure types regardless of translation unit.</p>
<p dir=3D"ltr">Well, actually, clang uses the mangling system for the targe=
t (typically the vendor-neutral Itanium C++ ABI) to give the closure type t=
he same name across translation units; typically this involves sequentially=
 numbering the lambdas in each context where they can appear. (File:line:co=
lumn would not be correct since that is not required to be the same in each=
 such definition -- think about compiling preprocessed source for a practic=
al case where this happens.)</p>
<p dir=3D"ltr">&gt; I see no reason why your example should cause an ODR vi=
olation. It&#39;s just a matter of specifying in the standard whether it sh=
ould be one or not so it&#39;s not implementation dependent.</p>
<p dir=3D"ltr">The standard is already clear that it would not be: under th=
e terms of the odr, since you used the same token sequence to write the cla=
ss definition (and met the side conditions for lookup results), the impleme=
ntation is required to make your program act as if there is only one defini=
tion of the class, that is merely somehow visible from multiple translation=
 units at once.</p>
<p dir=3D"ltr">&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/ab7e1ab2-1558-23e6-8315-aff8d48d=
cc4e%40gmail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/ab7e1ab2-1558-23e6-8315-aff8d48dcc4e%40gmail.com</a>.<br>
</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqncfPKn9ekLWVH5uyB6y_iqBMt5f1Et=
Q7A4BT8equrhTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqncfPKn9ekL=
WVH5uyB6y_iqBMt5f1EtQ7A4BT8equrhTw%40mail.gmail.com</a>.<br />

--94eb2c06fad609287d0533a55a03--

.

------=_Part_6734_189756750.1464167429081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>
> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>
>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=20
>> wrote:
>>>
>>> Again. I cannot see how that motivates a need for default constructible=
=20
>>> lambdas.
>>>
>>
>> It's never strictly a need, it's just a convenience.
>> [...]
>> FWIW, even though I lean towards more consistency with other class types=
,=20
>> I have only personally found default-construction for captureless lambda=
s=20
>> to be desirable in my particular use-cases, and that's all that I=20
>> personally care for. Perhaps this is a more compelling example:
>>
>> // Use a lambda as a stateless deleter function
>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>> some_deletion_function(ptr); })> object(create_some_type());
>>
>
> This is a use-case I have also encountered in the wild. I would very much=
=20
> like this (lambdas in unevaluated contexts, default-construction of=20
> captureless closure types) to Just Work.
>
> Default-construction of *captureful* close types seems 100% dangerous and=
=20
> bad.
>
>     int main() {
>         int y =3D 42;
>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>         decltype(x) x2;
>         x2();  // does this print the "value" of a default-initialized=20
> int? that's super dangerous!
>     }
>
> We definitely shouldn't provide the user-programmer with any constructs=
=20
> that allow him to shoot himself in the foot this badly, especially when=
=20
> there's no motivating use-case for the feature.
>

See above for motivating examples.
=20

>
> I would say that there's one minorly thought-provoking corner case in=20
> between "captureless" and "captureful":
>
>     int main() {
>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>         decltype(x) x2;  // ought this to compile?
>         x2();  // ought this to print 42?
>     }
>
> My opinion is that "no, it certainly oughtn't to print 42", based on my=
=20
> (correct?) belief that the meaning of [z=3DFOO] is not altered in any way=
=20
> by whether or not FOO is a constant-expression. In my ideal world, the=20
> above code would *refuse to compile*, because decltype(x) is quite=20
> definitely a *captureful* closure type.
>
> =20
As explained above, the default constructor of the lambda should rely on=20
the default constructor of its members (same as a user-defined type). Thus,=
=20
the value of a default-constructed lambda would be meaningful depending of=
=20
the meaningfulness of the values of its default-constructed members.
For example, imagine a lambda capturing a std::string, the default=20
construction of the type of this lambda should default-constructs its=20
std::string member, which has a meaningful value (the empty string).
Therefore, the value of this default-constructed lambda type is meaningful.

For a lambda capturing an int :
decltype(my_lambda_capturing_an_int) x; // the int member's value is=20
undefined (members are default-constructed without empty braces)
decltype(my_lambda_capturing_an_int) x{}; // the int member's value is 0=20
(members are default-constructed with empty braces)

(though I don't remember if a type default-constructed with empty braces=20
will recursively default-construct its members with empty braces).

This way, default-construction of a lambda type is consistent with=20
user-defined types.
=20

> Captureless closure types are already semantically more featureful than=
=20
> captureful closure types; namely, they provide an implicit conversion to=
=20
> function-pointer type. Providing a default constructor for captureless=20
> closure types would be logically in keeping with that existing behavior,=
=20
> IMO.
>
> I see that existing behavior of captureless closure types as basically=20
> analogous to the way each new C++ standard adds new accessors to=20
> std::true_type:
> - ::value
> - default constructor + operator bool
> - default constructor + operator()
> It's convenient to be able to use std::true_type as if it "means" true,=
=20
> even though technically they're different things.
>
> For captureless closure types, we're only at the start of that journey. S=
o=20
> far we've added only
> - operator <function-type>
> but I think it makes sense to add
> - default constructor
> as well. This will enable user-programmers to more conveniently use=20
> captureless closure types as if they "mean" functions, even though=20
> technically they're different things.
>
> =E2=80=93Arthur
>
>>
--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4b453658-5a0f-466e-80f1-6b7312e5bee6%40isocpp.or=
g.

------=_Part_6734_189756750.1464167429081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O&#=
39;Dwyer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabres=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote">On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <spa=
n dir=3D"ltr">&lt;<a rel=3D"nofollow">via....@gmail.com</a>&gt;</span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div>Again. I cannot see how that motivates a need for default const=
ructible lambdas.</div></div></div></div></blockquote><div><br></div><div>I=
t&#39;s never strictly a need, it&#39;s just a convenience.</div><div>[...]=
</div><div>FWIW, even though I lean towards more consistency with other cla=
ss types, I have only personally found default-construction for captureless=
 lambdas to be desirable in my particular use-cases, and that&#39;s all tha=
t I personally care for. Perhaps this is a more compelling example:</div><d=
iv><br></div><div>// Use a lambda as a stateless deleter function</div><div=
>std::unique_ptr&lt;some_type, decltype([](some_type* ptr) { some_deletion_=
function(ptr); })&gt; object(create_some_type());</div></div></div></div></=
blockquote><div><br></div><div>This is a use-case I have also encountered i=
n the wild. I would very much like this (lambdas in unevaluated contexts, d=
efault-construction of captureless closure types) to Just Work.</div><div><=
br></div><div>Default-construction of <b><i>captureful</i></b> close types =
seems 100% dangerous and bad.</div><div><br></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 int main() {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
auto x =3D [z=3Dy](){ printf(&quot;%d\n&quot;, z); };</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x=
2;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 x2(); =C2=A0// does this print the &quot;value&quot; of a defaul=
t-initialized int? that&#39;s super dangerous!</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div><div><br></div><div=
>We definitely shouldn&#39;t provide the user-programmer with any construct=
s that allow him to shoot himself in the foot this badly, especially when t=
here&#39;s no motivating use-case for the feature.</div></div></blockquote>=
<div><br></div><div>See above for motivating examples.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></=
div><div>I would say that there&#39;s one minorly thought-provoking corner =
case in between &quot;captureless&quot; and &quot;captureful&quot;:</div><d=
iv><br></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
int main() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3D42](){ printf(&quot;%d\n&quot;, z); };=
<br></font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 decltype(x) x2; =C2=A0// ought this to compile?</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2();=
 =C2=A0// ought this to print 42?</font></div><div><font face=3D"courier ne=
w, monospace">=C2=A0 =C2=A0 }</font></div></div><div><br></div><div>My opin=
ion is that &quot;no, it certainly oughtn&#39;t to print 42&quot;, based on=
 my (correct?) belief that the meaning of <font face=3D"courier new, monosp=
ace">[z=3DFOO]</font> is not altered in any way by whether or not <font fac=
e=3D"courier new, monospace">FOO</font> is a constant-expression. In my ide=
al world, the above code would <i><b>refuse to compile</b></i>, because <fo=
nt face=3D"courier new, monospace">decltype(x)</font> is quite definitely a=
 <i><b>captureful</b></i> closure type.</div><div><br></div></div></blockqu=
ote><div>=C2=A0</div><div>As explained above, the default constructor of th=
e lambda should rely on the default constructor of its members (same as a u=
ser-defined type). Thus, the value of a default-constructed lambda would be=
 meaningful depending of the meaningfulness of the values of its default-co=
nstructed members.</div><div>For example, imagine a lambda capturing a std:=
:string, the default construction of the type of this lambda should default=
-constructs its std::string member, which has a meaningful value (the empty=
 string).</div><div>Therefore, the value of this default-constructed lambda=
 type is meaningful.</div><div><br></div><div>For a lambda capturing an int=
 :</div><div>decltype(my_lambda_capturing_an_int) x; // the int member&#39;=
s value is undefined (members are default-constructed without empty braces)=
</div><div>decltype(my_lambda_capturing_an_int) x{}; // the int member&#39;=
s value is 0 (members are default-constructed with empty braces)<br></div><=
div><br></div><div>(though I don&#39;t remember if a type default-construct=
ed with empty braces will recursively default-construct its members with em=
pty braces).</div><div><br></div><div>This way, default-construction of a l=
ambda type is consistent with user-defined types.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>=
<div>Captureless closure types are already semantically more featureful tha=
n captureful closure types; namely, they provide an implicit conversion to =
function-pointer type. Providing a default constructor for captureless clos=
ure types would be logically in keeping with that existing behavior, IMO.</=
div><div><br></div><div>I see that existing behavior of captureless closure=
 types as basically analogous to the way each new C++ standard adds new acc=
essors to std::true_type:</div></div><div>- ::value</div><div>- default con=
structor + operator bool</div><div>- default constructor + operator()</div>=
<div>It&#39;s convenient to be able to use <font face=3D"courier new, monos=
pace">std::true_type</font> as if it &quot;means&quot; <font face=3D"courie=
r new, monospace">true</font>, even though technically they&#39;re differen=
t things.</div><div><br></div><div>For captureless closure types, we&#39;re=
 only at the start of that journey. So far we&#39;ve added only</div><div>-=
 operator &lt;function-type&gt;</div><div>but I think it makes sense to add=
</div><div>- default constructor</div><div>as well. This will enable user-p=
rogrammers to more conveniently use captureless closure types as if they &q=
uot;mean&quot; functions, even though technically they&#39;re different thi=
ngs.</div><div><br></div><div>=E2=80=93Arthur</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
</blockquote></div></blockquote></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4b453658-5a0f-466e-80f1-6b7312e5bee6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4b453658-5a0f-466e-80f1-6b7312e5bee6=
%40isocpp.org</a>.<br />

------=_Part_6734_189756750.1464167429081--

.

------=_Part_3469_645203739.1464171590366
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le mercredi 25 mai 2016 11:10:29 UTC+2, jmo...@aldebaran.com a =C3=A9crit :
>
>
>
> Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>>
>> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>>
>>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=20
>>> wrote:
>>>>
>>>> Again. I cannot see how that motivates a need for default constructibl=
e=20
>>>> lambdas.
>>>>
>>>
>>> It's never strictly a need, it's just a convenience.
>>> [...]
>>> FWIW, even though I lean towards more consistency with other class=20
>>> types, I have only personally found default-construction for captureles=
s=20
>>> lambdas to be desirable in my particular use-cases, and that's all that=
 I=20
>>> personally care for. Perhaps this is a more compelling example:
>>>
>>> // Use a lambda as a stateless deleter function
>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>>> some_deletion_function(ptr); })> object(create_some_type());
>>>
>>
>> This is a use-case I have also encountered in the wild. I would very muc=
h=20
>> like this (lambdas in unevaluated contexts, default-construction of=20
>> captureless closure types) to Just Work.
>>
>> Default-construction of *captureful* close types seems 100% dangerous=20
>> and bad.
>>
>>     int main() {
>>         int y =3D 42;
>>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>>         decltype(x) x2;
>>         x2();  // does this print the "value" of a default-initialized=
=20
>> int? that's super dangerous!
>>     }
>>
>> We definitely shouldn't provide the user-programmer with any constructs=
=20
>> that allow him to shoot himself in the foot this badly, especially when=
=20
>> there's no motivating use-case for the feature.
>>
>
> See above for motivating examples.
> =20
>
>>
>> I would say that there's one minorly thought-provoking corner case in=20
>> between "captureless" and "captureful":
>>
>>     int main() {
>>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>>         decltype(x) x2;  // ought this to compile?
>>         x2();  // ought this to print 42?
>>     }
>>
>> My opinion is that "no, it certainly oughtn't to print 42", based on my=
=20
>> (correct?) belief that the meaning of [z=3DFOO] is not altered in any wa=
y=20
>> by whether or not FOO is a constant-expression. In my ideal world, the=
=20
>> above code would *refuse to compile*, because decltype(x) is quite=20
>> definitely a *captureful* closure type.
>>
>> =20
> As explained above, the default constructor of the lambda should rely on=
=20
> the default constructor of its members (same as a user-defined type). Thu=
s,=20
> the value of a default-constructed lambda would be meaningful depending o=
f=20
> the meaningfulness of the values of its default-constructed members.
> For example, imagine a lambda capturing a std::string, the default=20
> construction of the type of this lambda should default-constructs its=20
> std::string member, which has a meaningful value (the empty string).
> Therefore, the value of this default-constructed lambda type is meaningfu=
l.
>
> For a lambda capturing an int :
> decltype(my_lambda_capturing_an_int) x; // the int member's value is=20
> undefined (members are default-constructed without empty braces)
> decltype(my_lambda_capturing_an_int) x{}; // the int member's value is 0=
=20
> (members are default-constructed with empty braces)
>
> One precision regarding the default construction without a meaningful=20
value, as in this case :
decltype(my_lambda_capturing_an_int) x;

The constructed value could be considered useless but again, following=20
Stepanov (Elements of Programming, p7), you can decide to have the default=
=20
construction of a type leaving the object in a *partially formed state*,=20
meaning you can only assign a value to it or destroy it. The main gain is=
=20
to have a free default construction by not initializing anything. See the=
=20
initial example for a use-case, or for example=20
find_adjacent_mismatch_forward (EoP, p106).
=20

> (though I don't remember if a type default-constructed with empty braces=
=20
> will recursively default-construct its members with empty braces).
>
> This way, default-construction of a lambda type is consistent with=20
> user-defined types.
> =20
>
>> Captureless closure types are already semantically more featureful than=
=20
>> captureful closure types; namely, they provide an implicit conversion to=
=20
>> function-pointer type. Providing a default constructor for captureless=
=20
>> closure types would be logically in keeping with that existing behavior,=
=20
>> IMO.
>>
>> I see that existing behavior of captureless closure types as basically=
=20
>> analogous to the way each new C++ standard adds new accessors to=20
>> std::true_type:
>> - ::value
>> - default constructor + operator bool
>> - default constructor + operator()
>> It's convenient to be able to use std::true_type as if it "means" true,=
=20
>> even though technically they're different things.
>>
>> For captureless closure types, we're only at the start of that journey.=
=20
>> So far we've added only
>> - operator <function-type>
>> but I think it makes sense to add
>> - default constructor
>> as well. This will enable user-programmers to more conveniently use=20
>> captureless closure types as if they "mean" functions, even though=20
>> technically they're different things.
>>
>> =E2=80=93Arthur
>>
>>>
--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7e217e87-cf62-4a34-ac3c-727548dd5d86%40isocpp.or=
g.

------=_Part_3469_645203739.1464171590366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mercredi 25 mai 2016 11:10:29 UTC+2, jmo...@ald=
ebaran.com a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><br><br>Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O&#=
39;Dwyer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">via....@gmail.com</a>&gt;</span> wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div>Again. I cannot see how that motivates a need for default constructi=
ble lambdas.</div></div></div></div></blockquote><div><br></div><div>It&#39=
;s never strictly a need, it&#39;s just a convenience.</div><div>[...]</div=
><div>FWIW, even though I lean towards more consistency with other class ty=
pes, I have only personally found default-construction for captureless lamb=
das to be desirable in my particular use-cases, and that&#39;s all that I p=
ersonally care for. Perhaps this is a more compelling example:</div><div><b=
r></div><div>// Use a lambda as a stateless deleter function</div><div>std:=
:unique_ptr&lt;some_type, decltype([](some_type* ptr) { some_deletion_funct=
ion(ptr); })&gt; object(create_some_type());</div></div></div></div></block=
quote><div><br></div><div>This is a use-case I have also encountered in the=
 wild. I would very much like this (lambdas in unevaluated contexts, defaul=
t-construction of captureless closure types) to Just Work.</div><div><br></=
div><div>Default-construction of <b><i>captureful</i></b> close types seems=
 100% dangerous and bad.</div><div><br></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 int main() {</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto =
x =3D [z=3Dy](){ printf(&quot;%d\n&quot;, z); };</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 x2(); =C2=A0// does this print the &quot;value&quot; of a default-in=
itialized int? that&#39;s super dangerous!</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 }</font></div><div><br></div><div>We d=
efinitely shouldn&#39;t provide the user-programmer with any constructs tha=
t allow him to shoot himself in the foot this badly, especially when there&=
#39;s no motivating use-case for the feature.</div></div></blockquote><div>=
<br></div><div>See above for motivating examples.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I=
 would say that there&#39;s one minorly thought-provoking corner case in be=
tween &quot;captureless&quot; and &quot;captureful&quot;:</div><div><br></d=
iv><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int main()=
 {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 auto x =3D [z=3D42](){ printf(&quot;%d\n&quot;, z); };<br></font=
></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 decltype(x) x2; =C2=A0// ought this to compile?</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// =
ought this to print 42?</font></div><div><font face=3D"courier new, monospa=
ce">=C2=A0 =C2=A0 }</font></div></div><div><br></div><div>My opinion is tha=
t &quot;no, it certainly oughtn&#39;t to print 42&quot;, based on my (corre=
ct?) belief that the meaning of <font face=3D"courier new, monospace">[z=3D=
FOO]</font> is not altered in any way by whether or not <font face=3D"couri=
er new, monospace">FOO</font> is a constant-expression. In my ideal world, =
the above code would <i><b>refuse to compile</b></i>, because <font face=3D=
"courier new, monospace">decltype(x)</font> is quite definitely a <i><b>cap=
tureful</b></i> closure type.</div><div><br></div></div></blockquote><div>=
=C2=A0</div><div>As explained above, the default constructor of the lambda =
should rely on the default constructor of its members (same as a user-defin=
ed type). Thus, the value of a default-constructed lambda would be meaningf=
ul depending of the meaningfulness of the values of its default-constructed=
 members.</div><div>For example, imagine a lambda capturing a std::string, =
the default construction of the type of this lambda should default-construc=
ts its std::string member, which has a meaningful value (the empty string).=
</div><div>Therefore, the value of this default-constructed lambda type is =
meaningful.</div><div><br></div><div>For a lambda capturing an int :</div><=
div>decltype(my_lambda_capturing_<wbr>an_int) x; // the int member&#39;s va=
lue is undefined (members are default-constructed without empty braces)</di=
v><div>decltype(my_lambda_capturing_<wbr>an_int) x{}; // the int member&#39=
;s value is 0 (members are default-constructed with empty braces)<br></div>=
<div><br></div></div></blockquote><div><div>One precision regarding the def=
ault construction without a meaningful value, as in this case :</div><div>d=
ecltype(my_lambda_capturing_an_int) x;</div><div><br></div><div>The constru=
cted value could be considered useless but again, following Stepanov (Eleme=
nts of Programming, p7), you can decide to have the default construction of=
 a type leaving the object in a <i>partially formed state</i>, meaning you =
can only assign a value to it or destroy it. The main gain is to have a fre=
e default construction by not initializing anything. See the initial exampl=
e for a use-case, or for example find_adjacent_mismatch_forward (EoP, p106)=
..</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div></div><div>(though I don&#39;t remember if a type def=
ault-constructed with empty braces will recursively default-construct its m=
embers with empty braces).</div><div><br></div><div>This way, default-const=
ruction of a lambda type is consistent with user-defined types.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div><div>Captureless closure types are already semantically more feat=
ureful than captureful closure types; namely, they provide an implicit conv=
ersion to function-pointer type. Providing a default constructor for captur=
eless closure types would be logically in keeping with that existing behavi=
or, IMO.</div><div><br></div><div>I see that existing behavior of capturele=
ss closure types as basically analogous to the way each new C++ standard ad=
ds new accessors to std::true_type:</div></div><div>- ::value</div><div>- d=
efault constructor + operator bool</div><div>- default constructor + operat=
or()</div><div>It&#39;s convenient to be able to use <font face=3D"courier =
new, monospace">std::true_type</font> as if it &quot;means&quot; <font face=
=3D"courier new, monospace">true</font>, even though technically they&#39;r=
e different things.</div><div><br></div><div>For captureless closure types,=
 we&#39;re only at the start of that journey. So far we&#39;ve added only</=
div><div>- operator &lt;function-type&gt;</div><div>but I think it makes se=
nse to add</div><div>- default constructor</div><div>as well. This will ena=
ble user-programmers to more conveniently use captureless closure types as =
if they &quot;mean&quot; functions, even though technically they&#39;re dif=
ferent things.</div><div><br></div><div>=E2=80=93Arthur</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
</blockquote></div></blockquote></div></blockquote></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7e217e87-cf62-4a34-ac3c-727548dd5d86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7e217e87-cf62-4a34-ac3c-727548dd5d86=
%40isocpp.org</a>.<br />

------=_Part_3469_645203739.1464171590366--

.

------=_Part_222_365349535.1464190514016
Content-Type: multipart/alternative;
 boundary="----=_Part_223_353441076.1464190514017"

------=_Part_223_353441076.1464190514017
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, jmo...@aldebaran.com wrote:
>
> Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>>
>> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>>
>>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=20
>>> wrote:
>>>>
>>>> Again. I cannot see how that motivates a need for default constructibl=
e=20
>>>> lambdas.
>>>>
>>>
>>> It's never strictly a need, it's just a convenience.
>>> [...]
>>> FWIW, even though I lean towards more consistency with other class=20
>>> types, I have only personally found default-construction for captureles=
s=20
>>> lambdas to be desirable in my particular use-cases, and that's all that=
 I=20
>>> personally care for. Perhaps this is a more compelling example:
>>>
>>> // Use a lambda as a stateless deleter function
>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>>> some_deletion_function(ptr); })> object(create_some_type());
>>>
>>
>> This is a use-case I have also encountered in the wild. I would very muc=
h=20
>> like this (lambdas in unevaluated contexts, default-construction of=20
>> captureless closure types) to Just Work.
>>
>> Default-construction of *captureful* close types seems 100% dangerous=20
>> and bad.
>>
>>     int main() {
>>         int y =3D 42;
>>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>>         decltype(x) x2;
>>         x2();  // does this print the "value" of a default-initialized=
=20
>> int? that's super dangerous!
>>     }
>>
>> We definitely shouldn't provide the user-programmer with any constructs=
=20
>> that allow him to shoot himself in the foot this badly, especially when=
=20
>> there's no motivating use-case for the feature.
>>
>
> See above for motivating examples.
> =20
>
>>
>> I would say that there's one minorly thought-provoking corner case in=20
>> between "captureless" and "captureful":
>>
>>     int main() {
>>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>>         decltype(x) x2;  // ought this to compile?
>>         x2();  // ought this to print 42?
>>     }
>>
>> My opinion is that "no, it certainly oughtn't to print 42", based on my=
=20
>> (correct?) belief that the meaning of [z=3DFOO] is not altered in any wa=
y=20
>> by whether or not FOO is a constant-expression. In my ideal world, the=
=20
>> above code would *refuse to compile*, because decltype(x) is quite=20
>> definitely a *captureful* closure type.
>>
>> =20
> As explained above, the default constructor of the lambda should rely on=
=20
> the default constructor of its members (same as a user-defined type). Thu=
s,=20
> the value of a default-constructed lambda would be meaningful depending o=
f=20
> the meaningfulness of the values of its default-constructed members.
>

I don't think you're getting the point.

If a lambda captures something, then the lambda function is either written=
=20
with the expectation that the capture will have the exact captured value or=
=20
it is not. If the function expects the value, then a default constructed=20
value of that type is *wrong* and will cause the function to behave=20
inappropriately.

There is *no way* to distinguish between these two cases. As such, whether=
=20
it is valid to default construct a lambda that captures values is not known=
=20
and cannot be known. Therefore, permitting the default construction of a=20
capturing lambda creates fragile, brittle code.

That's bad.

This is like the rules of trivial copyability. It's possible to write=20
classes which violate the rules of trivial copyability yet still=20
technically could be. This is based on how the user-defined copy/move=20
operations work and what data is being stored. But despite this, we don't=
=20
allow trivially copying them to be well-defined C++ behavior. We only allow=
=20
it to be well-defined in circumstances where we can be *certain* that such=
=20
copying will be reasonable, where we can *statically* determine if it will=
=20
always be legitimate.

The same goes here. The only case where we can be certain that default=20
constructing a lambda will produce a valid lambda is if it is captureless.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/55208578-a1d4-443b-bc92-4c52729bb367%40isocpp.or=
g.

------=_Part_223_353441076.1464190514017
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, jmo...@ald=
ebaran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O&#39;Dwyer a =C3=A9crit=
=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday,=
 May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On =
Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">via....@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Again. I can=
not see how that motivates a need for default constructible lambdas.</div><=
/div></div></div></blockquote><div><br></div><div>It&#39;s never strictly a=
 need, it&#39;s just a convenience.</div><div>[...]</div><div>FWIW, even th=
ough I lean towards more consistency with other class types, I have only pe=
rsonally found default-construction for captureless lambdas to be desirable=
 in my particular use-cases, and that&#39;s all that I personally care for.=
 Perhaps this is a more compelling example:</div><div><br></div><div>// Use=
 a lambda as a stateless deleter function</div><div>std::unique_ptr&lt;some=
_type, decltype([](some_type* ptr) { some_deletion_function(ptr); })&gt; ob=
ject(create_some_type());</div></div></div></div></blockquote><div><br></di=
v><div>This is a use-case I have also encountered in the wild. I would very=
 much like this (lambdas in unevaluated contexts, default-construction of c=
aptureless closure types) to Just Work.</div><div><br></div><div>Default-co=
nstruction of <b><i>captureful</i></b> close types seems 100% dangerous and=
 bad.</div><div><br></div><div><font face=3D"courier new, monospace">=C2=A0=
 =C2=A0 int main() {</font></div><div><font face=3D"courier new, monospace"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3Dy](){ pr=
intf(&quot;%d\n&quot;, z); };</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0/=
/ does this print the &quot;value&quot; of a default-initialized int? that&=
#39;s super dangerous!</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 }</font></div><div><br></div><div>We definitely shouldn&#3=
9;t provide the user-programmer with any constructs that allow him to shoot=
 himself in the foot this badly, especially when there&#39;s no motivating =
use-case for the feature.</div></div></blockquote><div><br></div><div>See a=
bove for motivating examples.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I would say that ther=
e&#39;s one minorly thought-provoking corner case in between &quot;capturel=
ess&quot; and &quot;captureful&quot;:</div><div><br></div><div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 int main() {</font></div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =
=3D [z=3D42](){ printf(&quot;%d\n&quot;, z); };<br></font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;=
 =C2=A0// ought this to compile?</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// ought this to print=
 42?</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }=
</font></div></div><div><br></div><div>My opinion is that &quot;no, it cert=
ainly oughtn&#39;t to print 42&quot;, based on my (correct?) belief that th=
e meaning of <font face=3D"courier new, monospace">[z=3DFOO]</font> is not =
altered in any way by whether or not <font face=3D"courier new, monospace">=
FOO</font> is a constant-expression. In my ideal world, the above code woul=
d <i><b>refuse to compile</b></i>, because <font face=3D"courier new, monos=
pace">decltype(x)</font> is quite definitely a <i><b>captureful</b></i> clo=
sure type.</div><div><br></div></div></blockquote><div>=C2=A0</div><div>As =
explained above, the default constructor of the lambda should rely on the d=
efault constructor of its members (same as a user-defined type). Thus, the =
value of a default-constructed lambda would be meaningful depending of the =
meaningfulness of the values of its default-constructed members.</div></div=
></blockquote><div><br>I don&#39;t think you&#39;re getting the point.<br><=
br>If a lambda captures something, then the lambda function is either writt=
en with the expectation that the capture will have the exact captured value=
 or it is not. If the function expects the value, then a default constructe=
d value of that type is <b>wrong</b> and will cause the function to behave =
inappropriately.<br><br> There is <i>no way</i> to distinguish between thes=
e two cases. As such, whether it is valid to default construct a lambda tha=
t captures values is not known and cannot be known. Therefore, permitting t=
he default construction of a capturing lambda creates fragile, brittle code=
..<br><br>That&#39;s bad.<br><br>This is like the rules of trivial copyabili=
ty. It&#39;s possible to write classes which violate the rules of trivial c=
opyability yet still technically could be. This is based on how the user-de=
fined copy/move operations work and what data is being stored. But despite =
this, we don&#39;t allow trivially copying them to be well-defined C++ beha=
vior. We only allow it to be well-defined in circumstances where we can be =
<i>certain</i> that such copying will be reasonable, where we can <i>static=
ally</i> determine if it will always be legitimate.<br><br>The same goes he=
re. The only case where we can be certain that default constructing a lambd=
a will produce a valid lambda is if it is captureless.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/55208578-a1d4-443b-bc92-4c52729bb367%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55208578-a1d4-443b-bc92-4c52729bb367=
%40isocpp.org</a>.<br />

------=_Part_223_353441076.1464190514017--

------=_Part_222_365349535.1464190514016--

.

------=_Part_5236_1829494321.1464257695665
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol Bolas a =C3=A9crit :
>
> On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, jmo...@aldebaran.com=20
> wrote:
>>
>> Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>>>
>>> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>>>
>>>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=
=20
>>>> wrote:
>>>>>
>>>>> Again. I cannot see how that motivates a need for default=20
>>>>> constructible lambdas.
>>>>>
>>>>
>>>> It's never strictly a need, it's just a convenience.
>>>> [...]
>>>> FWIW, even though I lean towards more consistency with other class=20
>>>> types, I have only personally found default-construction for capturele=
ss=20
>>>> lambdas to be desirable in my particular use-cases, and that's all tha=
t I=20
>>>> personally care for. Perhaps this is a more compelling example:
>>>>
>>>> // Use a lambda as a stateless deleter function
>>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>>>> some_deletion_function(ptr); })> object(create_some_type());
>>>>
>>>
>>> This is a use-case I have also encountered in the wild. I would very=20
>>> much like this (lambdas in unevaluated contexts, default-construction o=
f=20
>>> captureless closure types) to Just Work.
>>>
>>> Default-construction of *captureful* close types seems 100% dangerous=
=20
>>> and bad.
>>>
>>>     int main() {
>>>         int y =3D 42;
>>>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>>>         decltype(x) x2;
>>>         x2();  // does this print the "value" of a default-initialized=
=20
>>> int? that's super dangerous!
>>>     }
>>>
>>> We definitely shouldn't provide the user-programmer with any constructs=
=20
>>> that allow him to shoot himself in the foot this badly, especially when=
=20
>>> there's no motivating use-case for the feature.
>>>
>>
>> See above for motivating examples.
>> =20
>>
>>>
>>> I would say that there's one minorly thought-provoking corner case in=
=20
>>> between "captureless" and "captureful":
>>>
>>>     int main() {
>>>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>>>         decltype(x) x2;  // ought this to compile?
>>>         x2();  // ought this to print 42?
>>>     }
>>>
>>> My opinion is that "no, it certainly oughtn't to print 42", based on my=
=20
>>> (correct?) belief that the meaning of [z=3DFOO] is not altered in any w=
ay=20
>>> by whether or not FOO is a constant-expression. In my ideal world, the=
=20
>>> above code would *refuse to compile*, because decltype(x) is quite=20
>>> definitely a *captureful* closure type.
>>>
>>> =20
>> As explained above, the default constructor of the lambda should rely on=
=20
>> the default constructor of its members (same as a user-defined type). Th=
us,=20
>> the value of a default-constructed lambda would be meaningful depending =
of=20
>> the meaningfulness of the values of its default-constructed members.
>>
>
> I don't think you're getting the point.
>
> If a lambda captures something, then the lambda function is either writte=
n=20
> with the expectation that the capture will have the exact captured value =
or=20
> it is not. If the function expects the value, then a default constructed=
=20
> value of that type is *wrong* and will cause the function to behave=20
> inappropriately.
>
>
I'm not sure to follow you.
If I write:

std::string suffix{"abcd"};
auto append =3D [=3D](std::string const& str) {return str + suffix;};

I expect the generated lambda type to be roughly equivalent to :

struct lambda_type {
    std::string suffix;
    lambda_type(std::string s) : suffix(std::move(s)) {}
    auto operator()(std::string const& str) const {return str + suffix;}
};
// ...
lambda_type append{"abcd"};

Why adding a default constructor to lambda_type would be wrong ?
The default-constructed string member would simply be empty.
As explained before, the meaningfulness of a default constructed lambda=20
would be dependent on the meaningfulness of its default constructed=20
members. It is the responsability of the programmer to determine if the=20
default constructed lambda is meaningful or not. Note that it would be the=
=20
exact same logic as for the default construction of any user-defined type=
=20
and would thus be consistent with the rest of the language.

Also note that in the case of an arithmetic type:
int m{2};
auto add =3D [=3D](int n) {return m + n;};

I expect the generated lambda type to be roughly equivalent to :

struct lambda_type2 {
    int m;
    lambda_type2(int m) : m(m) {}
    auto operator()(int n) const {return m + n;}
};
// ...
lambda_type2 add{2};

In this case:
lambda_type2 add; // not meaningful because int is not initialized (see=20
above for "partially formed state")
add =3D lambda_type2{2}; // Now ok (see the initial example for a motivatio=
n).

With also this case:
lambda_type2 add{}; // Ok: member initialized with empty braces, so value=
=20
is 0.

As noted Matt Calabrese, it's all about consistency. The current behaviour=
=20
of lambdas break the consistency with the equivalent user-defined types.=20
When introducing a new feature in the language, it should be primordial to=
=20
ensure that it works well with the other existing mechanisms of the=20
language, i.e. to ensure it doesn't break consistency.

One of the fundamental mechanisms of the language is the ability to build=
=20
new richer types based on existing types, by using existing types as=20
members. This means that the capabilities of the new type depend on the=20
capabilities of its members. For example, the new type is typically=20
comparable only if all its members are comparable. Same thing for default=
=20
construction. The consistency allows to reduce complexity (think of=20
std::vector being able to store std::vector, without having to handle any=
=20
special case because std::vector respects the same constrains that it put=
=20
on its stored type).

So, if I design a new type in generic code and any Callable (sub)members=20
happens to be a lambda, I have to drop default constructability. This seems=
=20
an artificial limitation, as the equivalent user-defined type to this=20
lambda type would be fine.
I'm talking here about default construction because it the topic of this=20
proposal, but I think the case is even stronger for equality.

Regards,

Jeremy
=20

> There is *no way* to distinguish between these two cases. As such,=20
> whether it is valid to default construct a lambda that captures values is=
=20
> not known and cannot be known. Therefore, permitting the default=20
> construction of a capturing lambda creates fragile, brittle code.
>
> That's bad.
>
> This is like the rules of trivial copyability. It's possible to write=20
> classes which violate the rules of trivial copyability yet still=20
> technically could be. This is based on how the user-defined copy/move=20
> operations work and what data is being stored. But despite this, we don't=
=20
> allow trivially copying them to be well-defined C++ behavior. We only all=
ow=20
> it to be well-defined in circumstances where we can be *certain* that=20
> such copying will be reasonable, where we can *statically* determine if=
=20
> it will always be legitimate.
>
> The same goes here. The only case where we can be certain that default=20
> constructing a lambda will produce a valid lambda is if it is captureless=
..
>

--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dceec4a4-4067-4219-bb5b-b1f3aebdd41c%40isocpp.or=
g.

------=_Part_5236_1829494321.1464257695665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol Bola=
s a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, <a>jmo...@aldebara=
n.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Le=
 mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O&#39;Dwyer a =C3=A9crit=C2=A0=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, May 2=
4, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Ma=
y 24, 2016 at 9:39 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a rel=3D"nofo=
llow">via....@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Again. I cannot see =
how that motivates a need for default constructible lambdas.</div></div></d=
iv></div></blockquote><div><br></div><div>It&#39;s never strictly a need, i=
t&#39;s just a convenience.</div><div>[...]</div><div>FWIW, even though I l=
ean towards more consistency with other class types, I have only personally=
 found default-construction for captureless lambdas to be desirable in my p=
articular use-cases, and that&#39;s all that I personally care for. Perhaps=
 this is a more compelling example:</div><div><br></div><div>// Use a lambd=
a as a stateless deleter function</div><div>std::unique_ptr&lt;some_type, d=
ecltype([](some_type* ptr) { some_deletion_function(ptr); })&gt; object(cre=
ate_some_type());</div></div></div></div></blockquote><div><br></div><div>T=
his is a use-case I have also encountered in the wild. I would very much li=
ke this (lambdas in unevaluated contexts, default-construction of capturele=
ss closure types) to Just Work.</div><div><br></div><div>Default-constructi=
on of <b><i>captureful</i></b> close types seems 100% dangerous and bad.</d=
iv><div><br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
int main() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3Dy](){ printf(&qu=
ot;%d\n&quot;, z); };</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// does=
 this print the &quot;value&quot; of a default-initialized int? that&#39;s =
super dangerous!</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 }</font></div><div><br></div><div>We definitely shouldn&#39;t pr=
ovide the user-programmer with any constructs that allow him to shoot himse=
lf in the foot this badly, especially when there&#39;s no motivating use-ca=
se for the feature.</div></div></blockquote><div><br></div><div>See above f=
or motivating examples.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br></div><div>I would say that there&#39;=
s one minorly thought-provoking corner case in between &quot;captureless&qu=
ot; and &quot;captureful&quot;:</div><div><br></div><div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 int main() {</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=
=3D42](){ printf(&quot;%d\n&quot;, z); };<br></font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2; =C2=
=A0// ought this to compile?</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// ought this to print 42?=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</fo=
nt></div></div><div><br></div><div>My opinion is that &quot;no, it certainl=
y oughtn&#39;t to print 42&quot;, based on my (correct?) belief that the me=
aning of <font face=3D"courier new, monospace">[z=3DFOO]</font> is not alte=
red in any way by whether or not <font face=3D"courier new, monospace">FOO<=
/font> is a constant-expression. In my ideal world, the above code would <i=
><b>refuse to compile</b></i>, because <font face=3D"courier new, monospace=
">decltype(x)</font> is quite definitely a <i><b>captureful</b></i> closure=
 type.</div><div><br></div></div></blockquote><div>=C2=A0</div><div>As expl=
ained above, the default constructor of the lambda should rely on the defau=
lt constructor of its members (same as a user-defined type). Thus, the valu=
e of a default-constructed lambda would be meaningful depending of the mean=
ingfulness of the values of its default-constructed members.</div></div></b=
lockquote><div><br>I don&#39;t think you&#39;re getting the point.<br><br>I=
f a lambda captures something, then the lambda function is either written w=
ith the expectation that the capture will have the exact captured value or =
it is not. If the function expects the value, then a default constructed va=
lue of that type is <b>wrong</b> and will cause the function to behave inap=
propriately.<br><br></div></div></blockquote><div><br></div><div><div style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;">I&#39;m not sure to=
 follow you.</div><div style=3D"font-family: arial, sans-serif; font-size: =
12.8px;">If I write:</div><div style=3D"font-family: arial, sans-serif; fon=
t-size: 12.8px;"><br></div><div style=3D"font-family: arial, sans-serif; fo=
nt-size: 12.8px;">std::string suffix{&quot;abcd&quot;};</div><div style=3D"=
font-family: arial, sans-serif; font-size: 12.8px;">auto append =3D [=3D](s=
td::string const&amp; str) {return str + suffix;};</div><div style=3D"font-=
family: arial, sans-serif; font-size: 12.8px;"><br></div><div style=3D"font=
-family: arial, sans-serif; font-size: 12.8px;">I expect the generated lamb=
da type to be roughly equivalent to :</div><div style=3D"font-family: arial=
, sans-serif; font-size: 12.8px;"><br></div><div style=3D"font-family: aria=
l, sans-serif; font-size: 12.8px;">struct lambda_type {</div><div style=3D"=
font-family: arial, sans-serif; font-size: 12.8px;">=C2=A0 =C2=A0 std::stri=
ng suffix;</div><div style=3D"font-family: arial, sans-serif; font-size: 12=
..8px;">=C2=A0 =C2=A0 lambda_type(std::string s) : suffix(std::move(s)) {}</=
div><div style=3D"font-family: arial, sans-serif; font-size: 12.8px;">=C2=
=A0 =C2=A0 auto operator()(std::string const&amp; str) const {return str + =
suffix;}</div><div style=3D"font-family: arial, sans-serif; font-size: 12.8=
px;">};</div><div style=3D"font-family: arial, sans-serif; font-size: 12.8p=
x;">// ...</div><div style=3D"font-family: arial, sans-serif; font-size: 12=
..8px;">lambda_type append{&quot;abcd&quot;};</div><div style=3D"font-family=
: arial, sans-serif; font-size: 12.8px;"><br></div><div style=3D"font-famil=
y: arial, sans-serif; font-size: 12.8px;">Why adding a default constructor =
to lambda_type would be wrong ?</div><div style=3D"font-family: arial, sans=
-serif; font-size: 12.8px;">The default-constructed string member would sim=
ply be empty.</div><div style=3D"font-family: arial, sans-serif; font-size:=
 12.8px;">As explained before, the meaningfulness of a default constructed =
lambda would be dependent on the meaningfulness of its default constructed =
members. It is the responsability of the programmer to determine if the def=
ault constructed lambda is meaningful or not. Note that it would be the exa=
ct same logic as for the default construction of any user-defined type and =
would thus be consistent with the rest of the language.</div><div style=3D"=
font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style=3D=
"font-family: arial, sans-serif; font-size: 12.8px;">Also note that in the =
case of an arithmetic type:</div><div style=3D"font-family: arial, sans-ser=
if; font-size: 12.8px;">int m{2};</div><div style=3D"font-family: arial, sa=
ns-serif; font-size: 12.8px;">auto add =3D [=3D](int n) {return m + n;};</d=
iv><div style=3D"font-family: arial, sans-serif; font-size: 12.8px;"><br></=
div><div style=3D"font-family: arial, sans-serif; font-size: 12.8px;">I exp=
ect the generated lambda type to be roughly equivalent to :</div><div style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div styl=
e=3D"font-family: arial, sans-serif; font-size: 12.8px;">struct lambda_type=
2 {</div><div style=3D"font-family: arial, sans-serif; font-size: 12.8px;">=
=C2=A0 =C2=A0 int m;</div><div style=3D"font-family: arial, sans-serif; fon=
t-size: 12.8px;">=C2=A0 =C2=A0 lambda_type2(int m) : m(m) {}</div><div styl=
e=3D"font-family: arial, sans-serif; font-size: 12.8px;">=C2=A0 =C2=A0 auto=
 operator()(int n) const {return m + n;}</div><div style=3D"font-family: ar=
ial, sans-serif; font-size: 12.8px;">};</div><div style=3D"font-family: ari=
al, sans-serif; font-size: 12.8px;">// ...</div><div style=3D"font-family: =
arial, sans-serif; font-size: 12.8px;">lambda_type2 add{2};</div><div style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;"><br></div><div styl=
e=3D"font-family: arial, sans-serif; font-size: 12.8px;">In this case:</div=
><div style=3D"font-family: arial, sans-serif; font-size: 12.8px;">lambda_t=
ype2 add; // not meaningful because int is not initialized (see above for &=
quot;partially formed state&quot;)</div><div style=3D"font-family: arial, s=
ans-serif; font-size: 12.8px;">add =3D lambda_type2{2}; // Now ok (see the =
initial example for a motivation).</div><div style=3D"font-family: arial, s=
ans-serif; font-size: 12.8px;"><br></div><div style=3D"font-family: arial, =
sans-serif; font-size: 12.8px;">With also this case:</div><div style=3D"fon=
t-family: arial, sans-serif; font-size: 12.8px;">lambda_type2 add{}; // Ok:=
 member initialized with empty braces, so value is 0.</div><div style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.8px;"><br></div><div style=3D"f=
ont-family: arial, sans-serif; font-size: 12.8px;">As noted Matt Calabrese,=
 it&#39;s all about consistency. The current behaviour of lambdas break the=
 consistency with the equivalent user-defined types. When introducing a new=
 feature in the language, it should be primordial to ensure that it works w=
ell with the other existing mechanisms of the language, i.e. to ensure it d=
oesn&#39;t break consistency.</div><div style=3D"font-family: arial, sans-s=
erif; font-size: 12.8px;"><br></div><div style=3D"font-family: arial, sans-=
serif; font-size: 12.8px;"><div>One of the fundamental mechanisms of the la=
nguage is the ability to build new richer types based on existing types, by=
 using existing types as members. This means that the capabilities of the n=
ew type depend on the capabilities of its members. For example, the new typ=
e is typically comparable only if all its members are comparable. Same thin=
g for default construction. The consistency allows to reduce complexity (th=
ink of std::vector being able to store std::vector, without having to handl=
e any special case because std::vector respects the same constrains that it=
 put on its stored type).</div><div><br></div><div>So, if I design a new ty=
pe in generic code and any Callable (sub)members happens to be a lambda, I =
have to drop default constructability. This seems an artificial limitation,=
 as the equivalent user-defined type to this lambda type would be fine.</di=
v><div>I&#39;m talking here about default construction because it the topic=
 of this proposal, but I think the case is even stronger for equality.</div=
><div><br></div><div>Regards,</div><div><br></div><div>Jeremy</div></div></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div> There is <i>no way</i> to distinguish between these two case=
s. As such, whether it is valid to default construct a lambda that captures=
 values is not known and cannot be known. Therefore, permitting the default=
 construction of a capturing lambda creates fragile, brittle code.<br><br>T=
hat&#39;s bad.<br><br>This is like the rules of trivial copyability. It&#39=
;s possible to write classes which violate the rules of trivial copyability=
 yet still technically could be. This is based on how the user-defined copy=
/move operations work and what data is being stored. But despite this, we d=
on&#39;t allow trivially copying them to be well-defined C++ behavior. We o=
nly allow it to be well-defined in circumstances where we can be <i>certain=
</i> that such copying will be reasonable, where we can <i>statically</i> d=
etermine if it will always be legitimate.<br><br>The same goes here. The on=
ly case where we can be certain that default constructing a lambda will pro=
duce a valid lambda is if it is captureless.<br></div></div></blockquote></=
div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dceec4a4-4067-4219-bb5b-b1f3aebdd41c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dceec4a4-4067-4219-bb5b-b1f3aebdd41c=
%40isocpp.org</a>.<br />

------=_Part_5236_1829494321.1464257695665--

.

------=_Part_4987_1808453559.1464273735609
Content-Type: multipart/alternative;
 boundary="----=_Part_4988_348403004.1464273735610"

------=_Part_4988_348403004.1464273735610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, May 26, 2016 at 6:14:55 AM UTC-4, jmo...@aldebaran.com wrote:
>
> Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>> On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, jmo...@aldebaran.com=20
>> wrote:
>>>
>>> Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>>>>
>>>> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>>>>
>>>>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=
=20
>>>>> wrote:
>>>>>>
>>>>>> Again. I cannot see how that motivates a need for default=20
>>>>>> constructible lambdas.
>>>>>>
>>>>>
>>>>> It's never strictly a need, it's just a convenience.
>>>>> [...]
>>>>> FWIW, even though I lean towards more consistency with other class=20
>>>>> types, I have only personally found default-construction for capturel=
ess=20
>>>>> lambdas to be desirable in my particular use-cases, and that's all th=
at I=20
>>>>> personally care for. Perhaps this is a more compelling example:
>>>>>
>>>>> // Use a lambda as a stateless deleter function
>>>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>>>>> some_deletion_function(ptr); })> object(create_some_type());
>>>>>
>>>>
>>>> This is a use-case I have also encountered in the wild. I would very=
=20
>>>> much like this (lambdas in unevaluated contexts, default-construction =
of=20
>>>> captureless closure types) to Just Work.
>>>>
>>>> Default-construction of *captureful* close types seems 100% dangerous=
=20
>>>> and bad.
>>>>
>>>>     int main() {
>>>>         int y =3D 42;
>>>>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>>>>         decltype(x) x2;
>>>>         x2();  // does this print the "value" of a default-initialized=
=20
>>>> int? that's super dangerous!
>>>>     }
>>>>
>>>> We definitely shouldn't provide the user-programmer with any construct=
s=20
>>>> that allow him to shoot himself in the foot this badly, especially whe=
n=20
>>>> there's no motivating use-case for the feature.
>>>>
>>>
>>> See above for motivating examples.
>>> =20
>>>
>>>>
>>>> I would say that there's one minorly thought-provoking corner case in=
=20
>>>> between "captureless" and "captureful":
>>>>
>>>>     int main() {
>>>>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>>>>         decltype(x) x2;  // ought this to compile?
>>>>         x2();  // ought this to print 42?
>>>>     }
>>>>
>>>> My opinion is that "no, it certainly oughtn't to print 42", based on m=
y=20
>>>> (correct?) belief that the meaning of [z=3DFOO] is not altered in any=
=20
>>>> way by whether or not FOO is a constant-expression. In my ideal world,=
=20
>>>> the above code would *refuse to compile*, because decltype(x) is quite=
=20
>>>> definitely a *captureful* closure type.
>>>>
>>>> =20
>>> As explained above, the default constructor of the lambda should rely o=
n=20
>>> the default constructor of its members (same as a user-defined type). T=
hus,=20
>>> the value of a default-constructed lambda would be meaningful depending=
 of=20
>>> the meaningfulness of the values of its default-constructed members.
>>>
>>
>> I don't think you're getting the point.
>>
>> If a lambda captures something, then the lambda function is either=20
>> written with the expectation that the capture will have the exact captur=
ed=20
>> value or it is not. If the function expects the value, then a default=20
>> constructed value of that type is *wrong* and will cause the function to=
=20
>> behave inappropriately.
>>
>>
> I'm not sure to follow you.
> If I write:
>
> std::string suffix{"abcd"};
> auto append =3D [=3D](std::string const& str) {return str + suffix;};
>
> I expect the generated lambda type to be roughly equivalent to :
>
> struct lambda_type {
>     std::string suffix;
>     lambda_type(std::string s) : suffix(std::move(s)) {}
>     auto operator()(std::string const& str) const {return str + suffix;}
> };
> // ...
> lambda_type append{"abcd"};
>
> Why adding a default constructor to lambda_type would be wrong ?
>

You explained why this would be wrong with your `lambda_type` example.=20
Indeed, I have no idea why you posted it, since it undermines your entire=
=20
argument.

First, you should recall that `lambda_type` as you have declared it is *not=
=20
default constructible*. The rules for implicit default constructors is that=
=20
they exist unless you add a constructor. Since `lambda_type` has a=20
constructor, it won't get a default constructor unless you *explicitly* add=
=20
one.

So your "consistency" argument doesn't work. The standards committee=20
already ruled that such types are not implicitly default constructible. And=
=20
they did so for a very good reason. Therefore, making types that would=20
ordinarily be non-implicitly default constructible types into implicitly=20
default constructible types would in fact be *inconsistent* with existing=
=20
types.

Giving captureless lambdas a default constructor wouldn't be, since their=
=20
constructor's argument list is already de-facto empty.

Furthermore, the semantic purpose of `lambda_type` in your example is to=20
create an object which appends a string given at construction time to the=
=20
back of a string parameter. While it is syntactically valid to default=20
construct such an object, nobody would *want to*. Because if you did... *it=
=20
doesn't do anything*. Calling the default-constructed lambda is an=20
expensive no-op.

I would therefore assume most programmers would not declare a default=20
constructor for such a type, because the whole point of the type is that it=
=20
has a string. If the user wants to create one that appends the empty=20
string, then the user can pass an empty string to the non-default=20
constructor. That makes it abundantly clear what's going on.

And that's the best-case scenario for a default-constructed lambda: that it=
=20
does something pointless but harmless. Consider this:

auto GetTextureBinder(GLenum target, GLuint tex_id)
{
  if(!IsValidTarget(target)) throw std::runtime_error("Not a valid target."
);
  if(!glIsTexture(tex_id)) throw std::runtime_error("Not a valid texture");

  return [target, tex_id]() {glBindTexture(target, tex_id);}
}

This function validates a parameter, then returns a function that uses that=
=20
parameter. By the rules of C++ as they stand now, I have reasonable=20
assurance that the returned functor will always have a valid target. There=
=20
is nothing you can do to break this lambda externally without employing=20
perfidy (or `glDeleteTexture(tex_id)`). And that in fact is the *the goal*=
=20
of this function: to produce a lambda that binds the texture successfully,=
=20
without having to match `target` with the texture it goes to..

Default constructing this type will produce a *semantically meaningless*=20
object. To call that lambda will *at best*produce an OpenGL error; If it is=
=20
default initialized, then you may get total garbage. And remember: the=20
whole point of the lambda is to *avoid* such errors, to bind a valid=20
texture and its appropriate target together.

So in your world, how do I get my reasonable assurance back? How do I *turn=
=20
off* default construction of a lambda when that would lead to a=20
non-functioning lambda? Should I put redundant checking in my lambda to=20
make sure that values which were verified previously remain valid, even=20
though the whole point was to ensure that it was valid *before* creating=20
the lambda? Or do I have to abandon lambdas entirely and go back to a=20
user-built `struct`?

The default-constructed string member would simply be empty.
> As explained before, the meaningfulness of a default constructed lambda=
=20
> would be dependent on the meaningfulness of its default constructed membe=
rs.
>

No, it depends on the meaningfulness of the lambda function when used with=
=20
default constructed members.
=20

> It is the responsability of the programmer to determine if the default=20
> constructed lambda is meaningful or not.
>

Not under your proposal.

Responsibility has two parts: what you're have to do and the *ability* to=
=20
do it. If it is impossible for you to do something, then you're not=20
responsible for failing to do it.

Under your proposal, it is *impossible* for a programmer to turn off=20
default construction of a lambda when it is not meaningful. If the types=20
permit default construction, there is nothing the lambda writer can do=20
about it.

And no, using special non-default-constructible wrappers in your captures=
=20
is not a valid alternative.
=20

> As noted Matt Calabrese, it's all about consistency. The current behaviou=
r=20
> of lambdas break the consistency with the equivalent user-defined types.=
=20
> When introducing a new feature in the language, it should be primordial t=
o=20
> ensure that it works well with the other existing mechanisms of the=20
> language, i.e. to ensure it doesn't break consistency.
>

OK, the "consistency" ship sailed on lambdas when they decided that you had=
=20
to stick `mutable` at the end in order to modify the captured values.=20
Expecting consistency from lambdas is foolish at this point.

Also, as previously stated, "consistency" makes no sense here, because the=
=20
types in a struct do not alone determine whether it is default=20
constructible. So what are you trying to be "consistent" with here?

Lastly, consistency for its own sake is silly. Especially when that=20
"consistency" creates the possibility of bugs that didn't exist before.

One of the fundamental mechanisms of the language is the ability to build=
=20
> new richer types based on existing types, by using existing types as=20
> members. This means that the capabilities of the new type depend on the=
=20
> capabilities of its members. For example, the new type is typically=20
> comparable only if all its members are comparable. Same thing for default=
=20
> construction.
>

I can *turn off* default construction. I can also turn on default=20
construction even when types are not default constructible.

Your suggestion doesn't give me that power.
=20

> The consistency allows to reduce complexity (think of std::vector being=
=20
> able to store std::vector, without having to handle any special case=20
> because std::vector respects the same constrains that it put on its store=
d=20
> type).
>

Precisely what complexity is being reduced here?

Show me a template function which takes an arbitrary callable as a=20
parameter, that would *reasonably decide* to call a default-constructed=20
version of that callable.

Nobody would write such a thing. Why? Because you'd break with this:

int MyFunc();

CallTemplate(&MyFunc);

A default constructed function pointer is always a bad thing. Also:

std::function<int()> MyFunc =3D ...;

CallTemplate(MyFunc);

A default-constructed `function` is always a bad thing.

When it comes to non-functioning code, I'd personally rather get a compile=
=20
error instead of a runtime crash.

The *only reason* I can see why you would ever want to default construct=20
one is as a temporary measure, a stopgap on the way to performing a=20
copy/move assignment into that value. And those cases are exceedingly rare,=
=20
and can be dealt with by using `aligned_storage` and placement new.

So, if I design a new type in generic code and any Callable (sub)members=20
> happens to be a lambda, I have to drop default constructability. This see=
ms=20
> an artificial limitation, as the equivalent user-defined type to this=20
> lambda type would be fine.
>

As previously explained, the "equivalent user-defined type" would not be=20
default constructible. Also as previously explained, the ability to default=
=20
construct a lambda does not ensure that calling the function will be valid.=
=20
So if you were permitted to default construct them, you would not be able=
=20
to tell whether it was valid to do so.

Therefore, your template code should not attempt to default construct them.=
=20
So you've gained *nothing*.

The only lambdas that are *guaranteed* to be legitimate candidates for=20
default construction are captureless ones.
=20

> I'm talking here about default construction because it the topic of this=
=20
> proposal, but I think the case is even stronger for equality.
>

Equality is irrelevant, since we'll get that with the implicit comparison=
=20
operators proposal.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/871cb4cd-3df5-4421-a318-f69bb90b3ca2%40isocpp.or=
g.

------=_Part_4988_348403004.1464273735610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, May 26, 2016 at 6:14:55 AM UTC-4, jmo...@alde=
baran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, May 2=
5, 2016 at 5:10:29 AM UTC-4, <a>jmo...@aldebaran.com</a> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Le mercredi 25 mai 2016 01:31:=
42 UTC+2, Arthur O&#39;Dwyer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7=
, Matt Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On Tue, May 24, 2016 at 9:39 AM, Viach=
eslav Usov <span dir=3D"ltr">&lt;<a rel=3D"nofollow">via....@gmail.com</a>&=
gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>Again. I cannot see how that motivates a need fo=
r default constructible lambdas.</div></div></div></div></blockquote><div><=
br></div><div>It&#39;s never strictly a need, it&#39;s just a convenience.<=
/div><div>[...]</div><div>FWIW, even though I lean towards more consistency=
 with other class types, I have only personally found default-construction =
for captureless lambdas to be desirable in my particular use-cases, and tha=
t&#39;s all that I personally care for. Perhaps this is a more compelling e=
xample:</div><div><br></div><div>// Use a lambda as a stateless deleter fun=
ction</div><div>std::unique_ptr&lt;some_type, decltype([](some_type* ptr) {=
 some_deletion_function(ptr); })&gt; object(create_some_type());</div></div=
></div></div></blockquote><div><br></div><div>This is a use-case I have als=
o encountered in the wild. I would very much like this (lambdas in unevalua=
ted contexts, default-construction of captureless closure types) to Just Wo=
rk.</div><div><br></div><div>Default-construction of <b><i>captureful</i></=
b> close types seems 100% dangerous and bad.</div><div><br></div><div><font=
 face=3D"courier new, monospace">=C2=A0 =C2=A0 int main() {</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y =
=3D 42;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 auto x =3D [z=3Dy](){ printf(&quot;%d\n&quot;, z); };</fo=
nt></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 decltype(x) x2;</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// does this print the &quot;val=
ue&quot; of a default-initialized int? that&#39;s super dangerous!</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div>=
<div><br></div><div>We definitely shouldn&#39;t provide the user-programmer=
 with any constructs that allow him to shoot himself in the foot this badly=
, especially when there&#39;s no motivating use-case for the feature.</div>=
</div></blockquote><div><br></div><div>See above for motivating examples.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><br></div><div>I would say that there&#39;s one minorly thought-pro=
voking corner case in between &quot;captureless&quot; and &quot;captureful&=
quot;:</div><div><br></div><div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 int main() {</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3D42](){ printf(&quot;%d\n=
&quot;, z); };<br></font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2; =C2=A0// ought this to compile?=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 x2(); =C2=A0// ought this to print 42?</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div></div><div><br></=
div><div>My opinion is that &quot;no, it certainly oughtn&#39;t to print 42=
&quot;, based on my (correct?) belief that the meaning of <font face=3D"cou=
rier new, monospace">[z=3DFOO]</font> is not altered in any way by whether =
or not <font face=3D"courier new, monospace">FOO</font> is a constant-expre=
ssion. In my ideal world, the above code would <i><b>refuse to compile</b><=
/i>, because <font face=3D"courier new, monospace">decltype(x)</font> is qu=
ite definitely a <i><b>captureful</b></i> closure type.</div><div><br></div=
></div></blockquote><div>=C2=A0</div><div>As explained above, the default c=
onstructor of the lambda should rely on the default constructor of its memb=
ers (same as a user-defined type). Thus, the value of a default-constructed=
 lambda would be meaningful depending of the meaningfulness of the values o=
f its default-constructed members.</div></div></blockquote><div><br>I don&#=
39;t think you&#39;re getting the point.<br><br>If a lambda captures someth=
ing, then the lambda function is either written with the expectation that t=
he capture will have the exact captured value or it is not. If the function=
 expects the value, then a default constructed value of that type is <b>wro=
ng</b> and will cause the function to behave inappropriately.<br><br></div>=
</div></blockquote><div><br></div><div><div style=3D"font-family:arial,sans=
-serif;font-size:12.8px">I&#39;m not sure to follow you.</div><div style=3D=
"font-family:arial,sans-serif;font-size:12.8px">If I write:</div><div style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div style=3D"=
font-family:arial,sans-serif;font-size:12.8px">std::string suffix{&quot;abc=
d&quot;};</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"=
>auto append =3D [=3D](std::string const&amp; str) {return str + suffix;};<=
/div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div=
><div style=3D"font-family:arial,sans-serif;font-size:12.8px">I expect the =
generated lambda type to be roughly equivalent to :</div><div style=3D"font=
-family:arial,sans-serif;font-size:12.8px"><br></div><div style=3D"font-fam=
ily:arial,sans-serif;font-size:12.8px">struct lambda_type {</div><div style=
=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0 std::strin=
g suffix;</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"=
>=C2=A0 =C2=A0 lambda_type(std::string s) : suffix(std::move(s)) {}</div><d=
iv style=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0 au=
to operator()(std::string const&amp; str) const {return str + suffix;}</div=
><div style=3D"font-family:arial,sans-serif;font-size:12.8px">};</div><div =
style=3D"font-family:arial,sans-serif;font-size:12.8px">// ...</div><div st=
yle=3D"font-family:arial,sans-serif;font-size:12.8px">lambda_type append{&q=
uot;abcd&quot;};</div><div style=3D"font-family:arial,sans-serif;font-size:=
12.8px"><br></div><div style=3D"font-family:arial,sans-serif;font-size:12.8=
px">Why adding a default constructor to lambda_type would be wrong ?</div><=
/div></div></blockquote><div><br>You explained why this would be wrong with=
 your `lambda_type` example. Indeed, I have no idea why you posted it, sinc=
e it undermines your entire argument.<br><br>First, you should recall that =
`lambda_type` as you have declared it is <i>not default constructible</i>. =
The rules for implicit default constructors is that they exist unless you a=
dd a constructor. Since `lambda_type` has a constructor, it won&#39;t get a=
 default constructor unless you <i>explicitly</i> add one.<br><br>So your &=
quot;consistency&quot; argument doesn&#39;t work. The standards committee a=
lready ruled that such types are not implicitly default constructible. And =
they did so for a very good reason. Therefore, making types that would ordi=
narily be non-implicitly default constructible types into implicitly defaul=
t constructible types would in fact be <i>inconsistent</i> with existing ty=
pes.<br><br>Giving captureless lambdas a default constructor wouldn&#39;t b=
e, since their constructor&#39;s argument list is already de-facto empty.<b=
r><br>Furthermore, the semantic purpose of `lambda_type` in your example is=
 to create an object which appends a string given at construction time to t=
he back of a string parameter. While it is syntactically valid to default c=
onstruct such an object, nobody would <i>want to</i>. Because if you did...=
 <i>it doesn&#39;t do anything</i>. Calling the default-constructed lambda =
is an expensive no-op.<br><br>I would therefore assume most programmers wou=
ld not declare a default constructor for such a type, because the whole poi=
nt of the type is that it has a string. If the user wants to create one tha=
t appends the empty string, then the user can pass an empty string to the n=
on-default constructor. That makes it abundantly clear what&#39;s going on.=
<br><br>And that&#39;s the best-case scenario for a default-constructed lam=
bda: that it does something pointless but harmless. Consider this:<br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">GetTextureBinder</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">GLenum</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> target</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">GLuint</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> tex_id</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">IsValidTarget</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">target</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">throw</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">runtime_error</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quo=
t;Not a valid target.&quot;</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">glIsTe=
xture</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">tex_id</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">))</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">throw</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">runtime_error</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&quot;Not a valid texture&quot;</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br>=C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</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">target</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t=
ex_id</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">glBindTexture</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">target</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> tex_id</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span></div></code></div><br>This function validates a parame=
ter, then returns a function that uses that parameter. By the rules of C++ =
as they stand now, I have reasonable assurance that the returned functor wi=
ll always have a valid target. There is nothing you can do to break this la=
mbda externally without employing perfidy (or `glDeleteTexture(tex_id)`). A=
nd that in fact is the <i>the goal</i> of this function: to produce a lambd=
a that binds the texture successfully, without having to match `target` wit=
h the texture it goes to..<br><br>Default constructing this type will produ=
ce a <i>semantically meaningless</i> object. To call that lambda will <i>at=
 best</i>produce an OpenGL error; If it is default initialized, then you ma=
y get total garbage. And remember: the whole point of the lambda is to <i>a=
void</i> such errors, to bind a valid texture and its appropriate target to=
gether.<br><br>So in your world, how do I get my reasonable assurance back?=
 How do I <i>turn off</i> default construction of a lambda when that would =
lead to a non-functioning lambda? Should I put redundant checking in my lam=
bda to make sure that values which were verified previously remain valid, e=
ven though the whole point was to ensure that it was valid <i>before</i> cr=
eating the lambda? Or do I have to abandon lambdas entirely and go back to =
a user-built `struct`?<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 dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;font=
-size:12.8px">The default-constructed string member would simply be empty.<=
/div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">As explai=
ned before, the meaningfulness of a default constructed lambda would be dep=
endent on the meaningfulness of its default constructed members.</div></div=
></div></blockquote><div><br>No, it depends on the meaningfulness of the la=
mbda function when used with default constructed members.<br>=C2=A0</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 dir=3D"ltr"><div><div style=
=3D"font-family:arial,sans-serif;font-size:12.8px"> It is the responsabilit=
y of the programmer to determine if the default constructed lambda is meani=
ngful or not.</div></div></div></blockquote><div><br>Not under your proposa=
l.<br><br>Responsibility has two parts: what you&#39;re have to do and the =
<i>ability</i> to do it. If it is impossible for you to do something, then =
you&#39;re not responsible for failing to do it.<br><br>Under your proposal=
, it is <i>impossible</i> for a programmer to turn off default construction=
 of a lambda when it is not meaningful. If the types permit default constru=
ction, there is nothing the lambda writer can do about it.<br><br>And no, u=
sing special non-default-constructible wrappers in your captures is not a v=
alid alternative.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px"></div><div style=3D"font-family:arial,sans-serif;font-size:12.8p=
x">As noted Matt Calabrese, it&#39;s all about consistency. The current beh=
aviour of lambdas break the consistency with the equivalent user-defined ty=
pes. When introducing a new feature in the language, it should be primordia=
l to ensure that it works well with the other existing mechanisms of the la=
nguage, i.e. to ensure it doesn&#39;t break consistency.</div></div></div><=
/blockquote><div><br>OK, the &quot;consistency&quot; ship sailed on lambdas=
 when they decided that you had to stick `mutable` at the end in order to m=
odify the captured values. Expecting consistency from lambdas is foolish at=
 this point.<br><br>Also, as previously stated, &quot;consistency&quot; mak=
es no sense here, because the types in a struct do not alone determine whet=
her it is default constructible. So what are you trying to be &quot;consist=
ent&quot; with here?<br><br>Lastly, consistency for its own sake is silly. =
Especially when that &quot;consistency&quot; creates the possibility of bug=
s that didn&#39;t exist before.<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 dir=3D"ltr"><div><div style=3D"font-family:arial,sans-s=
erif;font-size:12.8px"></div><div style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px"><div>One of the fundamental mechanisms of the language is th=
e ability to build new richer types based on existing types, by using exist=
ing types as members. This means that the capabilities of the new type depe=
nd on the capabilities of its members. For example, the new type is typical=
ly comparable only if all its members are comparable. Same thing for defaul=
t construction.</div></div></div></div></blockquote><div><br>I can <i>turn =
off</i> default construction. I can also turn on default construction even =
when types are not default constructible.<br><br>Your suggestion doesn&#39;=
t give me that power.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px"><div> The consistency allows to reduce complexity (think of =
std::vector being able to store std::vector, without having to handle any s=
pecial case because std::vector respects the same constrains that it put on=
 its stored type).<br></div></div></div></div></blockquote><div><br>Precise=
ly what complexity is being reduced here?<br><br>Show me a template functio=
n which takes an arbitrary callable as a parameter, that would <i>reasonabl=
y decide</i> to call a default-constructed version of that callable.<br><br=
>Nobody would write such a thing. Why? Because you&#39;d break with this:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">MyFunc</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">CallTemplate</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(&amp;</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">MyFunc</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span></div></code></div><br>A default=
 constructed function pointer is always a bad thing. Also:<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">function</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">MyFunc</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </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"><br><br></span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">CallTemplate</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">MyFunc</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>A d=
efault-constructed `function` is always a bad thing.<br><br>When it comes t=
o non-functioning code, I&#39;d personally rather get a compile error inste=
ad of a runtime crash.<br><br>The <i>only reason</i> I can see why you woul=
d ever want to default construct one is as a temporary measure, a stopgap o=
n the way to performing a copy/move assignment into that value. And those c=
ases are exceedingly rare, and can be dealt with by using `aligned_storage`=
 and placement new.<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 dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px"><div></div><div>So, if I design a new type in generic code and a=
ny Callable (sub)members happens to be a lambda, I have to drop default con=
structability. This seems an artificial limitation, as the equivalent user-=
defined type to this lambda type would be fine.</div></div></div></div></bl=
ockquote><div><br>As previously explained, the &quot;equivalent user-define=
d type&quot; would not be default constructible. Also as previously explain=
ed, the ability to default construct a lambda does not ensure that calling =
the function will be valid. So if you were permitted to default construct t=
hem, you would not be able to tell whether it was valid to do so.<br><br>Th=
erefore, your template code should not attempt to default construct them. S=
o you&#39;ve gained <i>nothing</i>.<br><br>The only lambdas that are <i>gua=
ranteed</i> to be legitimate candidates for default construction are captur=
eless ones.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;font-size:12.=
8px"><div>I&#39;m talking here about default construction because it the to=
pic of this proposal, but I think the case is even stronger for equality.</=
div></div></div></div></blockquote><div><br>Equality is irrelevant, since w=
e&#39;ll get that with the implicit comparison operators proposal.<br></div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/871cb4cd-3df5-4421-a318-f69bb90b3ca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/871cb4cd-3df5-4421-a318-f69bb90b3ca2=
%40isocpp.org</a>.<br />

------=_Part_4988_348403004.1464273735610--

------=_Part_4987_1808453559.1464273735609--

.

--001a1140568a948cf30533c001a6
Content-Type: text/plain; charset=UTF-8

On 26 May 2016 at 05:14, <jmonnon@aldebaran.com> wrote:

>
> std::string suffix{"abcd"};
> auto append = [=](std::string const& str) {return str + suffix;};
>
> I expect the generated lambda type to be roughly equivalent to :
>
> struct lambda_type {
>     std::string suffix;
>     lambda_type(std::string s) : suffix(std::move(s)) {}
>     auto operator()(std::string const& str) const {return str + suffix;}
> };
> // ...
> lambda_type append{"abcd"};
>

Why wouldn't I just create a different lambda if I wanted to append to
nothing as opposed to appending to a captured string?

Again, I'm not seeing why having a lambda with only two possible states is
all that useful, especially in generic code.

Yes, I know you can abuse a mutable function call operator to add more
states, but that is an awfully convoluted way to get around writing a class.


> As noted Matt Calabrese, it's all about consistency. The current behaviour
> of lambdas break the consistency with the equivalent user-defined types.
>

Huh?  UDTs are not required to be default constructible.  UDTs typically
can have far more than two states.


> One of the fundamental mechanisms of the language is the ability to build
> new richer types based on existing types, by using existing types as
> members.
>

Which is not the intention of lambdas.  How do you envision using a
capturing lambda (default constructed or not) as an aggregate member of
another type?  Please post a code example of what you want to work in this
case.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNxrUkWT8s3RxCG0xbsDO_tYiQPx%3D3M9%2B2-rGZrUMTOoQ%40mail.gmail.com.

--001a1140568a948cf30533c001a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 26 May 2016 at 05:14,  <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmonnon@aldebaran.com" target=3D"_blank">jmonnon@aldebaran.com</a>&=
gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"h5"><br>=
<span style=3D"font-size:12.8px;color:rgb(34,34,34)">std::string suffix{&qu=
ot;abcd&quot;};</span><br></div></div><div><div style=3D"font-family:arial,=
sans-serif;font-size:12.8px">auto append =3D [=3D](std::string const&amp; s=
tr) {return str + suffix;};</div><div style=3D"font-family:arial,sans-serif=
;font-size:12.8px"><br></div><div style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px">I expect the generated lambda type to be roughly equivalent =
to :</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br>=
</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">struct l=
ambda_type {</div><div style=3D"font-family:arial,sans-serif;font-size:12.8=
px">=C2=A0 =C2=A0 std::string suffix;</div><div style=3D"font-family:arial,=
sans-serif;font-size:12.8px">=C2=A0 =C2=A0 lambda_type(std::string s) : suf=
fix(std::move(s)) {}</div><div style=3D"font-family:arial,sans-serif;font-s=
ize:12.8px">=C2=A0 =C2=A0 auto operator()(std::string const&amp; str) const=
 {return str + suffix;}</div><div style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px">};</div><div style=3D"font-family:arial,sans-serif;font-size=
:12.8px">// ...</div><div style=3D"font-family:arial,sans-serif;font-size:1=
2.8px">lambda_type append{&quot;abcd&quot;};</div></div></div></blockquote>=
<div><br></div><div>Why wouldn&#39;t I just create a different lambda if I =
wanted to append to nothing as opposed to appending to a captured string?</=
div><div><br></div><div>Again, I&#39;m not seeing why having a lambda with =
only two possible states is all that useful, especially in generic code.</d=
iv><div><br></div><div>Yes, I know you can abuse a mutable function call op=
erator to add more states, but that is an awfully convoluted way to get aro=
und writing a class.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;font-size:1=
2.8px"><span style=3D"font-size:12.8px">As noted Matt Calabrese, it&#39;s a=
ll about consistency. The current behaviour of lambdas break the consistenc=
y with the equivalent user-defined types.</span></div></div></div></blockqu=
ote><div><br></div><div>Huh?=C2=A0 UDTs are not required to be default cons=
tructible.=C2=A0 UDTs typically can have far more than two states.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div sty=
le=3D"font-family:arial,sans-serif;font-size:12.8px"><div>One of the fundam=
ental mechanisms of the language is the ability to build new richer types b=
ased on existing types, by using existing types as members. </div></div></d=
iv></div></blockquote><div><br></div><div>Which is not the intention of lam=
bdas.=C2=A0 How do you envision using a capturing lambda (default construct=
ed or not) as an aggregate member of another type?=C2=A0 Please post a code=
 example of what you want to work in this case.</div><div>--=C2=A0<br></div=
></div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr=
"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =
=C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNxrUkWT8s3RxCG0xbsDO_tYiQPx%=
3D3M9%2B2-rGZrUMTOoQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNx=
rUkWT8s3RxCG0xbsDO_tYiQPx%3D3M9%2B2-rGZrUMTOoQ%40mail.gmail.com</a>.<br />

--001a1140568a948cf30533c001a6--

.

Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT, jmonnon@aldebara=
n.com=20
escreveu:
> Also note that in the case of an arithmetic type:
> int m{2};
> auto add =3D [=3D](int n) {return m + n;};
>=20
> I expect the generated lambda type to be roughly equivalent to :
>=20
> struct lambda_type2 {
>     int m;
>     lambda_type2(int m) : m(m) {}
>     auto operator()(int n) const {return m + n;}
> };
> // ...
> lambda_type2 add{2};

In this case and in many others, I'd expect the compiler to do constant=20
propagation and remove the member "m" completely. That would make the lambd=
a:

struct lambda_type2 {
    auto operator()(int n) const {return 2 + n;}
};

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56320921.nVkzP2oIad%40tjmaciei-mobl1.

.

--001a11488f208b0f700533c30e83
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2016 at 9:35 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT,
> jmonnon@aldebaran.com
> escreveu:
> > Also note that in the case of an arithmetic type:
> > int m{2};
> > auto add =3D [=3D](int n) {return m + n;};
> >
> > I expect the generated lambda type to be roughly equivalent to :
> >
> > struct lambda_type2 {
> >     int m;
> >     lambda_type2(int m) : m(m) {}
> >     auto operator()(int n) const {return m + n;}
> > };
> > // ...
> > lambda_type2 add{2};
>
> In this case and in many others, I'd expect the compiler to do constant
> propagation and remove the member "m" completely. That would make the
> lambda:
>
> struct lambda_type2 {
>     auto operator()(int n) const {return 2 + n;}
> };
>

Thiago, I think from a machine-level point of view you're certainly
*correct* =E2=80=94 but if you believe your comment to be *relevant* at the
C++-language-semantics level, could you please clarify how?

Part of the point of my earlier post was to demonstrate that even these two
lambdas

    auto captureless =3D [](int n) { return 2 + n; };
    auto captureful =3D [m=3D2](int n) { return m + n; };

have fundamentally different behaviors in C++. captureless is implicitly
convertible to int(*)(int), whereas captureful is not implicitly
convertible to int(*)(int), and by the current rules of the C++ language
the compiler is *not allowed* to make it implicitly convertible to
int(*)(int).

=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0K5s0FX0_L5MbU39mzynQW-3KKgXwa4V8%2BJD94ZL=
Xm0dQ%40mail.gmail.com.

--001a11488f208b0f700533c30e83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, May 26, 2016 at 9:35 AM, Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">Em quinta-feira, 26 de maio de 2016, =
=C3=A0s 03:14:55 PDT, <a href=3D"mailto:jmonnon@aldebaran.com">jmonnon@alde=
baran.com</a><br>
escreveu:<br>
<span class=3D"">&gt; Also note that in the case of an arithmetic type:<br>
&gt; int m{2};<br>
&gt; auto add =3D [=3D](int n) {return m + n;};<br>
&gt;<br>
&gt; I expect the generated lambda type to be roughly equivalent to :<br>
&gt;<br>
&gt; struct lambda_type2 {<br>
&gt;=C2=A0 =C2=A0 =C2=A0int m;<br>
&gt;=C2=A0 =C2=A0 =C2=A0lambda_type2(int m) : m(m) {}<br>
&gt;=C2=A0 =C2=A0 =C2=A0auto operator()(int n) const {return m + n;}<br>
&gt; };<br>
&gt; // ...<br>
&gt; lambda_type2 add{2};<br>
<br>
</span>In this case and in many others, I&#39;d expect the compiler to do c=
onstant<br>
propagation and remove the member &quot;m&quot; completely. That would make=
 the lambda:<br>
<br>
struct lambda_type2 {<br>
=C2=A0 =C2=A0 auto operator()(int n) const {return 2 + n;}<br>
};<br></blockquote><div><br></div><div>Thiago, I think from a machine-level=
 point of view you&#39;re certainly <i>correct</i>=C2=A0=E2=80=94 but if yo=
u believe your comment to be <i>relevant</i> at the C++-language-semantics =
level, could you please clarify how?</div><div><br></div><div>Part of the p=
oint of my earlier post was to demonstrate that even these two lambdas</div=
><div><br></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto=
 captureless =3D [](int n) { return 2 + n; };</font></div><div><div><font f=
ace=3D"monospace, monospace">=C2=A0 =C2=A0 auto captureful =3D [m=3D2](int =
n) { return m + n; };</font></div></div><div><br></div><div>have fundamenta=
lly different behaviors in C++. <font face=3D"monospace, monospace">capture=
less</font> is implicitly convertible to <font face=3D"monospace, monospace=
">int(*)(int)</font>, whereas <font face=3D"monospace, monospace">capturefu=
l</font> is not implicitly convertible to <font face=3D"monospace, monospac=
e">int(*)(int)</font>, and by the current rules of the C++ language the com=
piler is <i>not allowed</i> to make it implicitly convertible to <font face=
=3D"monospace, monospace">int(*)(int)</font>.</div><div><br></div><div>=E2=
=80=93Arthur</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0K5s0FX0_L5MbU39mzynQW-3KKgXwa4=
V8%2BJD94ZLXm0dQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0K5s0FX0_=
L5MbU39mzynQW-3KKgXwa4V8%2BJD94ZLXm0dQ%40mail.gmail.com</a>.<br />

--001a11488f208b0f700533c30e83--

.

--001a1148a0bcd2c9ec0533c36ec5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2016 at 12:09 AM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On 24 May 2016 7:23 p.m., "Miro Knejp" <miro.knejp@gmail.com> wrote:
> > Am 25.05.2016 um 03:33 schrieb Nevin Liber:
> >> On 24 May 2016 at 18:31, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> >>>
> >>> This is a use-case I have also encountered in the wild. I would very
much like this
> >>> (lambdas in unevaluated contexts, default-construction of captureless
closure types)
> >>> to Just Work.
> >>
> >> Then how do you prevent [...]
> >> accidental ODR violation when someone includes this in two translation
units?
> >
> > [...] I see no reason why your example should cause an ODR violation.
It's just a matter
> > of specifying in the standard whether it should be one or not so it's
not implementation
> > dependent.
>
> The standard is already clear that it would not be: under the terms of
the odr, since you
> used the same token sequence to write the class definition (and met the
side conditions
> for lookup results), the implementation is required to make your program
act as if there
> is only one definition of the class, that is merely somehow visible from
multiple translation
> units at once.

Richard, could you expand on this a little bit, being as you're probably
the one here who knows the most about the ODR? :)  It sounds to me as if
you're using basically a technicality (the existence of a surrounding
struct/class definition) to avoid the ODR in Nevin's specific case, but
that you haven't addressed the possibility of ODR violations or plain old
type mismatches in simpler cases.
For example, if we allowed decltype-of-lambda, would this program still be
ill-formed?:

cat >alpha.h <<EOF
  EXTERN decltype([](){}) x;
EOF
cat >alpha.cc <<EOF
  #define EXTERN extern
  #include "alpha.h"  // declare x of type T
  #undef EXTERN
  #define EXTERN
  #include "alpha.h"  // define x of type U; if U!=3DT, the program is
ill-formed, right?
  int main() {}
EOF
clang++ alpha.cc

How about this one, where the initializer of an inline variable (does the
initializer count as part of the "definition" for purposes of the ODR?)
consists of the same sequence of tokens everywhere, but also contains an
implicit conversion from what I assume is a unique closure type, thus
apparently falling foul of N4567 3.2/(6.4)?:

cat >beta.cc <<EOF
  inline int (*v)() =3D [](){ return 42; };
EOF
cat >gamma.cc <<EOF
  inline int (*v)() =3D [](){ return 42; };
  int main() {}
EOF
clang++ beta.cc gamma.cc

I mean, are you saying there are *no* lambda-related ODR problems, or are
the problems just *more subtle* than the one Nevin suggested? (And if the
only problems are *subtle*, isn't that kind of worse than if they were
right out in the open?)

Could any of the problems (if any) be addressed by adding one more special
rule to captureless lambdas: namely, that two captureless lambdas
consisting of the same sequence of tokens are guaranteed to behave as if
they correspond to the same definition of the lambda?  That is, what if
tomorrow we made decltype([](){return 2;}) just as
translation-unit-invariant as decltype(2) is today? I think we have the
technology these days to make that happen (via the same mechanisms we use
for inlines and templates), although it might need a lot of work in the
mangler.

=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0K3x6RCFZE2UnGZGtpDSGjMZR1Y%2BvdksXVDHuFxN=
zJJMw%40mail.gmail.com.

--001a1148a0bcd2c9ec0533c36ec5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, May 25, 2016 at 12:09 AM, Richard Smith &lt;<a hre=
f=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>=
&gt; On 24 May 2016 7:23 p.m., &quot;Miro Knejp&quot; &lt;<a href=3D"mailto=
:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>&gt; &gt; Am =
25.05.2016 um 03:33 schrieb Nevin Liber:<br>&gt; &gt;&gt; On 24 May 2016 at=
 18:31, Arthur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com"=
>arthur.j.odwyer@gmail.com</a>&gt; wrote:<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;=
&gt;&gt; This is a use-case I have also encountered in the wild. I would ve=
ry much like this<br>&gt; &gt;&gt;&gt; (lambdas in unevaluated contexts, de=
fault-construction of captureless closure types)<br>&gt; &gt;&gt;&gt; to Ju=
st Work.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Then how do you prevent [...]<br=
>&gt; &gt;&gt; accidental ODR violation when someone includes this in two t=
ranslation units?<br>&gt; &gt;<br>&gt; &gt; [...] I see no reason why your =
example should cause an ODR violation. It&#39;s just a matter<br>&gt; &gt; =
of specifying in the standard whether it should be one or not so it&#39;s n=
ot implementation<br>&gt; &gt; dependent.<br>&gt;<br>&gt; The standard is a=
lready clear that it would not be: under the terms of the odr, since you<br=
>&gt; used the same token sequence to write the class definition (and met t=
he side conditions<br>&gt; for lookup results), the implementation is requi=
red to make your program act as if there<br>&gt; is only one definition of =
the class, that is merely somehow visible from multiple translation<br>&gt;=
 units at once.<br><br>Richard, could you expand on this a little bit, bein=
g as you&#39;re probably the one here who knows the most about the ODR? :) =
=C2=A0It sounds to me as if you&#39;re using basically a technicality (the =
existence of a surrounding struct/class definition) to avoid the ODR in Nev=
in&#39;s specific case, but that you haven&#39;t addressed the possibility =
of ODR violations or plain old type mismatches in simpler cases.<br>For exa=
mple, if we allowed decltype-of-lambda, would this program still be ill-for=
med?:<br><br><font face=3D"monospace, monospace">cat &gt;alpha.h &lt;&lt;EO=
F<br>=C2=A0 EXTERN decltype([](){}) x;<br>EOF<br>cat &gt;alpha.cc &lt;&lt;E=
OF<br>=C2=A0 #define EXTERN extern<br>=C2=A0 #include &quot;alpha.h&quot; =
=C2=A0// declare x of type T<br>=C2=A0 #undef EXTERN<br>=C2=A0 #define EXTE=
RN<br>=C2=A0 #include &quot;alpha.h&quot; =C2=A0// define x of type U; if U=
!=3DT, the program is ill-formed, right?</font><div><font face=3D"monospace=
, monospace">=C2=A0 int main() {}<br>EOF<br>clang++ alpha.cc</font><br><br>=
How about this one, where the initializer of an inline variable (does the i=
nitializer count as part of the &quot;definition&quot; for purposes of the =
ODR?) consists of the same sequence of tokens everywhere, but also contains=
 an implicit conversion from what I assume is a unique closure type, thus a=
pparently falling foul of N4567 3.2/(6.4)?:<br><br><font face=3D"monospace,=
 monospace">cat &gt;beta.cc &lt;&lt;EOF<br>=C2=A0 inline int (*v)() =3D [](=
){ return 42; };<br>EOF<br>cat &gt;gamma.cc &lt;&lt;EOF<br>=C2=A0 inline in=
t (*v)() =3D [](){ return 42; };<br>=C2=A0 int main() {}<br>EOF<br>clang++ =
beta.cc gamma.cc</font><br><div><br></div><div>I mean, are you saying there=
 are=C2=A0<i>no</i> lambda-related ODR problems, or are the problems just <=
i>more subtle</i> than the one Nevin suggested? (And if the only problems a=
re <i>subtle</i>, isn&#39;t that kind of worse than if they were right out =
in the open?)</div><div><br></div><div>Could any of the problems (if any) b=
e addressed by adding one more special rule to captureless lambdas: namely,=
 that two captureless lambdas consisting of the same sequence of tokens are=
 guaranteed to behave as if they correspond to the same definition of the l=
ambda?=C2=A0 That is, what if tomorrow we made <font face=3D"monospace, mon=
ospace">decltype([](){return 2;})</font> just as translation-unit-invariant=
 as <font face=3D"monospace, monospace">decltype(2)</font>=C2=A0is today? I=
 think we have the technology these days to make that happen (via the same =
mechanisms we use for inlines and templates), although it might need a lot =
of work in the mangler.</div><div><br></div><div>=E2=80=93Arthur</div></div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0K3x6RCFZE2UnGZGtpDSGjMZR1Y%2Bv=
dksXVDHuFxNzJJMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0K3x6RCFZ=
E2UnGZGtpDSGjMZR1Y%2BvdksXVDHuFxNzJJMw%40mail.gmail.com</a>.<br />

--001a1148a0bcd2c9ec0533c36ec5--

.

--001a113f29a81549e60533c686d6
Content-Type: text/plain; charset=UTF-8

On 26 May 2016 at 14:02, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

> \Richard, could you expand on this a little bit, being as you're probably
> the one here who knows the most about the ODR? :)  It sounds to me as if
> you're using basically a technicality (the existence of a surrounding
> struct/class definition) to avoid the ODR in Nevin's specific case, but
> that you haven't addressed the possibility of ODR violations or plain old
> type mismatches in simpler cases.
>

To be clear, my only real concern about extending captureless lambdas is
accidental ODR violations.  If we can get past that, it would be a useful
feature.

I'm still firmly against extending capturing lambdas, as I just don't see a
compelling reason to do so.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMkCo-vRqT1HTr0OOZZVKyfzJRfaqGYFTJ81ixr%2BuubbQ%40mail.gmail.com.

--001a113f29a81549e60533c686d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 26 May 2016 at 14:02, Arthur O&#39;Dwyer <span dir=3D"l=
tr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arth=
ur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
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"><div dir=3D"ltr">\=
Richard, could you expand on this a little bit, being as you&#39;re probabl=
y the one here who knows the most about the ODR? :) =C2=A0It sounds to me a=
s if you&#39;re using basically a technicality (the existence of a surround=
ing struct/class definition) to avoid the ODR in Nevin&#39;s specific case,=
 but that you haven&#39;t addressed the possibility of ODR violations or pl=
ain old type mismatches in simpler cases.<br></div></blockquote><div><br></=
div><div>To be clear, my only real concern about extending captureless lamb=
das is accidental ODR violations.=C2=A0 If we can get past that, it would b=
e a useful feature.</div><div><br></div><div>I&#39;m still firmly against e=
xtending capturing lambdas, as I just don&#39;t see a compelling reason to =
do so.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><d=
iv><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMkCo-vRqT1HTr0OOZZVKyfzJRfaq=
GYFTJ81ixr%2BuubbQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMkCo=
-vRqT1HTr0OOZZVKyfzJRfaqGYFTJ81ixr%2BuubbQ%40mail.gmail.com</a>.<br />

--001a113f29a81549e60533c686d6--

.

------=_Part_0_1951149512.1464308804394
Content-Type: multipart/alternative;
 boundary="----=_Part_1_97151094.1464308804401"

------=_Part_1_97151094.1464308804401
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, May 26, 2016 at 2:35:40 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Thu, May 26, 2016 at 9:35 AM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT,=20
>> jmo...@aldebaran.com <javascript:>
>> escreveu:
>> > Also note that in the case of an arithmetic type:
>> > int m{2};
>> > auto add =3D [=3D](int n) {return m + n;};
>> >
>> > I expect the generated lambda type to be roughly equivalent to :
>> >
>> > struct lambda_type2 {
>> >     int m;
>> >     lambda_type2(int m) : m(m) {}
>> >     auto operator()(int n) const {return m + n;}
>> > };
>> > // ...
>> > lambda_type2 add{2};
>>
>> In this case and in many others, I'd expect the compiler to do constant
>> propagation and remove the member "m" completely. That would make the=20
>> lambda:
>>
>> struct lambda_type2 {
>>     auto operator()(int n) const {return 2 + n;}
>> };
>>
>
> Thiago, I think from a machine-level point of view you're certainly=20
> *correct* =E2=80=94 but if you believe your comment to be *relevant* at t=
he=20
> C++-language-semantics level, could you please clarify how?
>

He's not trying to say that, at the language level, one should be=20
equivalent to the other. He's saying that the compiler has the choice right=
=20
now to optimize the capturing lambda "as if" it were a non-capturing one.=
=20
You don't get the language distinction, but you do get the *performance*.

With the proposed change, forcing capturing lambdas to be default=20
constructible, that optimization would now become *impossible*.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/230b692a-7b91-48f2-95a9-7559ad8f22bb%40isocpp.or=
g.

------=_Part_1_97151094.1464308804401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, May 26, 2016 at 2:35:40 PM UTC-4, Arthur O&#3=
9;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Thu, May 26, 2016 at 9:35 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"oeYTsCDIDgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">thi...@m=
acieira.org</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT, <a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"oeYTsCDIDgAJ"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmo...@ald=
ebaran.com</a><br>
escreveu:<br>
<span>&gt; Also note that in the case of an arithmetic type:<br>
&gt; int m{2};<br>
&gt; auto add =3D [=3D](int n) {return m + n;};<br>
&gt;<br>
&gt; I expect the generated lambda type to be roughly equivalent to :<br>
&gt;<br>
&gt; struct lambda_type2 {<br>
&gt;=C2=A0 =C2=A0 =C2=A0int m;<br>
&gt;=C2=A0 =C2=A0 =C2=A0lambda_type2(int m) : m(m) {}<br>
&gt;=C2=A0 =C2=A0 =C2=A0auto operator()(int n) const {return m + n;}<br>
&gt; };<br>
&gt; // ...<br>
&gt; lambda_type2 add{2};<br>
<br>
</span>In this case and in many others, I&#39;d expect the compiler to do c=
onstant<br>
propagation and remove the member &quot;m&quot; completely. That would make=
 the lambda:<br>
<br>
struct lambda_type2 {<br>
=C2=A0 =C2=A0 auto operator()(int n) const {return 2 + n;}<br>
};<br></blockquote><div><br></div><div>Thiago, I think from a machine-level=
 point of view you&#39;re certainly <i>correct</i>=C2=A0=E2=80=94 but if yo=
u believe your comment to be <i>relevant</i> at the C++-language-semantics =
level, could you please clarify how?</div></div></div></div></blockquote><d=
iv><br>He&#39;s not trying to say that, at the language level, one should b=
e equivalent to the other. He&#39;s saying that the compiler has the choice=
 right now to optimize the capturing lambda &quot;as if&quot; it were a non=
-capturing one. You don&#39;t get the language distinction, but you do get =
the <i>performance</i>.<br><br>With the proposed change, forcing capturing =
lambdas to be default constructible, that optimization would now become <i>=
impossible</i>.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/230b692a-7b91-48f2-95a9-7559ad8f22bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/230b692a-7b91-48f2-95a9-7559ad8f22bb=
%40isocpp.org</a>.<br />

------=_Part_1_97151094.1464308804401--

------=_Part_0_1951149512.1464308804394--

.

--001a1146cfa0a239290533c7ff5c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2016 at 5:26 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, May 26, 2016 at 2:35:40 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Thu, May 26, 2016 at 9:35 AM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT,
>>> jmo...@aldebaran.com
>>> escreveu:
>>> > Also note that in the case of an arithmetic type:
>>> > int m{2};
>>> > auto add =3D [=3D](int n) {return m + n;};
>>> >
>>> > I expect the generated lambda type to be roughly equivalent to :
>>> >
>>> > struct lambda_type2 {
>>> >     int m;
>>> >     lambda_type2(int m) : m(m) {}
>>> >     auto operator()(int n) const {return m + n;}
>>> > };
>>> > // ...
>>> > lambda_type2 add{2};
>>>
>>> In this case and in many others, I'd expect the compiler to do constant
>>> propagation and remove the member "m" completely. That would make the
>>> lambda:
>>>
>>> struct lambda_type2 {
>>>     auto operator()(int n) const {return 2 + n;}
>>> };
>>>
>>
>> Thiago, I think from a machine-level point of view you're certainly
>> *correct* =E2=80=94 but if you believe your comment to be *relevant* at =
the
>> C++-language-semantics level, could you please clarify how?
>>
>
> He's not trying to say that, at the language level, one should be
> equivalent to the other. He's saying that the compiler has the choice rig=
ht
> now to optimize the capturing lambda "as if" it were a non-capturing one.
> You don't get the language distinction, but you do get the *performance*.
>
> With the proposed change, forcing capturing lambdas to be default
> constructible, that optimization would now become *impossible*.
>

Ah, I see. That makes sense.

=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JSQMO6ms33G8H4udQJ--ZrVkc8-19j7yzbSPeA6Bj=
LBA%40mail.gmail.com.

--001a1146cfa0a239290533c7ff5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, May 26, 2016 at 5:26 PM, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursda=
y, May 26, 2016 at 2:35:40 PM UTC-4, Arthur O&#39;Dwyer wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Thu, May 26, 2016 at 9:35 AM=
, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@macieira=
..org</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">Em quinta-feira, 26 de maio de 2016, =C3=A0s 03:14:55 PDT, <a rel=3D"no=
follow">jmo...@aldebaran.com</a><span class=3D""><br>
escreveu:<br>
<span>&gt; Also note that in the case of an arithmetic type:<br>
&gt; int m{2};<br>
&gt; auto add =3D [=3D](int n) {return m + n;};<br>
&gt;<br>
&gt; I expect the generated lambda type to be roughly equivalent to :<br>
&gt;<br>
&gt; struct lambda_type2 {<br>
&gt;=C2=A0 =C2=A0 =C2=A0int m;<br>
&gt;=C2=A0 =C2=A0 =C2=A0lambda_type2(int m) : m(m) {}<br>
&gt;=C2=A0 =C2=A0 =C2=A0auto operator()(int n) const {return m + n;}<br>
&gt; };<br>
&gt; // ...<br>
&gt; lambda_type2 add{2};<br>
<br>
</span>In this case and in many others, I&#39;d expect the compiler to do c=
onstant<br>
propagation and remove the member &quot;m&quot; completely. That would make=
 the lambda:<br>
<br>
struct lambda_type2 {<br>
=C2=A0 =C2=A0 auto operator()(int n) const {return 2 + n;}<br>
};<br></span></blockquote><span class=3D""><div><br></div><div>Thiago, I th=
ink from a machine-level point of view you&#39;re certainly <i>correct</i>=
=C2=A0=E2=80=94 but if you believe your comment to be <i>relevant</i> at th=
e C++-language-semantics level, could you please clarify how?</div></span><=
/div></div></div></blockquote><div><br>He&#39;s not trying to say that, at =
the language level, one should be equivalent to the other. He&#39;s saying =
that the compiler has the choice right now to optimize the capturing lambda=
 &quot;as if&quot; it were a non-capturing one. You don&#39;t get the langu=
age distinction, but you do get the <i>performance</i>.<br><br>With the pro=
posed change, forcing capturing lambdas to be default constructible, that o=
ptimization would now become <i>impossible</i>.</div></div></blockquote><di=
v><br></div><div>Ah, I see. That makes sense.</div><div><br></div><div>=E2=
=80=93Arthur</div></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JSQMO6ms33G8H4udQJ--ZrVkc8-19j=
7yzbSPeA6BjLBA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JSQMO6ms33=
G8H4udQJ--ZrVkc8-19j7yzbSPeA6BjLBA%40mail.gmail.com</a>.<br />

--001a1146cfa0a239290533c7ff5c--

.

--001a113fe944b71a710533cc37e8
Content-Type: text/plain; charset=UTF-8

On Thu, May 26, 2016 at 12:02 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Wed, May 25, 2016 at 12:09 AM, Richard Smith <richard@metafoo.co.uk>
> wrote:
> > On 24 May 2016 7:23 p.m., "Miro Knejp" <miro.knejp@gmail.com> wrote:
> > > Am 25.05.2016 um 03:33 schrieb Nevin Liber:
> > >> On 24 May 2016 at 18:31, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
> > >>>
> > >>> This is a use-case I have also encountered in the wild. I would very
> much like this
> > >>> (lambdas in unevaluated contexts, default-construction of
> captureless closure types)
> > >>> to Just Work.
> > >>
> > >> Then how do you prevent [...]
> > >> accidental ODR violation when someone includes this in two
> translation units?
> > >
> > > [...] I see no reason why your example should cause an ODR violation.
> It's just a matter
> > > of specifying in the standard whether it should be one or not so it's
> not implementation
> > > dependent.
> >
> > The standard is already clear that it would not be: under the terms of
> the odr, since you
> > used the same token sequence to write the class definition (and met the
> side conditions
> > for lookup results), the implementation is required to make your program
> act as if there
> > is only one definition of the class, that is merely somehow visible from
> multiple translation
> > units at once.
>
> Richard, could you expand on this a little bit, being as you're probably
> the one here who knows the most about the ODR? :)  It sounds to me as if
> you're using basically a technicality (the existence of a surrounding
> struct/class definition) to avoid the ODR in Nevin's specific case, but
> that you haven't addressed the possibility of ODR violations or plain old
> type mismatches in simpler cases.
>

It may be a technicality, but it's an important one that's reasonably
central to the rules that make class / inline function definitions in
header files work in C++. Here's another case of the same rule:

// foo.h
struct A {
  struct { int x, y; } s;
};

decltype(A().s) is the same across translation units because of this rule.
And another:

// bar.h
inline auto f() {
  return [] {};
}

f() can be defined in multiple translation units only because the lambda
has the same type in each instance.

For example, if we allowed decltype-of-lambda, would this program still be
> ill-formed?:
>
> cat >alpha.h <<EOF
>   EXTERN decltype([](){}) x;
> EOF
> cat >alpha.cc <<EOF
>   #define EXTERN extern
>   #include "alpha.h"  // declare x of type T
>   #undef EXTERN
>   #define EXTERN
>   #include "alpha.h"  // define x of type U; if U!=T, the program is
> ill-formed, right?
>   int main() {}
> EOF
> clang++ alpha.cc
>

Yes, each occurrence of the [](){} token sequence here would create a
distinct closure type; that would be ill-formed.

How about this one, where the initializer of an inline variable (does the
> initializer count as part of the "definition" for purposes of the ODR?)
> consists of the same sequence of tokens everywhere, but also contains an
> implicit conversion from what I assume is a unique closure type, thus
> apparently falling foul of N4567 3.2/(6.4)?:
>
> cat >beta.cc <<EOF
>   inline int (*v)() = [](){ return 42; };
> EOF
> cat >gamma.cc <<EOF
>   inline int (*v)() = [](){ return 42; };
>   int main() {}
> EOF
> clang++ beta.cc gamma.cc
>

That would be fine, just as it would if the lambda were instead defined
inside an inline function or class definition. The program behaves as if
there is exactly one definition of the variable.

I mean, are you saying there are *no* lambda-related ODR problems, or are
> the problems just *more subtle* than the one Nevin suggested? (And if the
> only problems are *subtle*, isn't that kind of worse than if they were
> right out in the open?)
>

The latter. Do you have a plausible example where the ODR would be violated
but no diagnostic would be produced? It seems likely to me that problems
would often look like your EXTERN case above and would be reliably
diagnosed, but maybe there are other kinds of likely failure mode.

Could any of the problems (if any) be addressed by adding one more special
> rule to captureless lambdas: namely, that two captureless lambdas
> consisting of the same sequence of tokens are guaranteed to behave as if
> they correspond to the same definition of the lambda?  That is, what if
> tomorrow we made decltype([](){return 2;}) just as
> translation-unit-invariant as decltype(2) is today? I think we have the
> technology these days to make that happen (via the same mechanisms we use
> for inlines and templates), although it might need a lot of work in the
> mangler.
>

That sounds pretty painful. But yes, that'd solve the problem :)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-9qmO-jX-T6GWzQbyLuVP%2BoFLesenZA_jffe-rt9a%3DA%40mail.gmail.com.

--001a113fe944b71a710533cc37e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, May 26, 2016 at 12:02 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span=
 class=3D"">On Wed, May 25, 2016 at 12:09 AM, Richard Smith &lt;<a href=3D"=
mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&g=
t; wrote:<br>&gt; On 24 May 2016 7:23 p.m., &quot;Miro Knejp&quot; &lt;<a h=
ref=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com<=
/a>&gt; wrote:<br>&gt; &gt; Am 25.05.2016 um 03:33 schrieb Nevin Liber:<br>=
&gt; &gt;&gt; On 24 May 2016 at 18:31, Arthur O&#39;Dwyer &lt;<a href=3D"ma=
ilto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com=
</a>&gt; wrote:<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; This is a use-cas=
e I have also encountered in the wild. I would very much like this<br>&gt; =
&gt;&gt;&gt; (lambdas in unevaluated contexts, default-construction of capt=
ureless closure types)<br>&gt; &gt;&gt;&gt; to Just Work.<br>&gt; &gt;&gt;<=
br></span>&gt; &gt;&gt; Then how do you prevent [...]<span class=3D""><br>&=
gt; &gt;&gt; accidental ODR violation when someone includes this in two tra=
nslation units?<br>&gt; &gt;<br></span>&gt; &gt; [...] I see no reason why =
your example should cause an ODR violation. It&#39;s just a matter<span cla=
ss=3D""><br>&gt; &gt; of specifying in the standard whether it should be on=
e or not so it&#39;s not implementation<br>&gt; &gt; dependent.<br>&gt;<br>=
&gt; The standard is already clear that it would not be: under the terms of=
 the odr, since you<br>&gt; used the same token sequence to write the class=
 definition (and met the side conditions<br>&gt; for lookup results), the i=
mplementation is required to make your program act as if there<br>&gt; is o=
nly one definition of the class, that is merely somehow visible from multip=
le translation<br>&gt; units at once.<br><br></span>Richard, could you expa=
nd on this a little bit, being as you&#39;re probably the one here who know=
s the most about the ODR? :) =C2=A0It sounds to me as if you&#39;re using b=
asically a technicality (the existence of a surrounding struct/class defini=
tion) to avoid the ODR in Nevin&#39;s specific case, but that you haven&#39=
;t addressed the possibility of ODR violations or plain old type mismatches=
 in simpler cases.<br></div></blockquote><div><br></div><div>It may be a te=
chnicality, but it&#39;s an important one that&#39;s reasonably central to =
the rules that make class / inline function definitions in header files wor=
k in C++. Here&#39;s another case of the same rule:</div><div><br></div><di=
v>// foo.h</div><div>struct A {</div><div>=C2=A0 struct { int x, y; } s;</d=
iv><div>};</div><div><br></div><div>decltype(A().s) is the same across tran=
slation units because of this rule. And another:</div><div><br></div><div>/=
/ bar.h</div><div>inline auto f() {</div><div>=C2=A0 return [] {};</div><di=
v>}</div><div><br></div><div>f() can be defined in multiple translation uni=
ts only because the lambda has the same type in each instance.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex"><div dir=3D"ltr">For example, if we allowed declty=
pe-of-lambda, would this program still be ill-formed?:<br><br><font face=3D=
"monospace, monospace">cat &gt;alpha.h &lt;&lt;EOF<br>=C2=A0 EXTERN decltyp=
e([](){}) x;<br>EOF<br>cat &gt;alpha.cc &lt;&lt;EOF<br>=C2=A0 #define EXTER=
N extern<br>=C2=A0 #include &quot;alpha.h&quot; =C2=A0// declare x of type =
T<br>=C2=A0 #undef EXTERN<br>=C2=A0 #define EXTERN<br>=C2=A0 #include &quot=
;alpha.h&quot; =C2=A0// define x of type U; if U!=3DT, the program is ill-f=
ormed, right?</font><div><font face=3D"monospace, monospace">=C2=A0 int mai=
n() {}<br>EOF<br>clang++ alpha.cc</font></div></div></blockquote><div><br><=
/div><div>Yes, each occurrence of the [](){} token sequence here would crea=
te a distinct closure type; that would be ill-formed.=C2=A0</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>How about this one, where the i=
nitializer of an inline variable (does the initializer count as part of the=
 &quot;definition&quot; for purposes of the ODR?) consists of the same sequ=
ence of tokens everywhere, but also contains an implicit conversion from wh=
at I assume is a unique closure type, thus apparently falling foul of N4567=
 3.2/(6.4)?:<br><br><font face=3D"monospace, monospace">cat &gt;beta.cc &lt=
;&lt;EOF<br>=C2=A0 inline int (*v)() =3D [](){ return 42; };<br>EOF<br>cat =
&gt;gamma.cc &lt;&lt;EOF<br>=C2=A0 inline int (*v)() =3D [](){ return 42; }=
;<br>=C2=A0 int main() {}<br>EOF<br>clang++ beta.cc gamma.cc</font></div></=
div></blockquote><div><br></div><div>That would be fine, just as it would i=
f the lambda were instead defined inside an inline function or class defini=
tion. The program behaves as if there is exactly one definition of the vari=
able.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I mea=
n, are you saying there are=C2=A0<i>no</i> lambda-related ODR problems, or =
are the problems just <i>more subtle</i> than the one Nevin suggested? (And=
 if the only problems are <i>subtle</i>, isn&#39;t that kind of worse than =
if they were right out in the open?)</div></div></div></blockquote><div><br=
></div><div>The latter. Do you have a plausible example where the ODR would=
 be violated but no diagnostic would be produced? It seems likely to me tha=
t problems would often look like your EXTERN case above and would be reliab=
ly diagnosed, but maybe there are other kinds of likely failure mode.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Could any of the=
 problems (if any) be addressed by adding one more special rule to capturel=
ess lambdas: namely, that two captureless lambdas consisting of the same se=
quence of tokens are guaranteed to behave as if they correspond to the same=
 definition of the lambda?=C2=A0 That is, what if tomorrow we made <font fa=
ce=3D"monospace, monospace">decltype([](){return 2;})</font> just as transl=
ation-unit-invariant as <font face=3D"monospace, monospace">decltype(2)</fo=
nt>=C2=A0is today? I think we have the technology these days to make that h=
appen (via the same mechanisms we use for inlines and templates), although =
it might need a lot of work in the mangler.</div></div></div></blockquote><=
div><br></div><div>That sounds pretty painful. But yes, that&#39;d solve th=
e problem :)=C2=A0</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-9qmO-jX-T6GWzQbyLuVP%2BoFLes=
enZA_jffe-rt9a%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-9qmO=
-jX-T6GWzQbyLuVP%2BoFLesenZA_jffe-rt9a%3DA%40mail.gmail.com</a>.<br />

--001a113fe944b71a710533cc37e8--

.

------=_Part_166_294317760.1464339506758
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le jeudi 26 mai 2016 16:57:18 UTC+2, Nevin ":-)" Liber a =C3=A9crit :
>
> On 26 May 2016 at 05:14, <jmo...@aldebaran.com <javascript:>> wrote:
>
>>
>> std::string suffix{"abcd"};
>> auto append =3D [=3D](std::string const& str) {return str + suffix;};
>>
>> I expect the generated lambda type to be roughly equivalent to :
>>
>> struct lambda_type {
>>     std::string suffix;
>>     lambda_type(std::string s) : suffix(std::move(s)) {}
>>     auto operator()(std::string const& str) const {return str + suffix;}
>> };
>> // ...
>> lambda_type append{"abcd"};
>>
>
> Why wouldn't I just create a different lambda if I wanted to append to=20
> nothing as opposed to appending to a captured string?
>
> Again, I'm not seeing why having a lambda with only two possible states i=
s=20
> all that useful, especially in generic code.
>

See the example below.
=20

>
> Yes, I know you can abuse a mutable function call operator to add more=20
> states, but that is an awfully convoluted way to get around writing a cla=
ss.
> =20
>
>> As noted Matt Calabrese, it's all about consistency. The current=20
>> behaviour of lambdas break the consistency with the equivalent user-defi=
ned=20
>> types.
>>
>
> Huh?  UDTs are not required to be default constructible.  UDTs typically=
=20
> can have far more than two states.=20
>
=20
>
>> One of the fundamental mechanisms of the language is the ability to buil=
d=20
>> new richer types based on existing types, by using existing types as=20
>> members.=20
>>
>
> Which is not the intention of lambdas.  How do you envision using a=20
> capturing lambda (default constructed or not) as an aggregate member of=
=20
> another type?  Please post a code example of what you want to work in thi=
s=20
> case.
>

Here is an more complex example that should compile. I hope this will=20
answer your questions.
It's useful to default construct I in find_last.

#include <iterator>
#include <utility>
#include <type_traits>
#include <forward_list>
#include <string>
#include <iostream>

// Useful in this example.
template<typename T>
bool operator!=3D(T const& a, T const& b) {
    return !(a =3D=3D b);
}

// Find the iterator right before end, that is the last iterator pointing t=
o
// a valid element of the half-open bounded range.
template<typename I> // ForwardIterator I
I find_last(I b, I e) {
    // Precondition: bounded_range(b, e) && b !=3D e
    I i; // It's possible to do this only if all I's members are default=20
constructible, which is not the case if there is a lambda.
    // Note that it doesn't matter here if the default-constructed value is=
=20
meaningful or not.
    do {
        i =3D b;
        ++b;
    } while (b !=3D e);
    return i;
}

// In this case, it is useful to default contruct i, because we don't have=
=20
the value yet, and the scope of i exceed the loop.

// A Transformation is a Regular Callable with the signature T (T).
// We could also use an Action (semantically equivalent to a Transformation=
,
// but with the signature void (T&)) if the assignment of I is expensive.
template<typename I, typename F> // ForwardIterator I, Transformation<I> F
struct iter_transfo_t {
    I i;
    F f; // This is a Callable, and it would be nice if it could be a=20
lambda.
    // ...
    iter_transfo_t& operator++() {
        i =3D f(i);
        return *this;
    }
    friend bool operator=3D=3D(iter_transfo_t const& a, iter_transfo_t cons=
t&=20
b) {
        // For now, doesn't compile if f is a lambda, but let's assume it's=
=20
ok.
        return a.i =3D=3D b.i && a.f =3D=3D b.f;
    }
    // As a side note, would be also nice to have operator<(), for example=
=20
to be able to use this type
    // as the key type of a map.
    // The definition would be (a.i < b.i) || (!(b.i < a.i) && a.f < b.f),
    // assuming that < on I follows the trichotomy law (meaning
    // !(i < j) && !(j < i) implies i =3D=3D j).
    // ...
};

template<typename I> // ForwardIterator I
auto strided_iter(I&& i, size_t step) {
    auto f =3D [=3D](I i) {std::advance(i, step); return i;};
    return iter_transfo_t<std::decay_t<I>, decltype(f)>{std::forward<I>(i),=
=20
f};
}

// Let's imagine the elements follow the pattern
// firstname0, lastname0, firstname1, lastname1, ...
// We could use this to find the last firstname.
template<typename I> // ForwardIterator I
I find_last_even_positionned(I b, I e) {
    // Precondition: bounded_range(b, e) && std::distance(b, e) >=3D 2 &&=
=20
std::distance(b, e) % 2 =3D=3D 0
    return find_last(strided_iter(b, 2u), strided_iter(e, 2u)).i;
}

// We could implement other algorithms similar to find_last_name, by using=
=20
other transformations,
// (typically implemented by lambdas) for example to find the last prime=20
number of a range, and so on.
// The transformations allow to implement any traversal of the range.

int main() {
    using namespace std;
    // The only purpose of using a forward_list is to show that the=20
algorithm works with forward iterators.
    forward_list<string> names{"John", "Rambo", "Marty", "McFly",=20
"Indiana", "Jones"};
    auto it_first_name =3D find_last_even_positionned(begin(names),=20
end(names));
    cout << *it_first_name << '\n'; // output Indiana
    return 0;
}
=20

> --=20
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>=20
>  +1-847-691-1404
>

If we replace the lambda in strided_iter by the following type, everything=
=20
is ok :

struct advance_t {
    size_t step;
    template<typename I>
    I operator()(I i) const {
        std::advance(i, step);
        return i;
    }
    friend bool operator=3D=3D(advance_t const &a, advance_t const& b) {
        return a.step =3D=3D b.step;
    }
    // Not mandatory in the above example, but nice to have:
    friend bool operator<(advance_t const &a, advance_t const& b) {
        return a.step < b.step;
    }
};

template<typename I> // ForwardIterator I
auto strided_iter(I&& i, size_t step) {
    return iter_transfo_t<std::decay_t<I>, advance_t>{std::forward<I>(i),=
=20
{step}};
}


Regards,

Jeremy

--=20





*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------




*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a06ba085-0637-46d9-8249-af668640c8b1%40isocpp.or=
g.

------=_Part_166_294317760.1464339506758
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le jeudi 26 mai 2016 16:57:18 UTC+2, Nevin &quot;:=
-)&quot; Liber a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On 26 May 2016 at 05:14,  <span dir=3D"ltr">&lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"a01uKDa8DgAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmo...@al=
debaran.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><span style=3D"font=
-size:12.8px;color:rgb(34,34,34)">std::string suffix{&quot;abcd&quot;};</sp=
an><br></div></div><div><div style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">auto append =3D [=3D](std::string const&amp; str) {return str + s=
uffix;};</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">=
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">I ex=
pect the generated lambda type to be roughly equivalent to :</div><div styl=
e=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div style=3D=
"font-family:arial,sans-serif;font-size:12.8px">struct lambda_type {</div><=
div style=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0 s=
td::string suffix;</div><div style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">=C2=A0 =C2=A0 lambda_type(std::string s) : suffix(std::move(s)) {=
}</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =
=C2=A0 auto operator()(std::string const&amp; str) const {return str + suff=
ix;}</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">};</=
div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">// ...</di=
v><div style=3D"font-family:arial,sans-serif;font-size:12.8px">lambda_type =
append{&quot;abcd&quot;};</div></div></div></blockquote><div><br></div><div=
>Why wouldn&#39;t I just create a different lambda if I wanted to append to=
 nothing as opposed to appending to a captured string?</div><div><br></div>=
<div>Again, I&#39;m not seeing why having a lambda with only two possible s=
tates is all that useful, especially in generic code.</div></div></div></di=
v></blockquote><div><br></div><div>See the example below.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div><br></div><div>Yes, I know you can abuse a mut=
able function call operator to add more states, but that is an awfully conv=
oluted way to get around writing a class.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div style=3D"font-family:arial,s=
ans-serif;font-size:12.8px"><span style=3D"font-size:12.8px">As noted Matt =
Calabrese, it&#39;s all about consistency. The current behaviour of lambdas=
 break the consistency with the equivalent user-defined types.</span></div>=
</div></div></blockquote><div><br></div><div>Huh?=C2=A0 UDTs are not requir=
ed to be default constructible.=C2=A0 UDTs typically can have far more than=
 two states.=C2=A0</div></div></div></div></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px"><div>One of the fund=
amental mechanisms of the language is the ability to build new richer types=
 based on existing types, by using existing types as members. </div></div><=
/div></div></blockquote><div><br></div><div>Which is not the intention of l=
ambdas.=C2=A0 How do you envision using a capturing lambda (default constru=
cted or not) as an aggregate member of another type?=C2=A0 Please post a co=
de example of what you want to work in this case.</div></div></div></div></=
blockquote><div><br></div><div>Here is an more complex example that should =
compile. I hope this will answer your questions.</div><div>It&#39;s useful =
to default construct I in find_last.</div><div><br></div><div><div>#include=
 &lt;iterator&gt;</div><div>#include &lt;utility&gt;</div><div>#include &lt=
;type_traits&gt;</div><div>#include &lt;forward_list&gt;</div><div>#include=
 &lt;string&gt;</div><div>#include &lt;iostream&gt;</div><div><br></div><di=
v>// Useful in this example.</div><div>template&lt;typename T&gt;</div><div=
>bool operator!=3D(T const&amp; a, T const&amp; b) {</div><div>=C2=A0 =C2=
=A0 return !(a =3D=3D b);</div><div>}</div><div><br></div><div>// Find the =
iterator right before end, that is the last iterator pointing to</div><div>=
// a valid element of the half-open bounded range.</div><div>template&lt;ty=
pename I&gt; // ForwardIterator I</div><div>I find_last(I b, I e) {</div><d=
iv>=C2=A0 =C2=A0 // Precondition: bounded_range(b, e) &amp;&amp; b !=3D e</=
div><div>=C2=A0 =C2=A0 I i; // It&#39;s possible to do this only if all I&#=
39;s members are default constructible, which is not the case if there is a=
 lambda.</div><div>=C2=A0 =C2=A0 // Note that it doesn&#39;t matter here if=
 the default-constructed value is meaningful or not.</div><div>=C2=A0 =C2=
=A0 do {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 i =3D b;</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ++b;</div><div>=C2=A0 =C2=A0 } while (b !=3D e);</div>=
<div>=C2=A0 =C2=A0 return i;</div><div>}</div></div><div><br></div><div><di=
v>// In this case, it is useful to default contruct i, because we don&#39;t=
 have the value yet, and the scope of i exceed the loop.</div><div><br></di=
v><div>// A Transformation is a Regular Callable with the signature T (T).<=
/div><div>// We could also use an Action (semantically equivalent to a Tran=
sformation,</div><div>// but with the signature void (T&amp;)) if the assig=
nment of I is expensive.</div><div>template&lt;typename I, typename F&gt; /=
/ ForwardIterator I, Transformation&lt;I&gt; F</div><div>struct iter_transf=
o_t {</div><div>=C2=A0 =C2=A0 I i;</div><div>=C2=A0 =C2=A0 F f; // This is =
a Callable, and it would be nice if it could be a lambda.</div><div>=C2=A0 =
=C2=A0 // ...</div><div>=C2=A0 =C2=A0 iter_transfo_t&amp; operator++() {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 i =3D f(i);</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return *this;</div><div>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =
friend bool operator=3D=3D(iter_transfo_t const&amp; a, iter_transfo_t cons=
t&amp; b) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // For now, doesn&#39;t c=
ompile if f is a lambda, but let&#39;s assume it&#39;s ok.</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 return a.i =3D=3D b.i &amp;&amp; a.f =3D=3D b.f;</div=
><div>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 // As a side note, would be a=
lso nice to have operator&lt;(), for example to be able to use this type</d=
iv><div>=C2=A0 =C2=A0 // as the key type of a map.</div><div>=C2=A0 =C2=A0 =
// The definition would be (a.i &lt; b.i) || (!(b.i &lt; a.i) &amp;&amp; a.=
f &lt; b.f),</div><div>=C2=A0 =C2=A0 // assuming that &lt; on I follows the=
 trichotomy law (meaning</div><div>=C2=A0 =C2=A0 // !(i &lt; j) &amp;&amp; =
!(j &lt; i) implies i =3D=3D j).</div><div>=C2=A0 =C2=A0 // ...</div><div>}=
;</div><div><br></div><div>template&lt;typename I&gt; // ForwardIterator I<=
/div><div>auto strided_iter(I&amp;&amp; i, size_t step) {</div><div>=C2=A0 =
=C2=A0 auto f =3D [=3D](I i) {std::advance(i, step); return i;};</div><div>=
=C2=A0 =C2=A0 return iter_transfo_t&lt;std::decay_t&lt;I&gt;, decltype(f)&g=
t;{std::forward&lt;I&gt;(i), f};</div><div>}</div><div><br></div><div>// Le=
t&#39;s imagine the elements follow the pattern</div><div>// firstname0, la=
stname0, firstname1, lastname1, ...</div><div>// We could use this to find =
the last firstname.</div><div>template&lt;typename I&gt; // ForwardIterator=
 I</div><div>I find_last_even_positionned(I b, I e) {</div><div>=C2=A0 =C2=
=A0 // Precondition: bounded_range(b, e) &amp;&amp; std::distance(b, e) &gt=
;=3D 2 &amp;&amp; std::distance(b, e) % 2 =3D=3D 0</div><div>=C2=A0 =C2=A0 =
return find_last(strided_iter(b, 2u), strided_iter(e, 2u)).i;</div><div>}</=
div></div><div><br></div><div><div>// We could implement other algorithms s=
imilar to find_last_name, by using other transformations,</div><div>// (typ=
ically implemented by lambdas) for example to find the last prime number of=
 a range, and so on.</div><div>// The transformations allow to implement an=
y traversal of the range.</div><div><br></div><div>int main() {</div><div>=
=C2=A0 =C2=A0 using namespace std;</div><div>=C2=A0 =C2=A0 // The only purp=
ose of using a forward_list is to show that the algorithm works with forwar=
d iterators.</div><div>=C2=A0 =C2=A0 forward_list&lt;string&gt; names{&quot=
;John&quot;, &quot;Rambo&quot;, &quot;Marty&quot;, &quot;McFly&quot;, &quot=
;Indiana&quot;, &quot;Jones&quot;};</div><div>=C2=A0 =C2=A0 auto it_first_n=
ame =3D find_last_even_positionned(begin(names), end(names));</div><div>=C2=
=A0 =C2=A0 cout &lt;&lt; *it_first_name &lt;&lt; &#39;\n&#39;; // output In=
diana</div><div>=C2=A0 =C2=A0 return 0;</div><div>}</div></div><div>=C2=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><div>--=C2=A0<br></div></div><div><div dir=3D"l=
tr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;=
mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"a=
01uKDa8DgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">ne...@eviloverlord.com</a><wbr>&gt; =C2=A0+1-847-691-1404</div></div></di=
v></div></div></div></div></blockquote><div><br></div><div>If we replace th=
e lambda in strided_iter by the following type, everything is ok :</div><di=
v><br></div><div><div>struct advance_t {</div><div>=C2=A0 =C2=A0 size_t ste=
p;</div><div>=C2=A0 =C2=A0 template&lt;typename I&gt;</div><div>=C2=A0 =C2=
=A0 I operator()(I i) const {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::ad=
vance(i, step);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return i;</div><div>=
=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 friend bool operator=3D=3D(advance_=
t const &amp;a, advance_t const&amp; b) {</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return a.step =3D=3D b.step;</div><div>=C2=A0 =C2=A0 }</div><div>=C2=
=A0 =C2=A0 // Not mandatory in the above example, but nice to have:</div><d=
iv>=C2=A0 =C2=A0 friend bool operator&lt;(advance_t const &amp;a, advance_t=
 const&amp; b) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return a.step &lt; b=
..step;</div><div>=C2=A0 =C2=A0 }</div><div>};</div></div><div><br></div><di=
v><div>template&lt;typename I&gt; // ForwardIterator I</div><div>auto strid=
ed_iter(I&amp;&amp; i, size_t step) {</div><div>=C2=A0 =C2=A0 return iter_t=
ransfo_t&lt;std::decay_t&lt;I&gt;, advance_t&gt;{std::forward&lt;I&gt;(i), =
{step}};</div><div>}</div></div><div><br></div><div><br></div><div>Regards,=
</div><div><br></div><div>Jeremy</div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l&#39;entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n&#39;=C3=AAtes pas le destinataire vis=C3=A9, vous=
 =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d&#39;en=
 aviser imm=C3=A9diatement l&#39;exp=C3=A9diteur et de supprimer toutes les=
 copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n&#39;=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n&#39;est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a06ba085-0637-46d9-8249-af668640c8b1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a06ba085-0637-46d9-8249-af668640c8b1=
%40isocpp.org</a>.<br />

------=_Part_166_294317760.1464339506758--

.

------=_Part_1064_1838790514.1464348947807
Content-Type: multipart/alternative;
 boundary="----=_Part_1065_119668715.1464348947807"

------=_Part_1065_119668715.1464348947807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B45=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8810:25:40=EF=BC=8CKlaim - Jo=C3=ABl Lamotte=E5=86=99=E9=
=81=93=EF=BC=9A
>
> I am looking for the reason why lambda expressions are explicitly
> not defining a default constructor (at least depending on the arguments=
=20
> constructors).
>
> I cannot find a specific reason for that so far.
> Does anyone here have a source about this point?
>
>
> Otherwise I would like to propose to add=20
>
>     ClosureType() =3D default;=20
>
> to the definition of the closure generated by a lambda, if it's not=20
> already proposed somewhere.
>
> This would help working with closures in generic context where we assume
> that the callable type is regular (it's not enough but it helps);
>
> For example with this kind of code:
>
>
> template< class T, class Callable >
> struct FatForwardIterator
> {
>   T value;
>   Callable incr; // deactivate the default constructor if it's a closure
>   //... etc
>
>   FatForwardIterator& operator++()
>   {
>     // ...
>     value =3D incr(value);
>     return *this;
>   }
> };
> // let's assume that the proposal to generate default comparisons is on..=
..
>
>
> template< class T, class Callable >
> auto make_fat_iterator( T initial_value, Callable incr )
> {
>   return FatForwardIterator<T, Callable>{ initial_value, incr };
> }
>
> template< class IteratorType>
> void some_algorithm( IteratorType begin, IteratorType end )
> {
>   IteratorType previous; // error: IteratorType do not have a default=20
> constructor.
>   do
>   {
>     previous =3D begin;
>     ++begin;
>     // ... use previous
>   }
>   while( begin !=3D end );
> }
>
>
> void foo()
> {
>   auto times2 =3D [](auto value){  return value * 2; };
>   auto begin =3D make_fat_iterator( 1, times2 );
>   auto end =3D make_fat_iterator( 8, times2 );
>
>   // ...=20
>   some_algorithm( begin, end ); // fails to compile
> }
>
>
> Why should an iterator be DefaultConstructible?
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bf3a6595-4e16-442e-a166-49faaef5c5d1%40isocpp.or=
g.

------=_Part_1065_119668715.1464348947807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B45=E6=9C=8824=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:25:40=EF=BC=8CKlaim - Jo=C3=
=ABl Lamotte=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr">I am looking for the reason why lambda expression=
s are explicitly<div>not defining a default constructor (at least depending=
 on the arguments constructors).</div><div><br></div><div>I cannot find a s=
pecific reason for that so far.</div><div>Does anyone here have a source ab=
out this point?</div><div><br></div><div><br></div><div>Otherwise I would l=
ike to propose to add=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0 ClosureT=
ype() =3D default;=C2=A0</div><div><br></div><div>to the definition of the =
closure generated by a lambda, if it&#39;s not already proposed somewhere.<=
/div><div><br></div><div>This would help working with closures in generic c=
ontext where we assume</div><div>that the callable type is regular (it&#39;=
s not enough but it helps);</div><div><br></div><div>For example with this =
kind of code:</div><div><br></div><div><div><br></div><div>template&lt; cla=
ss T, class Callable &gt;</div><div>struct FatForwardIterator</div><div>{</=
div><div>=C2=A0 T value;</div><div>=C2=A0 Callable incr; // deactivate the =
default constructor if it&#39;s a closure</div><div>=C2=A0 //... etc</div><=
div><br></div><div>=C2=A0 FatForwardIterator&amp; operator++()</div><div>=
=C2=A0 {</div><div>=C2=A0 =C2=A0 // ...</div><div>=C2=A0 =C2=A0 value =3D i=
ncr(value);</div><div>=C2=A0 =C2=A0 return *this;</div><div>=C2=A0 }</div><=
div>};</div><div>// let&#39;s assume that the proposal to generate default =
comparisons is on...</div><div><br></div><div><br></div><div><div>template&=
lt; class T, class Callable &gt;</div><div>auto make_fat_iterator( T initia=
l_value, Callable incr )</div><div>{</div><div>=C2=A0 return FatForwardIter=
ator&lt;T, Callable&gt;{ initial_value, incr };</div><div>}</div></div><div=
><br></div><div>template&lt; class IteratorType&gt;</div><div>void some_alg=
orithm( IteratorType begin, IteratorType end )</div><div>{</div><div>=C2=A0=
 IteratorType previous; // error: IteratorType do not have a default constr=
uctor.</div><div>=C2=A0 do</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 previ=
ous =3D begin;</div><div>=C2=A0 =C2=A0 ++begin;</div><div>=C2=A0 =C2=A0 // =
.... use previous</div><div>=C2=A0 }</div><div>=C2=A0 while( begin !=3D end =
);</div><div>}</div><div><br></div><div><br></div><div>void foo()</div><div=
>{</div><div>=C2=A0 auto times2 =3D [](auto value){ =C2=A0return value * 2;=
 };</div><div>=C2=A0 auto begin =3D make_fat_iterator( 1, times2 );</div><d=
iv>=C2=A0 auto end =3D make_fat_iterator( 8, times2 );</div><div><br></div>=
<div>=C2=A0 // ...=C2=A0</div><div>=C2=A0 some_algorithm( begin, end ); // =
fails to compile</div><div>}</div></div><div><br></div><div><br></div></div=
></blockquote><div>Why should an iterator be DefaultConstructible?<br>=C2=
=A0<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf3a6595-4e16-442e-a166-49faaef5c5d1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf3a6595-4e16-442e-a166-49faaef5c5d1=
%40isocpp.org</a>.<br />

------=_Part_1065_119668715.1464348947807--

------=_Part_1064_1838790514.1464348947807--

.

2016-05-27 13:35 GMT+02:00 FrankHB1989 <frankhb1989@gmail.com>:
>
>
> =E5=9C=A8 2016=E5=B9=B45=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8810:25:40=EF=BC=8CKlaim - Jo=C3=ABl Lamotte=E5=86=99=
=E9=81=93=EF=BC=9A
>>
>> I am looking for the reason why lambda expressions are explicitly
>> not defining a default constructor (at least depending on the arguments
>> constructors).
>>
>> I cannot find a specific reason for that so far.
>> Does anyone here have a source about this point?
>>
>>
>> Otherwise I would like to propose to add
>>
>>     ClosureType() =3D default;
>>
>> to the definition of the closure generated by a lambda, if it's not
>> already proposed somewhere.
>>
>> This would help working with closures in generic context where we assume
>> that the callable type is regular (it's not enough but it helps);
>>
>> For example with this kind of code:
>>
>>
>> template< class T, class Callable >
>> struct FatForwardIterator
>> {
>>   T value;
>>   Callable incr; // deactivate the default constructor if it's a closure
>>   //... etc
>>
>>   FatForwardIterator& operator++()
>>   {
>>     // ...
>>     value =3D incr(value);
>>     return *this;
>>   }
>> };
>> // let's assume that the proposal to generate default comparisons is on.=
...

[..]

>>
> Why should an iterator be DefaultConstructible?

There is no DefaultConstructible requirement for an InputIterator or
an OutputIterator, but there is one from ForwardIterator on (indicated
by the naming of the OPs types there seems to be a forward iterator
involved).

- Daniel

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGNvRgDVgNsm4RkDUZvH87fnV-XA727zKpNJqmqK4KVv8AH=
r6Q%40mail.gmail.com.

.

------=_Part_1102_1259695208.1464351015850
Content-Type: multipart/alternative;
 boundary="----=_Part_1103_932433405.1464351015851"

------=_Part_1103_932433405.1464351015851
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B45=E6=9C=8826=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=886:14:55=EF=BC=8Cjmo...@aldebaran.com=E5=86=99=E9=81=93=
=EF=BC=9A
>
>
>
> Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>> On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, jmo...@aldebaran.com=20
>> wrote:
>>>
>>> Le mercredi 25 mai 2016 01:31:42 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>>>>
>>>> On Tuesday, May 24, 2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:
>>>>>
>>>>> On Tue, May 24, 2016 at 9:39 AM, Viacheslav Usov <via....@gmail.com>=
=20
>>>>> wrote:
>>>>>>
>>>>>> Again. I cannot see how that motivates a need for default=20
>>>>>> constructible lambdas.
>>>>>>
>>>>>
>>>>> It's never strictly a need, it's just a convenience.
>>>>> [...]
>>>>> FWIW, even though I lean towards more consistency with other class=20
>>>>> types, I have only personally found default-construction for capturel=
ess=20
>>>>> lambdas to be desirable in my particular use-cases, and that's all th=
at I=20
>>>>> personally care for. Perhaps this is a more compelling example:
>>>>>
>>>>> // Use a lambda as a stateless deleter function
>>>>> std::unique_ptr<some_type, decltype([](some_type* ptr) {=20
>>>>> some_deletion_function(ptr); })> object(create_some_type());
>>>>>
>>>>
>>>> This is a use-case I have also encountered in the wild. I would very=
=20
>>>> much like this (lambdas in unevaluated contexts, default-construction =
of=20
>>>> captureless closure types) to Just Work.
>>>>
>>>> Default-construction of *captureful* close types seems 100% dangerous=
=20
>>>> and bad.
>>>>
>>>>     int main() {
>>>>         int y =3D 42;
>>>>         auto x =3D [z=3Dy](){ printf("%d\n", z); };
>>>>         decltype(x) x2;
>>>>         x2();  // does this print the "value" of a default-initialized=
=20
>>>> int? that's super dangerous!
>>>>     }
>>>>
>>>> We definitely shouldn't provide the user-programmer with any construct=
s=20
>>>> that allow him to shoot himself in the foot this badly, especially whe=
n=20
>>>> there's no motivating use-case for the feature.
>>>>
>>>
>>> See above for motivating examples.
>>> =20
>>>
>>>>
>>>> I would say that there's one minorly thought-provoking corner case in=
=20
>>>> between "captureless" and "captureful":
>>>>
>>>>     int main() {
>>>>         auto x =3D [z=3D42](){ printf("%d\n", z); };
>>>>         decltype(x) x2;  // ought this to compile?
>>>>         x2();  // ought this to print 42?
>>>>     }
>>>>
>>>> My opinion is that "no, it certainly oughtn't to print 42", based on m=
y=20
>>>> (correct?) belief that the meaning of [z=3DFOO] is not altered in any=
=20
>>>> way by whether or not FOO is a constant-expression. In my ideal world,=
=20
>>>> the above code would *refuse to compile*, because decltype(x) is quite=
=20
>>>> definitely a *captureful* closure type.
>>>>
>>>> =20
>>> As explained above, the default constructor of the lambda should rely o=
n=20
>>> the default constructor of its members (same as a user-defined type). T=
hus,=20
>>> the value of a default-constructed lambda would be meaningful depending=
 of=20
>>> the meaningfulness of the values of its default-constructed members.
>>>
>>
>> I don't think you're getting the point.
>>
>> If a lambda captures something, then the lambda function is either=20
>> written with the expectation that the capture will have the exact captur=
ed=20
>> value or it is not. If the function expects the value, then a default=20
>> constructed value of that type is *wrong* and will cause the function to=
=20
>> behave inappropriately.
>>
>>
> I'm not sure to follow you.
> If I write:
>
> std::string suffix{"abcd"};
> auto append =3D [=3D](std::string const& str) {return str + suffix;};
>
> I expect the generated lambda type to be roughly equivalent to :
>
> struct lambda_type {
>     std::string suffix;
>     lambda_type(std::string s) : suffix(std::move(s)) {}
>     auto operator()(std::string const& str) const {return str + suffix;}
> };
> // ...
> lambda_type append{"abcd"};
>
> Why adding a default constructor to lambda_type would be wrong ?
> The default-constructed string member would simply be empty.
> As explained before, the meaningfulness of a default constructed lambda=
=20
> would be dependent on the meaningfulness of its default constructed=20
> members. It is the responsability of the programmer to determine if the=
=20
> default constructed lambda is meaningful or not. Note that it would be th=
e=20
> exact same logic as for the default construction of any user-defined type=
=20
> and would thus be consistent with the rest of the language.
>
> Also note that in the case of an arithmetic type:
> int m{2};
> auto add =3D [=3D](int n) {return m + n;};
>
> I expect the generated lambda type to be roughly equivalent to :
>
> struct lambda_type2 {
>     int m;
>     lambda_type2(int m) : m(m) {}
>     auto operator()(int n) const {return m + n;}
> };
> // ...
> lambda_type2 add{2};
>
> In this case:
> lambda_type2 add; // not meaningful because int is not initialized (see=
=20
> above for "partially formed state")
> add =3D lambda_type2{2}; // Now ok (see the initial example for a=20
> motivation).
>
> With also this case:
> lambda_type2 add{}; // Ok: member initialized with empty braces, so value=
=20
> is 0.
>
> As noted Matt Calabrese, it's all about consistency. The current behaviou=
r=20
> of lambdas break the consistency with the equivalent user-defined types.=
=20
> When introducing a new feature in the language, it should be primordial t=
o=20
> ensure that it works well with the other existing mechanisms of the=20
> language, i.e. to ensure it doesn't break consistency.
>
It sounds absurd to require arbitrary data types having capability of=20
holding not-constructed/indeterminate state. For integer types that may be=
=20
reasonable because the allowed representations are required to be uniformly=
=20
mapped to the underlying storage in some predicable manners.
Note that allowing indeterminate value stored in object of such types is=20
already not consistent, e.g. reading uninitialized unsigned char vs. int.=
=20

>
> One of the fundamental mechanisms of the language is the ability to build=
=20
> new richer types based on existing types, by using existing types as=20
> members. This means that the capabilities of the new type depend on the=
=20
> capabilities of its members. For example, the new type is typically=20
> comparable only if all its members are comparable. Same thing for default=
=20
> construction. The consistency allows to reduce complexity (think of=20
> std::vector being able to store std::vector, without having to handle any=
=20
> special case because std::vector respects the same constrains that it put=
=20
> on its stored type).
>
> Strictly speaking, these existing types are ill-designed. Unless I'm=20
working on some particular forms of interop, I want optional<T> but not T*;=
=20
similarly, I better have some indeterminate<T> rather than T with=20
indeterminate state specified in subtle additional rules of the language. I=
=20
do not like to pay for what I deliberately don't want to have, because it=
=20
will distorts my intent and causes unnecessary mental cost.
=20

> So, if I design a new type in generic code and any Callable (sub)members=
=20
> happens to be a lambda, I have to drop default constructability. This see=
ms=20
> an artificial limitation, as the equivalent user-defined type to this=20
> lambda type would be fine.
> I'm talking here about default construction because it the topic of this=
=20
> proposal, but I think the case is even stronger for equality.
>
> Are you serious? Equality is not strictly necessary in every theories, bu=
t=20
any formal systems (e.g. set theories) being practical and general enough=
=20
will provide some sorts of it, otherwise you can't determine the identity=
=20
of things being described. (And for theories do not provide one, they will=
=20
rely on the base theories which provide it.) You may not use it explicitly=
=20
because the underlying system has implied it, for example, the C++ type=20
system (which is nominal) provides type equivalence (btw, sadly=20
std::is_same cannot be overloaded) being widely used in many contexts of=20
the language. To implement such a system using meta language (here it is=20
C++), an equality function is always needed, so it is better provided in a=
=20
standard form, to make the use consistent. On the other hand, the property=
=20
of "being constructible without parameters" or "having exact one=20
standardized undetermined state" is definitely not so general in both meta=
=20
languages and object languages. It is occasionally useful in C++ as an=20
object language because the default constructor is specified being one of=
=20
"special member functions", despite there is actually no need to make it=20
special like a copy constructor or a destructor because the=20
default-initialization is concerned with less contexts in the language=20
(mostly required due to being compatible with C).

Regards,
>
> Jeremy
> =20
>
>> There is *no way* to distinguish between these two cases. As such,=20
>> whether it is valid to default construct a lambda that captures values i=
s=20
>> not known and cannot be known. Therefore, permitting the default=20
>> construction of a capturing lambda creates fragile, brittle code.
>>
>> That's bad.
>>
>> This is like the rules of trivial copyability. It's possible to write=20
>> classes which violate the rules of trivial copyability yet still=20
>> technically could be. This is based on how the user-defined copy/move=20
>> operations work and what data is being stored. But despite this, we don'=
t=20
>> allow trivially copying them to be well-defined C++ behavior. We only al=
low=20
>> it to be well-defined in circumstances where we can be *certain* that=20
>> such copying will be reasonable, where we can *statically* determine if=
=20
>> it will always be legitimate.
>>
>> The same goes here. The only case where we can be certain that default=
=20
>> constructing a lambda will produce a valid lambda is if it is captureles=
s.
>>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/17e4246d-789e-4795-89be-48e6fb1598b4%40isocpp.or=
g.

------=_Part_1103_932433405.1464351015851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B45=E6=9C=8826=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=886:14:55=EF=BC=8Cjmo...@aldebar=
an.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><br><br>Le mercredi 25 mai 2016 17:35:14 UTC+2, Nicol B=
olas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">On Wednesday, May 25, 2016 at 5:10:29 AM UTC-4, <a>jmo...@aldebaran.c=
om</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Le me=
rcredi 25 mai 2016 01:31:42 UTC+2, Arthur O&#39;Dwyer a =C3=A9crit=C2=A0:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, May 24, =
2016 at 11:00:25 AM UTC-7, Matt Calabrese wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, May 2=
4, 2016 at 9:39 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a rel=3D"nofollo=
w">via....@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Again. I cannot see how=
 that motivates a need for default constructible lambdas.</div></div></div>=
</div></blockquote><div><br></div><div>It&#39;s never strictly a need, it&#=
39;s just a convenience.</div><div>[...]</div><div>FWIW, even though I lean=
 towards more consistency with other class types, I have only personally fo=
und default-construction for captureless lambdas to be desirable in my part=
icular use-cases, and that&#39;s all that I personally care for. Perhaps th=
is is a more compelling example:</div><div><br></div><div>// Use a lambda a=
s a stateless deleter function</div><div>std::unique_ptr&lt;some_type, decl=
type([](some_type* ptr) { some_deletion_function(ptr); })&gt; object(create=
_some_type());</div></div></div></div></blockquote><div><br></div><div>This=
 is a use-case I have also encountered in the wild. I would very much like =
this (lambdas in unevaluated contexts, default-construction of captureless =
closure types) to Just Work.</div><div><br></div><div>Default-construction =
of <b><i>captureful</i></b> close types seems 100% dangerous and bad.</div>=
<div><br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int=
 main() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 int y =3D 42;</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3Dy](){ printf(&quot;=
%d\n&quot;, z); };</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2;</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// does thi=
s print the &quot;value&quot; of a default-initialized int? that&#39;s supe=
r dangerous!</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 }</font></div><div><br></div><div>We definitely shouldn&#39;t provid=
e the user-programmer with any constructs that allow him to shoot himself i=
n the foot this badly, especially when there&#39;s no motivating use-case f=
or the feature.</div></div></blockquote><div><br></div><div>See above for m=
otivating examples.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><br></div><div>I would say that there&#39;s on=
e minorly thought-provoking corner case in between &quot;captureless&quot; =
and &quot;captureful&quot;:</div><div><br></div><div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 int main() {</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D [z=3D42]=
(){ printf(&quot;%d\n&quot;, z); };<br></font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(x) x2; =C2=A0// ou=
ght this to compile?</font></div><div><font face=3D"courier new, monospace"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 x2(); =C2=A0// ought this to print 42?</font><=
/div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div=
></div><div><br></div><div>My opinion is that &quot;no, it certainly oughtn=
&#39;t to print 42&quot;, based on my (correct?) belief that the meaning of=
 <font face=3D"courier new, monospace">[z=3DFOO]</font> is not altered in a=
ny way by whether or not <font face=3D"courier new, monospace">FOO</font> i=
s a constant-expression. In my ideal world, the above code would <i><b>refu=
se to compile</b></i>, because <font face=3D"courier new, monospace">declty=
pe(x)</font> is quite definitely a <i><b>captureful</b></i> closure type.</=
div><div><br></div></div></blockquote><div>=C2=A0</div><div>As explained ab=
ove, the default constructor of the lambda should rely on the default const=
ructor of its members (same as a user-defined type). Thus, the value of a d=
efault-constructed lambda would be meaningful depending of the meaningfulne=
ss of the values of its default-constructed members.</div></div></blockquot=
e><div><br>I don&#39;t think you&#39;re getting the point.<br><br>If a lamb=
da captures something, then the lambda function is either written with the =
expectation that the capture will have the exact captured value or it is no=
t. If the function expects the value, then a default constructed value of t=
hat type is <b>wrong</b> and will cause the function to behave inappropriat=
ely.<br><br></div></div></blockquote><div><br></div><div><div style=3D"font=
-family:arial,sans-serif;font-size:12.8px">I&#39;m not sure to follow you.<=
/div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">If I writ=
e:</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></=
div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">std::strin=
g suffix{&quot;abcd&quot;};</div><div style=3D"font-family:arial,sans-serif=
;font-size:12.8px">auto append =3D [=3D](std::string const&amp; str) {retur=
n str + suffix;};</div><div style=3D"font-family:arial,sans-serif;font-size=
:12.8px"><br></div><div style=3D"font-family:arial,sans-serif;font-size:12.=
8px">I expect the generated lambda type to be roughly equivalent to :</div>=
<div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div=
 style=3D"font-family:arial,sans-serif;font-size:12.8px">struct lambda_type=
 {</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0=
 =C2=A0 std::string suffix;</div><div style=3D"font-family:arial,sans-serif=
;font-size:12.8px">=C2=A0 =C2=A0 lambda_type(std::string s) : suffix(std::m=
ove(s)) {}</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px=
">=C2=A0 =C2=A0 auto operator()(std::string const&amp; str) const {return s=
tr + suffix;}</div><div style=3D"font-family:arial,sans-serif;font-size:12.=
8px">};</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">/=
/ ...</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">lam=
bda_type append{&quot;abcd&quot;};</div><div style=3D"font-family:arial,san=
s-serif;font-size:12.8px"><br></div><div style=3D"font-family:arial,sans-se=
rif;font-size:12.8px">Why adding a default constructor to lambda_type would=
 be wrong ?</div><div style=3D"font-family:arial,sans-serif;font-size:12.8p=
x">The default-constructed string member would simply be empty.</div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px">As explained before,=
 the meaningfulness of a default constructed lambda would be dependent on t=
he meaningfulness of its default constructed members. It is the responsabil=
ity of the programmer to determine if the default constructed lambda is mea=
ningful or not. Note that it would be the exact same logic as for the defau=
lt construction of any user-defined type and would thus be consistent with =
the rest of the language.</div><div style=3D"font-family:arial,sans-serif;f=
ont-size:12.8px"><br></div><div style=3D"font-family:arial,sans-serif;font-=
size:12.8px">Also note that in the case of an arithmetic type:</div><div st=
yle=3D"font-family:arial,sans-serif;font-size:12.8px">int m{2};</div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px">auto add =3D [=3D](i=
nt n) {return m + n;};</div><div style=3D"font-family:arial,sans-serif;font=
-size:12.8px"><br></div><div style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">I expect the generated lambda type to be roughly equivalent to :<=
/div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div=
><div style=3D"font-family:arial,sans-serif;font-size:12.8px">struct lambda=
_type2 {</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">=
=C2=A0 =C2=A0 int m;</div><div style=3D"font-family:arial,sans-serif;font-s=
ize:12.8px">=C2=A0 =C2=A0 lambda_type2(int m) : m(m) {}</div><div style=3D"=
font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0 auto operator(=
)(int n) const {return m + n;}</div><div style=3D"font-family:arial,sans-se=
rif;font-size:12.8px">};</div><div style=3D"font-family:arial,sans-serif;fo=
nt-size:12.8px">// ...</div><div style=3D"font-family:arial,sans-serif;font=
-size:12.8px">lambda_type2 add{2};</div><div style=3D"font-family:arial,san=
s-serif;font-size:12.8px"><br></div><div style=3D"font-family:arial,sans-se=
rif;font-size:12.8px">In this case:</div><div style=3D"font-family:arial,sa=
ns-serif;font-size:12.8px">lambda_type2 add; // not meaningful because int =
is not initialized (see above for &quot;partially formed state&quot;)</div>=
<div style=3D"font-family:arial,sans-serif;font-size:12.8px">add =3D lambda=
_type2{2}; // Now ok (see the initial example for a motivation).</div><div =
style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div styl=
e=3D"font-family:arial,sans-serif;font-size:12.8px">With also this case:</d=
iv><div style=3D"font-family:arial,sans-serif;font-size:12.8px">lambda_type=
2 add{}; // Ok: member initialized with empty braces, so value is 0.</div><=
div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div =
style=3D"font-family:arial,sans-serif;font-size:12.8px">As noted Matt Calab=
rese, it&#39;s all about consistency. The current behaviour of lambdas brea=
k the consistency with the equivalent user-defined types. When introducing =
a new feature in the language, it should be primordial to ensure that it wo=
rks well with the other existing mechanisms of the language, i.e. to ensure=
 it doesn&#39;t break consistency.</div></div></div></blockquote><div>It so=
unds absurd to require arbitrary data types having capability of holding no=
t-constructed/indeterminate state. For integer types that may be reasonable=
 because the allowed representations are required to be uniformly mapped to=
 the underlying storage in some predicable manners.<br></div><div>Note that=
 allowing indeterminate value stored in object of such types is already not=
 consistent, e.g. reading uninitialized unsigned char vs. int. <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 dir=3D"ltr"><div><div style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><br></div><div style=3D"=
font-family:arial,sans-serif;font-size:12.8px"><div>One of the fundamental =
mechanisms of the language is the ability to build new richer types based o=
n existing types, by using existing types as members. This means that the c=
apabilities of the new type depend on the capabilities of its members. For =
example, the new type is typically comparable only if all its members are c=
omparable. Same thing for default construction. The consistency allows to r=
educe complexity (think of std::vector being able to store std::vector, wit=
hout having to handle any special case because std::vector respects the sam=
e constrains that it put on its stored type).</div><div><br></div></div></d=
iv></div></blockquote><div>Strictly speaking, these existing types are ill-=
designed. Unless I&#39;m working on some particular forms of interop, I wan=
t optional&lt;T&gt; but not T*; similarly, I better have some indeterminate=
&lt;T&gt; rather than T with indeterminate state specified in subtle additi=
onal rules of the language. I do not like to pay for what I deliberately do=
n&#39;t want to have, because it will distorts my intent and causes unneces=
sary mental cost.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px"><div></div><div>So, if I design a new type in generic code a=
nd any Callable (sub)members happens to be a lambda, I have to drop default=
 constructability. This seems an artificial limitation, as the equivalent u=
ser-defined type to this lambda type would be fine.</div><div>I&#39;m talki=
ng here about default construction because it the topic of this proposal, b=
ut I think the case is even stronger for equality.</div><div><br></div></di=
v></div></div></blockquote><div>Are you serious? Equality is not strictly n=
ecessary in every theories, but any formal systems (e.g. set theories) bein=
g practical and general enough will provide some sorts of it, otherwise you=
 can&#39;t determine the identity of things being described. (And for theor=
ies do not provide one, they will rely on the base theories which provide i=
t.) You may not use it explicitly because the underlying system has implied=
 it, for example, the C++ type system (which is nominal) provides type equi=
valence (btw, sadly std::is_same cannot be overloaded) being widely used in=
 many contexts of the language. To implement such a system using meta langu=
age (here it is C++), an equality function is always needed, so it is bette=
r provided in a standard form, to make the use consistent. On the other han=
d, the property of &quot;being constructible without parameters&quot; or &q=
uot;having exact one standardized undetermined state&quot; is definitely no=
t so general in both meta languages and object languages. It is occasionall=
y useful in C++ as an object language because the default constructor is sp=
ecified being one of &quot;special member functions&quot;, despite there is=
 actually no need to make it special like a copy constructor or a destructo=
r because the default-initialization is concerned with less contexts in the=
 language (mostly required due to being compatible with C).<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 dir=3D"ltr"><div><div style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><div></div><div>Regards,=
</div><div><br></div><div>Jeremy</div></div></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> There is <i>no way</=
i> to distinguish between these two cases. As such, whether it is valid to =
default construct a lambda that captures values is not known and cannot be =
known. Therefore, permitting the default construction of a capturing lambda=
 creates fragile, brittle code.<br><br>That&#39;s bad.<br><br>This is like =
the rules of trivial copyability. It&#39;s possible to write classes which =
violate the rules of trivial copyability yet still technically could be. Th=
is is based on how the user-defined copy/move operations work and what data=
 is being stored. But despite this, we don&#39;t allow trivially copying th=
em to be well-defined C++ behavior. We only allow it to be well-defined in =
circumstances where we can be <i>certain</i> that such copying will be reas=
onable, where we can <i>statically</i> determine if it will always be legit=
imate.<br><br>The same goes here. The only case where we can be certain tha=
t default constructing a lambda will produce a valid lambda is if it is cap=
tureless.<br></div></div></blockquote></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17e4246d-789e-4795-89be-48e6fb1598b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17e4246d-789e-4795-89be-48e6fb1598b4=
%40isocpp.org</a>.<br />

------=_Part_1103_932433405.1464351015851--

------=_Part_1102_1259695208.1464351015850--

.

------=_Part_1105_80562956.1464353064314
Content-Type: multipart/alternative;
 boundary="----=_Part_1106_1011048283.1464353064314"

------=_Part_1106_1011048283.1464353064314
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B45=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=887:41:19=EF=BC=8CDaniel Kr=C3=BCgler=E5=86=99=E9=81=93=
=EF=BC=9A
>
> 2016-05-27 13:35 GMT+02:00 FrankHB1989 <frank...@gmail.com <javascript:>>=
:=20
>
> >=20
> >=20
> > =E5=9C=A8 2016=E5=B9=B45=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=
 UTC+8=E4=B8=8B=E5=8D=8810:25:40=EF=BC=8CKlaim - Jo=C3=ABl Lamotte=E5=86=99=
=E9=81=93=EF=BC=9A=20
> >>=20
> >> I am looking for the reason why lambda expressions are explicitly=20
> >> not defining a default constructor (at least depending on the argument=
s=20
> >> constructors).=20
> >>=20
> >> I cannot find a specific reason for that so far.=20
> >> Does anyone here have a source about this point?=20
> >>=20
> >>=20
> >> Otherwise I would like to propose to add=20
> >>=20
> >>     ClosureType() =3D default;=20
> >>=20
> >> to the definition of the closure generated by a lambda, if it's not=20
> >> already proposed somewhere.=20
> >>=20
> >> This would help working with closures in generic context where we=20
> assume=20
> >> that the callable type is regular (it's not enough but it helps);=20
> >>=20
> >> For example with this kind of code:=20
> >>=20
> >>=20
> >> template< class T, class Callable >=20
> >> struct FatForwardIterator=20
> >> {=20
> >>   T value;=20
> >>   Callable incr; // deactivate the default constructor if it's a=20
> closure=20
> >>   //... etc=20
> >>=20
> >>   FatForwardIterator& operator++()=20
> >>   {=20
> >>     // ...=20
> >>     value =3D incr(value);=20
> >>     return *this;=20
> >>   }=20
> >> };=20
> >> // let's assume that the proposal to generate default comparisons is=
=20
> on...=20
>
> [..]=20
>
> >>=20
> > Why should an iterator be DefaultConstructible?=20
>
> There is no DefaultConstructible requirement for an InputIterator or=20
> an OutputIterator, but there is one from ForwardIterator on (indicated=20
> by the naming of the OPs types there seems to be a forward iterator=20
> involved).=20
>
> Yes, I should mean that specifically for forward iterators. However, for=
=20
iterators mostly used (e.g. as member type of containers), they have to=20
meet the requirement of being DefaultConstructible. Note forward iterators=
=20
are required to be value-initialized to be a general pass-the-end indicator=
=20
of an empty sequence which I find no algorithms relies on; I think it=20
superfluous.=20

> - Daniel=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ea49fc91-9018-4a83-9541-4739deab8774%40isocpp.or=
g.

------=_Part_1106_1011048283.1464353064314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B45=E6=9C=8827=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=887:41:19=EF=BC=8CDaniel Kr=C3=
=BCgler=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">2016-05-27 13:35 GMT+02:00 FrankHB1989 &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"nufn0BgADwAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">frank...@gmail.com</a>&gt;:
<br>&gt;
<br>&gt;
<br>&gt; =E5=9C=A8 2016=E5=B9=B45=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:25:40=EF=BC=8CKlaim - Jo=C3=ABl Lamotte=E5=
=86=99=E9=81=93=EF=BC=9A
<br>&gt;&gt;
<br>&gt;&gt; I am looking for the reason why lambda expressions are explici=
tly
<br>&gt;&gt; not defining a default constructor (at least depending on the =
arguments
<br>&gt;&gt; constructors).
<br>&gt;&gt;
<br>&gt;&gt; I cannot find a specific reason for that so far.
<br>&gt;&gt; Does anyone here have a source about this point?
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Otherwise I would like to propose to add
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 ClosureType() =3D default;
<br>&gt;&gt;
<br>&gt;&gt; to the definition of the closure generated by a lambda, if it&=
#39;s not
<br>&gt;&gt; already proposed somewhere.
<br>&gt;&gt;
<br>&gt;&gt; This would help working with closures in generic context where=
 we assume
<br>&gt;&gt; that the callable type is regular (it&#39;s not enough but it =
helps);
<br>&gt;&gt;
<br>&gt;&gt; For example with this kind of code:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; template&lt; class T, class Callable &gt;
<br>&gt;&gt; struct FatForwardIterator
<br>&gt;&gt; {
<br>&gt;&gt; =C2=A0 T value;
<br>&gt;&gt; =C2=A0 Callable incr; // deactivate the default constructor if=
 it&#39;s a closure
<br>&gt;&gt; =C2=A0 //... etc
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 FatForwardIterator&amp; operator++()
<br>&gt;&gt; =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 value =3D incr(value);
<br>&gt;&gt; =C2=A0 =C2=A0 return *this;
<br>&gt;&gt; =C2=A0 }
<br>&gt;&gt; };
<br>&gt;&gt; // let&#39;s assume that the proposal to generate default comp=
arisons is on...
<br>
<br>[..]
<br>
<br>&gt;&gt;
<br>&gt; Why should an iterator be DefaultConstructible?
<br>
<br>There is no DefaultConstructible requirement for an InputIterator or
<br>an OutputIterator, but there is one from ForwardIterator on (indicated
<br>by the naming of the OPs types there seems to be a forward iterator
<br>involved).
<br>
<br></blockquote><div>Yes, I should mean that specifically for forward iter=
ators. However, for iterators mostly used (e.g. as member type of container=
s), they have to meet the requirement of being DefaultConstructible. Note f=
orward iterators are required to be value-initialized to be a general pass-=
the-end indicator of an empty sequence which I find no algorithms relies on=
; I think it superfluous. <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">- Daniel
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea49fc91-9018-4a83-9541-4739deab8774%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea49fc91-9018-4a83-9541-4739deab8774=
%40isocpp.org</a>.<br />

------=_Part_1106_1011048283.1464353064314--

------=_Part_1105_80562956.1464353064314--

.

------=_Part_172_889389601.1464362976913
Content-Type: multipart/alternative;
 boundary="----=_Part_173_1980715343.1464362976915"

------=_Part_173_1980715343.1464362976915
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, May 27, 2016 at 4:58:26 AM UTC-4, jmo...@aldebaran.com wrote:
>
> Le jeudi 26 mai 2016 16:57:18 UTC+2, Nevin ":-)" Liber a =C3=A9crit :
>>
>> On 26 May 2016 at 05:14, <jmo...@aldebaran.com> wrote:
>>
>>>
>>> std::string suffix{"abcd"};
>>> auto append =3D [=3D](std::string const& str) {return str + suffix;};
>>>
>>> I expect the generated lambda type to be roughly equivalent to :
>>>
>>> struct lambda_type {
>>>     std::string suffix;
>>>     lambda_type(std::string s) : suffix(std::move(s)) {}
>>>     auto operator()(std::string const& str) const {return str + suffix;=
}
>>> };
>>> // ...
>>> lambda_type append{"abcd"};
>>>
>>
>> Why wouldn't I just create a different lambda if I wanted to append to=
=20
>> nothing as opposed to appending to a captured string?
>>
>> Again, I'm not seeing why having a lambda with only two possible states=
=20
>> is all that useful, especially in generic code.
>>
>
> See the example below.
> =20
>
>>
>> Yes, I know you can abuse a mutable function call operator to add more=
=20
>> states, but that is an awfully convoluted way to get around writing a cl=
ass.
>> =20
>>
>>> As noted Matt Calabrese, it's all about consistency. The current=20
>>> behaviour of lambdas break the consistency with the equivalent user-def=
ined=20
>>> types.
>>>
>>
>> Huh?  UDTs are not required to be default constructible.  UDTs typically=
=20
>> can have far more than two states.=20
>>
> =20
>>
>>> One of the fundamental mechanisms of the language is the ability to=20
>>> build new richer types based on existing types, by using existing types=
 as=20
>>> members.=20
>>>
>>
>> Which is not the intention of lambdas.  How do you envision using a=20
>> capturing lambda (default constructed or not) as an aggregate member of=
=20
>> another type?  Please post a code example of what you want to work in th=
is=20
>> case.
>>
>
> Here is an more complex example that should compile. I hope this will=20
> answer your questions.
> It's useful to default construct I in find_last.
>

So you have a type `iter_transfo_t` which needs to be default=20
constructible. But that type needs to store something which is decidedly=20
not default constructible. The only saving grace of this concept is that,=
=20
while default constructing ForwardIterators is legal, it's not legal to=20
actually do anything with them without copying into them. So just work=20
around the limitation. If `F` is default constructible, then use it. If `F`=
=20
is not, then don't store `F` directly. Use a `std::function` or a=20
lighter-weight wrapper which is default constructible. Here's one example=
=20
of such a wrapper:

template<typename T>
class DefaultConstructible
{
public:
    DefaultConstructible() =3D default;
   =20
    DefaultConstructible(const DefaultConstructible &other)
        : t(new(&t_data) T(other) {}
    DefaultConstructible(DefaultConstructible &&other)
        : t(new(&t_data) T(std::move(other)) {}
    const DefaultConstructible &operator=3D(const DefaultConstructible &oth=
er)
    {
        if(t)
        {
            if(other.t)
                *t =3D *other.t;
            else
            {
                t->~T();
                t =3D nullptr;
            }
        }
        else
        {
            if(other.t)
                t =3D new(&t_data) T(*other.t);
        }
        return *this;
    }
    const DefaultConstructible &operator=3D(DefaultConstructible &&other)
    {
        if(t)
        {
            if(other.t)
                *t =3D std::move(*other.t);
            else
            {
                t->~T();
                t =3D nullptr;
            }
        }
        else
        {
            if(other.t)
                t =3D new(&t_data) T(std::move(*other.t));
        }
        return *this;
    }
   =20
    operator T*() {return t;}
    operator const T*() const {return t;}
   =20
    T& operator*() {return *t;}
    const T& operator*() {return *t;}
   =20
    //SFINAE protect if DefaultCosntructible is not equality comparable.
    bool operator=3D=3D(const DefaultConstructible &rhs) const
    {
        if(t && rhs.t)
            return *t =3D=3D *rhs.t;
       =20
        return false; //If one of them doesn't have a proper value yet, you=
=20
can't compare them reasonably.
    }
   =20
    //Add other comparisons as needed.

    ~DefaultConstructible() {if(t) t->~T();}
   =20
private:
    std::aligned_storage<sizeof(T), alignof(T)>::type t_data;
    T *t =3D nullptr;
};

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56e840d4-2b87-41d3-81a4-4b9cca700c97%40isocpp.or=
g.

------=_Part_173_1980715343.1464362976915
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 27, 2016 at 4:58:26 AM UTC-4, jmo...@aldeba=
ran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Le jeudi 26 mai 2016 16:57:18 UTC+2, Nevin &quot;:-)&quot; Liber a =C3=A9c=
rit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On 26 Ma=
y 2016 at 05:14,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmo...@aldebara=
n.com</a>&gt;</span> wrote:<br><div><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"><div dir=3D"ltr"><div><div><br><span style=3D"font-size:=
12.8px;color:rgb(34,34,34)">std::string suffix{&quot;abcd&quot;};</span><br=
></div></div><div><div style=3D"font-family:arial,sans-serif;font-size:12.8=
px">auto append =3D [=3D](std::string const&amp; str) {return str + suffix;=
};</div><div style=3D"font-family:arial,sans-serif;font-size:12.8px"><br></=
div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">I expect t=
he generated lambda type to be roughly equivalent to :</div><div style=3D"f=
ont-family:arial,sans-serif;font-size:12.8px"><br></div><div style=3D"font-=
family:arial,sans-serif;font-size:12.8px">struct lambda_type {</div><div st=
yle=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0 std::st=
ring suffix;</div><div style=3D"font-family:arial,sans-serif;font-size:12.8=
px">=C2=A0 =C2=A0 lambda_type(std::string s) : suffix(std::move(s)) {}</div=
><div style=3D"font-family:arial,sans-serif;font-size:12.8px">=C2=A0 =C2=A0=
 auto operator()(std::string const&amp; str) const {return str + suffix;}</=
div><div style=3D"font-family:arial,sans-serif;font-size:12.8px">};</div><d=
iv style=3D"font-family:arial,sans-serif;font-size:12.8px">// ...</div><div=
 style=3D"font-family:arial,sans-serif;font-size:12.8px">lambda_type append=
{&quot;abcd&quot;};</div></div></div></blockquote><div><br></div><div>Why w=
ouldn&#39;t I just create a different lambda if I wanted to append to nothi=
ng as opposed to appending to a captured string?</div><div><br></div><div>A=
gain, I&#39;m not seeing why having a lambda with only two possible states =
is all that useful, especially in generic code.</div></div></div></div></bl=
ockquote><div><br></div><div>See the example below.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div><br></div><div>Yes, I know you can abuse a mutable functi=
on call operator to add more states, but that is an awfully convoluted way =
to get around writing a class.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif;f=
ont-size:12.8px"><span style=3D"font-size:12.8px">As noted Matt Calabrese, =
it&#39;s all about consistency. The current behaviour of lambdas break the =
consistency with the equivalent user-defined types.</span></div></div></div=
></blockquote><div><br></div><div>Huh?=C2=A0 UDTs are not required to be de=
fault constructible.=C2=A0 UDTs typically can have far more than two states=
..=C2=A0</div></div></div></div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div style=3D"font-fam=
ily:arial,sans-serif;font-size:12.8px"><div>One of the fundamental mechanis=
ms of the language is the ability to build new richer types based on existi=
ng types, by using existing types as members. </div></div></div></div></blo=
ckquote><div><br></div><div>Which is not the intention of lambdas.=C2=A0 Ho=
w do you envision using a capturing lambda (default constructed or not) as =
an aggregate member of another type?=C2=A0 Please post a code example of wh=
at you want to work in this case.</div></div></div></div></blockquote><div>=
<br></div><div>Here is an more complex example that should compile. I hope =
this will answer your questions.</div><div>It&#39;s useful to default const=
ruct I in find_last.</div></div></blockquote><div><br>So you have a type `i=
ter_transfo_t` which needs to be default constructible. But that type needs=
 to store something which is decidedly not default constructible. The only =
saving grace of this concept is that, while default constructing ForwardIte=
rators is legal, it&#39;s not legal to actually do anything with them witho=
ut copying into them. So just work around the limitation. If `F` is default=
 constructible, then use it. If `F` is not, then don&#39;t store `F` direct=
ly. Use a `std::function` or a lighter-weight wrapper which is default cons=
tructible. Here&#39;s one example of such a wrapper:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">DefaultConstructible</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">public=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">DefaultCons=
tructible</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">default</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">DefaultConstructible=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">DefaultConstructible</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">other</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">new</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">t_data</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">other</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #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"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">DefaultConstructible</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">DefaultConstructible</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">new</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">t_data</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">move</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">other</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">DefaultConstruct=
ible</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">DefaultConstructible</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">t </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">other</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 t</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">-&gt;~</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">else</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t </span><spa=
n 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=
: #008;" class=3D"styled-by-prettify">new</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">t_data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">o=
ther</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">t</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</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: #008;" class=3D"styled-by-prettify">this</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">DefaultConstructible</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D(</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">DefaultConstructible</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">other</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">t </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">othe=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">t</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 t</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">-&gt;~</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">nullptr</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">other</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">new</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(&amp;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">t_data</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">move</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">other</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">const</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: #008;" class=3D"styled-by-prettify">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0=
 =C2=A0 T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</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">t</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*()</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//SFINAE protect if DefaultCosntructible is not equality compar=
able.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">DefaultConstructible</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">rhs</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</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">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> rhs</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=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">rhs</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//If one of them doesn&#39;t have a proper value yet, yo=
u can&#39;t compare them reasonably.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">//Add other comparisons =
as needed.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">~</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">DefaultConstructible</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">t</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">-&gt;~</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">();}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 <br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">private</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">aligned_storage</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">alignof</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)&gt;::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">type t_data</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 T </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">t </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">nullptr</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span></div></code></div></div=
><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56e840d4-2b87-41d3-81a4-4b9cca700c97%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/56e840d4-2b87-41d3-81a4-4b9cca700c97=
%40isocpp.org</a>.<br />

------=_Part_173_1980715343.1464362976915--

------=_Part_172_889389601.1464362976913--

.