------=_Part_528_1826729847.1433961889851
Content-Type: multipart/alternative;
 boundary="----=_Part_529_1422321017.1433961889851"

------=_Part_529_1422321017.1433961889851
Content-Type: text/plain; charset=UTF-8



What you guys think of that new proposed keywords (like
 await/yield/mirrored/resumable) could be somehow prefixed with std::
namespace ?

I don't how hard is to make the compiler understand "std::await" as a
single "token" or "special token" or "special composed token", this way we
will not break old code introducing new "keywords".




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><br></div><div><br></div><div>What you guys think of =
that new proposed keywords (like &nbsp;await/yield/mirrored/resumable) coul=
d be somehow prefixed with std:: namespace ?&nbsp;</div><div><br></div><div=
>I don't how hard is to make the compiler understand "std::await" as a sing=
le "token" or "special token" or "special composed token", this way we will=
 not break old code introducing new "keywords".</div><div><br></div><div><b=
r></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_529_1422321017.1433961889851--
------=_Part_528_1826729847.1433961889851--

.

On 06/10/2015 08:44 PM, Cleiton Santoia wrote:
>
>
> What you guys think of that new proposed keywords (like
> await/yield/mirrored/resumable) could be somehow prefixed with std::
> namespace ?

While it could certainly work implementation-wise, I'm opposed.
Language keywords are different from standard library facilities.

(Regarding coroutines / resumable functions, I'm not yet sure we've
found the right (minimal) core language design here.  The amount
of behind-the-scenes library interaction for Gor's coroutines
proposal is ... frighteningly large.)

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

(Regarding coroutines / resumable functions, I'm not yet sure we've
> found the right (minimal) core language design here.  The amount
> of behind-the-scenes library interaction for Gor's coroutines
> proposal is ... frighteningly large.)
>

AFAIK Christopher Kohlhoff will introduce a new paper in the next meeting.
I always found
Christopher's solution easier to reason about. Less magic, more
straightforward.
With this I do not mean Gor's solution is bad. I just think it is too
"heavy" to reason about.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
(Regarding coroutines / resumable functions, I&#39;m not yet sure we&#39;ve=
<br>
found the right (minimal) core language design here.=C2=A0 The amount<br>
of behind-the-scenes library interaction for Gor&#39;s coroutines<br>
proposal is ... frighteningly large.)<br></blockquote><div><br></div><div>A=
FAIK Christopher Kohlhoff will introduce a new paper in the next meeting. I=
 always found</div><div>Christopher&#39;s solution easier to reason about. =
Less magic, more straightforward.</div><div>With this I do not mean Gor&#39=
;s solution is bad. I just think it is too &quot;heavy&quot; to reason abou=
t.=C2=A0</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114294787105a305188bfa3f--

.

> On 2015=E2=80=9306=E2=80=9315, at 6:32 PM, Germ=C3=A1n Diago <germandiago=
@gmail.com> wrote:
>=20
> AFAIK Christopher Kohlhoff will introduce a new paper in the next meeting=
.. I always found
> Christopher's solution easier to reason about. Less magic, more straightf=
orward.
> With this I do not mean Gor's solution is bad. I just think it is too "he=
avy" to reason about.=20

That=E2=80=99s good to hear=E2=80=A6 I=E2=80=99m really hoping for a good m=
igration path from switch/case-style coroutines, and minimal overhead.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 15 June 2015 at 17:22, David Krauss <potswa@mac.com> wrote:
>
>> On 2015=E2=80=9306=E2=80=9315, at 6:32 PM, Germ=C3=A1n Diago <germandiag=
o@gmail.com> wrote:
>>
>> AFAIK Christopher Kohlhoff will introduce a new paper in the next meetin=
g. I always found
>> Christopher's solution easier to reason about. Less magic, more straight=
forward.
>> With this I do not mean Gor's solution is bad. I just think it is too "h=
eavy" to reason about.
>
> That=E2=80=99s good to hear=E2=80=A6 I=E2=80=99m really hoping for a good=
 migration path from switch/case-style coroutines, and minimal overhead.


Depends on what kind of "overhead" you're talking about. Gor and Chris
are proposing two
fairly different things. Gor's coroutines incur little performance
overhead, and suspend up.
I don't know exactly how much overhead Chris's coroutines incur, but
they suspend down.

The former has strong emphasis on performance at the cost of the
coroutine return type
being "viral", the latter avoids the "viral" aspect at some cost of perform=
ance.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

Both proposals a stackless - unfortunately, and in contrast to the
statements of the committee at Urbana meeting, stackful coroutines were
completely ignored in Lenexa, so that a special kind of problems remain
unresolved.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>Both proposals a stackless - unfortunately, and in co=
ntrast to the statements of the committee at Urbana meeting, stackful corou=
tines were completely ignored in Lenexa, so that a special kind of problems=
 remain unresolved.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1137bd6062af450518916947--

.

On 15 June 2015 at 20:01, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> Both proposals a stackless - unfortunately, and in contrast to the
> statements of the committee at Urbana meeting, stackful coroutines were
> completely ignored in Lenexa, so that a special kind of problems remain
> unresolved.


They weren't ignored, but EWG didn't have time to look at them in more
detail. We did
look at Chris's newest proposal, but not your newest proposal. We will
look at coroutine
proposals in EWG in Kona, possibly jointly with SG1, or by inviting
interested SG1 people.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I'm opposed to this idea as well.

Referring to core language features through "std::" just doesn't make sense=
, since they are (should) be independent from standard library features. Do=
n't forget that there are environments (kernel/embedded development) where =
you frequently don't have access to a standard library implementation at al=
l. In these cases "std::" would make even less sense or may even be confusi=
ng.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_4296_1708330047.1434397334693--

.

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

Aren't std::move, std::forward, std::initializer_list examples of core
syntactic features that are in the std:: namespace? Initializer_list is a
weird half-way thing, where you can create one via core language syntax,
but need to include the header to declare it.

On Mon, Jun 15, 2015 at 12:42 PM, Max Truxa <me@maxtruxa.com> wrote:

> I'm opposed to this idea as well.
>
> Referring to core language features through "std::" just doesn't make
> sense, since they are (should) be independent from standard library
> features. Don't forget that there are environments (kernel/embedded
> development) where you frequently don't have access to a standard library
> implementation at all. In these cases "std::" would make even less sense or
> may even be confusing.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Aren&#39;t std::move, std::forward, std::initializer_list =
examples of core syntactic features that are in the std:: namespace? Initia=
lizer_list is a weird half-way thing, where you can create one via core lan=
guage syntax, but need to include the header to declare it.</div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jun 15, 2015 at 12:=
42 PM, Max Truxa <span dir=3D"ltr">&lt;<a href=3D"mailto:me@maxtruxa.com" t=
arget=3D"_blank">me@maxtruxa.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I&#39;m opposed to this idea as well.<br>
<br>
Referring to core language features through &quot;std::&quot; just doesn&#3=
9;t make sense, since they are (should) be independent from standard librar=
y features. Don&#39;t forget that there are environments (kernel/embedded d=
evelopment) where you frequently don&#39;t have access to a standard librar=
y implementation at all. In these cases &quot;std::&quot; would make even l=
ess sense or may even be confusing.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec5196a2dbbb5a5051893bf3c--

.

2015-06-15 21:48 GMT+02:00 Christopher Horvath <blackencino@gmail.com>:
> Aren't std::move, std::forward, std::initializer_list examples of core
> syntactic features that are in the std:: namespace?

A standard library header is always required for these three, they are
not predefined.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

My mistake, please pardon.

On Mon, Jun 15, 2015 at 12:53 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmai=
l.com>
wrote:

> 2015-06-15 21:48 GMT+02:00 Christopher Horvath <blackencino@gmail.com>:
> > Aren't std::move, std::forward, std::initializer_list examples of core
> > syntactic features that are in the std:: namespace?
>
> A standard library header is always required for these three, they are
> not predefined.
>
> - Daniel
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">My mistake, please pardon.</div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Mon, Jun 15, 2015 at 12:53 PM, Daniel Kr=
=C3=BCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.co=
m" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span class=3D"">2015-06-15 21:48 GMT+02:00 Chr=
istopher Horvath &lt;<a href=3D"mailto:blackencino@gmail.com">blackencino@g=
mail.com</a>&gt;:<br>
&gt; Aren&#39;t std::move, std::forward, std::initializer_list examples of =
core<br>
&gt; syntactic features that are in the std:: namespace?<br>
<br>
</span>A standard library header is always required for these three, they a=
re<br>
not predefined.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01538cbeeab658051893e249--

.

On Monday 15 June 2015 21:53:53 Daniel Kr=C3=BCgler wrote:
> 2015-06-15 21:48 GMT+02:00 Christopher Horvath <blackencino@gmail.com>:
> > Aren't std::move, std::forward, std::initializer_list examples of core
> > syntactic features that are in the std:: namespace?
>=20
> A standard library header is always required for these three, they are
> not predefined.

And just like <new> and <typeinfo>, those are simple interfaces to a core=
=20
language feature. The compiler defines the ABI for initializer_list and for=
=20
typeinfo, not the header.

An easy way of telling them apart is to check what is in libsupc++ / libc++=
abi=20
/ libcxxrt and what is in the upper library. The "C++ language support" or=
=20
"C++ runtime" libraries would be used for kernel / embedded development, bu=
t=20
not the upper library.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

As a larger stylistic point, isn't this somewhat odd - that you need to
include certain files to use what seem to be basic mechanisms of the
language? It doesn't really bother me, but it seems impure on some level.

On Mon, Jun 15, 2015 at 1:11 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 15 June 2015 21:53:53 Daniel Kr=C3=BCgler wrote:
> > 2015-06-15 21:48 GMT+02:00 Christopher Horvath <blackencino@gmail.com>:
> > > Aren't std::move, std::forward, std::initializer_list examples of cor=
e
> > > syntactic features that are in the std:: namespace?
> >
> > A standard library header is always required for these three, they are
> > not predefined.
>
> And just like <new> and <typeinfo>, those are simple interfaces to a core
> language feature. The compiler defines the ABI for initializer_list and f=
or
> typeinfo, not the header.
>
> An easy way of telling them apart is to check what is in libsupc++ /
> libc++abi
> / libcxxrt and what is in the upper library. The "C++ language support" o=
r
> "C++ runtime" libraries would be used for kernel / embedded development,
> but
> not the upper library.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">As a larger stylistic point, isn&#39;t this somewhat odd -=
 that you need to include certain files to use what seem to be basic mechan=
isms of the language? It doesn&#39;t really bother me, but it seems impure =
on some level.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Mon, Jun 15, 2015 at 1:11 PM, Thiago Macieira <span dir=3D"ltr">&lt;<=
a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org=
</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"><span class=3D"">O=
n Monday 15 June 2015 21:53:53 Daniel Kr=C3=BCgler wrote:<br>
&gt; 2015-06-15 21:48 GMT+02:00 Christopher Horvath &lt;<a href=3D"mailto:b=
lackencino@gmail.com">blackencino@gmail.com</a>&gt;:<br>
&gt; &gt; Aren&#39;t std::move, std::forward, std::initializer_list example=
s of core<br>
&gt; &gt; syntactic features that are in the std:: namespace?<br>
&gt;<br>
&gt; A standard library header is always required for these three, they are=
<br>
&gt; not predefined.<br>
<br>
</span>And just like &lt;new&gt; and &lt;typeinfo&gt;, those are simple int=
erfaces to a core<br>
language feature. The compiler defines the ABI for initializer_list and for=
<br>
typeinfo, not the header.<br>
<br>
An easy way of telling them apart is to check what is in libsupc++ / libc++=
abi<br>
/ libcxxrt and what is in the upper library. The &quot;C++ language support=
&quot; or<br>
&quot;C++ runtime&quot; libraries would be used for kernel / embedded devel=
opment, but<br>
not the upper library.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2033203fdd1051894295d--

.

On Monday 15 June 2015 13:18:25 Christopher Horvath wrote:
> As a larger stylistic point, isn't this somewhat odd - that you need to
> include certain files to use what seem to be basic mechanisms of the
> language? It doesn't really bother me, but it seems impure on some level.

Technically speaking, you don't.

 auto x = typeid(int);

Now you have a forward-declared std::type_info. Want to access its internals?
Include the header.

Same for {1}: it's a std::initializer_list, but to access the begin() and
end(), you need to include the header.

Now, the compilers require you to #include the header before you can even use
the constructs, but they technically speaking didn't need to.

That's why in the discussion about multiple return values I pointed out we'd
need a separate type for the aggregate, if there'll be one, as std::tuple is
already defined in the library's ABI, not the compiler's.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Mon, Jun 15, 2015 at 2:21 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 15 June 2015 13:18:25 Christopher Horvath wrote:
> > As a larger stylistic point, isn't this somewhat odd - that you need to
> > include certain files to use what seem to be basic mechanisms of the
> > language? It doesn't really bother me, but it seems impure on some level.
>
> Technically speaking, you don't.
>
>         auto x = typeid(int);
>
> Now you have a forward-declared std::type_info. Want to access its
> internals?
> Include the header.
>
> Same for {1}: it's a std::initializer_list, but to access the begin() and
> end(), you need to include the header.
>
> Now, the compilers require you to #include the header before you can even
> use
> the constructs, but they technically speaking didn't need to.
>

Well, the language standard requires that, and the compilers are just
implementing the rules as specified. This doesn't really seem important
enough to support as a conforming extension.

That said, it would have been completely reasonable in my opinion for
typeid(T) to be valid without including any header, but for std::type_info
to be an incomplete type unless you've included <typeinfo>.


> That's why in the discussion about multiple return values I pointed out
> we'd
> need a separate type for the aggregate, if there'll be one, as std::tuple
> is
> already defined in the library's ABI, not the compiler's.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--bcaec5489e45cf3cb805189650be
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 M=
on, Jun 15, 2015 at 2:21 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mond=
ay 15 June 2015 13:18:25 Christopher Horvath wrote:<br>
&gt; As a larger stylistic point, isn&#39;t this somewhat odd - that you ne=
ed to<br>
&gt; include certain files to use what seem to be basic mechanisms of the<b=
r>
&gt; language? It doesn&#39;t really bother me, but it seems impure on some=
 level.<br>
<br>
</span>Technically speaking, you don&#39;t.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D typeid(int);<br>
<br>
Now you have a forward-declared std::type_info. Want to access its internal=
s?<br>
Include the header.<br>
<br>
Same for {1}: it&#39;s a std::initializer_list, but to access the begin() a=
nd<br>
end(), you need to include the header.<br>
<br>
Now, the compilers require you to #include the header before you can even u=
se<br>
the constructs, but they technically speaking didn&#39;t need to.<br></bloc=
kquote><div><br></div><div>Well, the language standard requires that, and t=
he compilers are just implementing the rules as specified. This doesn&#39;t=
 really seem important enough to support as a conforming extension.</div><d=
iv><br></div><div>That said, it would have been completely reasonable in my=
 opinion for typeid(T) to be valid without including any header, but for st=
d::type_info to be an incomplete type unless you&#39;ve included &lt;typein=
fo&gt;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That&#39;s why in the discussion about multiple return values I pointed out=
 we&#39;d<br>
need a separate type for the aggregate, if there&#39;ll be one, as std::tup=
le is<br>
already defined in the library&#39;s ABI, not the compiler&#39;s.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec5489e45cf3cb805189650be--

.