C++ Standards Committee meeting next week

[Botond Ballo]

Hi everyone,

The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17.

I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week).

I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out.

If anyone's interested in the C++ standardization process, you can find more information here [2].

Thanks,
Botond

[1] http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s
[2] http://isocpp.org/std

[Benoit Jacob]

OK, here is something that I would really like:

http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf

Basically, this is a language extension that asks the compiler to store
type information for each object in memory, so that one can query at
runtime the type of what's stored at a given address.

That would be useful e.g. for refgraph (
https://github.com/bjacob/mozilla-central/wiki/Refgraph ) and, I suppose,
that also wouldn't hurt to know more about heap-unclassified in
about:memory. Basically, everything would be 'classified' at least by c++
type name. And that would also be a nice tool to have around during long
debugging sessions. So, I would appreciate if you could figure if there is
any intention to add something like this in the standard.

(Thanks to Rafael for bringing this to my attention)

Benoit




2013/9/20 Botond Ballo <bot...@mozilla.com>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Trevor Saunders]

Hi,

some things that I've seen that we'd probably like to see end up in the
language include.

- final on data / non virtual member functions
- virtual constants (maybe ability to get at vtable pointer too?)
- ability to say classes should only be used on stack / heap or not used
in one of those

It would be nice to know if we can interest people in supporting any
of those.

Trev

[Robert O'Callahan]

On Tue, Sep 24, 2013 at 5:18 AM, Trevor Saunders <trev.s...@gmail.com>wrote:

> - virtual constants
>

Yeah baby!

> - ability to say classes should only be used on stack / heap or not used
> in one of those
>

That's another good idea!

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*

[Gregory Szorc]

On 9/20/13 2:50 PM, Botond Ballo wrote:
> Hi everyone,
>
> The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17.
>
> I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week).
>
> I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out.
>
> If anyone's interested in the C++ standardization process, you can find more information here [2].
>
> Thanks,
> Botond
>
> [1] http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s
> [2] http://isocpp.org/std

Fixing the "include hell" problem would be at the top of my list of
wants as someone who cares about the performance of a large scale build
system. I believe there was a C++ modules proposal on the standards
track at one point. Not sure what it's status is beyond being an
experimental feature in clang [1]. Of course, by the time all the major
compilers support this and we're in a position to make use of it, large
parts of m-c's C++ might be rewritten in Rust, so who knows.

[1] http://clang.llvm.org/docs/Modules.html

[Joshua Cranmer 🐧]

On 9/20/2013 4:50 PM, Botond Ballo wrote:
> Hi everyone,
>
> The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17.
>
> I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week).
>
> I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out.

I have a laundry list of stuff that I want a fly-on-the-wall perspective.

First is the discussion of the standardization support macros (so we
don't have to maintain crummy stuff like mfbt/Compiler.h), although that
meeting may have already passed.

I'm also interested in seeing proposals for standardization of more
complex attributes that we have static analysis results for--in
particular, the stack class/heap class/etc. annotations, the
must_override analysis, and expanding override/must_override to refer to
nonvirtual as well as virtual methods.

The implementation timeframe of modules is also interesting, since it
appears to be the best-proposed solution to solving various #include
problems.

The new threading paradigms (MS is proposing an async/await framework
that basically plays out like the |yield| keyword in JS or python) could
also prove useful for Mozilla.

Finally, I'm interested in seeing what APIs are going to come out of the
networking and filesystem TS groups, particularly because trying to
track down progress on them is maddening.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Botond Ballo]

> what i've really been wondering about for a while is
> whether there are any considerations of static / compile-time introspection,
> and if not, why.
> It's nothing pressing, i'm just really curious and i haven't found anything
> on it (besides the rare musings of other C++ users on this).
>
> Basically static introspection would allow meta-programming to take it a step
> further; e.g. to use template-meta-programming to iterate at compile-time
> through information about members of namespaces and classes. You would be
> able to get their signatures/addresses/names/attributes/... and generate
> code for them.
> Use-cases would e.g. be:
> * generation of bridging code (C++ ↔ script)
> * various wrapper scenarios (forward/filter/... interfaces)
> * runtime reflection for select code subsets
> … for which currently separate pre-build steps (e.g. Qts moc), pre-processor
> markup (say Boost Reflect), repetitive code etc. are necessary - so it's
> either crude or requires specific toolchains.

This is definitely an active area of investigation in the Committee.

There is a Reflection Study Group (a sub-group of the Committee which
focuses on a particular area) which is tasked with investigating
language and library extensions for compile-time and runtime reflection.
The majority of the interest so far has been for compile-time reflection,
but I believe some of the infrastructure for compile-time reflection
will enable runtime reflection as well.

The Reflection Study Group met in Chicago last week, and talked about
a rough outline of the sorts of things we'd like to be able to do with
reflection, from straightforward things like iterating over the members
of a class at compile-time for purposes such as serialization and
equality comparison, to more sophisticated things like synthesizing
new types by transforming existing types.

I believe the plan is to issue a call for proposals, with some
guidance about the general direction that is desired, derived from
that outline. The Study Group will then look at the proposals at
future meetings and provide feedback, with the aim of converging
towards a cohesive set of proposals to present to the Committee at
large.

Since this is a very large area of explore, I believe the Study
Group is initially interested particularly in proposals that
provide infrastructure that compile-time reflection features can
be built on top of. This should become more clear when the
call for proposals is issued.

Botond

[Botond Ballo]

> OK, here is something that I would really like:
>
> http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf
>
> Basically, this is a language extension that asks the compiler to store
> type information for each object in memory, so that one can query at
> runtime the type of what's stored at a given address.
>
> That would be useful e.g. for refgraph (
> https://github.com/bjacob/mozilla-central/wiki/Refgraph ) and, I suppose,
> that also wouldn't hurt to know more about heap-unclassified in
> about:memory. Basically, everything would be 'classified' at least by c++
> type name. And that would also be a nice tool to have around during long
> debugging sessions. So, I would appreciate if you could figure if there is
> any intention to add something like this in the standard.

I believe this falls under the purview of runtime reflection, which
is being looked at by the Reflection Study Group. See my previous
email about the progress of the Reflection Study Group.

I've come across one paper in particular that seems to address this
use case, called "Rich Pointers with Dynamic and Static Introspection" [1].
I believe the Study Group looked at this paper briefly last week and
identified some serious problems with it, and the paper's author
decided to withdraw it. I'm not sure what the issues were as I wasn't
in that meeting (there were several groups meeting in parallel and
only one of me :-) ). However, I believe that the objectives that
the paper was aiming to achieve, such as determining what is the type
of an object at a given memory location, are still desirable, and
alternative proposals for achieving these objectives will probably
be made.

Botond

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3410.pdf

[Botond Ballo]

> - final on data / non virtual member functions
> - virtual constants (maybe ability to get at vtable pointer too?)

> - ability to say classes should only be used on stack / heap or not used
> in one of those
>

> It would be nice to know if we can interest people in supporting any
> of those.

I'm not sure what "final on data" means, can you elaborate on that?

For the other things, I'm not aware of any active proposals for these
things. I will post a follow-up email that describes the Committee's
procedure for making proposals for new language features, in case
anyone is interested in proposing these.

I should mention that forcing a class to be allocated on the stack
or heap can already be accomplished to some extent. (To force a
class to be allocated on the heap, declare its destructor private,
allocate it using "new", and delete it by calling a member function
that calls "delete this". To force a class to be allocated on the
stack, give it private operator new and delete members.) Of course
these techniques are not perfect and a built-in language feature
for doing this would be nicer.

Botond

[Botond Ballo]

> There is a Reflection Study Group (a sub-group of the Committee which
> focuses on a particular area) which is tasked with investigating
> language and library extensions for compile-time and runtime reflection.

By the way, the Reflection Study Group has just opened a public mailing
list [1].

Botond


[1] https://groups.google.com/a/isocpp.org/forum/#!forum/reflection

[Trevor Saunders]

On Tue, Oct 01, 2013 at 01:13:37PM -0700, Botond Ballo wrote:
> > - final on data / non virtual member functions
> > - virtual constants (maybe ability to get at vtable pointer too?)
> > - ability to say classes should only be used on stack / heap or not used
> > in one of those
> >
> > It would be nice to know if we can interest people in supporting any
> > of those.
>
> I'm not sure what "final on data" means, can you elaborate on that?

something like this
class Foo : public nsISomething
{
nsrefcount mRfcnt final;
};

class SpecialFoo : public Foo
{
nsrefcount mRfcnt; // Should not compile, is not ok, is footgun!
};

> For the other things, I'm not aware of any active proposals for these
> things. I will post a follow-up email that describes the Committee's
> procedure for making proposals for new language features, in case
> anyone is interested in proposing these.

maybe someone should look into doing that

> I should mention that forcing a class to be allocated on the stack
> or heap can already be accomplished to some extent. (To force a
> class to be allocated on the heap, declare its destructor private,
> allocate it using "new", and delete it by calling a member function
> that calls "delete this". To force a class to be allocated on the
> stack, give it private operator new and delete members.) Of course
> these techniques are not perfect and a built-in language feature
> for doing this would be nicer.

yeah, those are pretty poor substitutes, for example the operator new /
delte thing doesn't prevent globals of the type afaik.

Trev

>
> Botond

[Botond Ballo]

> Fixing the "include hell" problem would be at the top of my list of
> wants as someone who cares about the performance of a large scale build
> system. I believe there was a C++ modules proposal on the standards
> track at one point. Not sure what it's status is beyond being an
> experimental feature in clang [1]. Of course, by the time all the major
> compilers support this and we're in a position to make use of it, large
> parts of m-c's C++ might be rewritten in Rust, so who knows.
>
> [1] http://clang.llvm.org/docs/Modules.html

The Standards Committee has a study group focusing on modules.
It met briefly last week. Doug Gregor, who's been working on
implementing modules in clang, shared a status update:

- Clang has a working implementation of modules for C and Objective-C,
which is shipping in Xcode 5.
- Implementing the feature in C++ is quite a bit more difficult,
because of things like having to reconcile template instantiations
from different modules (basically, a lot of the same problems that
made 'export' difficult). There is work in progress on a clang
implementation for C++, but it's not usable yet.

The latest version of the proposal looks fairly clean to me from a
user's point of view:

- Modules are simply header files. A file called a "module map"
identifies header files as being modules and gives them a name.
- To import a module, one writes

import modulename;

- From an implementation point of view, modules are just a pre-
parsed representation of a header file's contents. Clang's
work-in-progress implementation represents them as a
serialized AST, but other implementations are possible.
- Modules are parsed without any context. So, if one does

#define EVIL_MACRO
#include <header.h>

then EVIL_MACRO is defined while processing the contents of
<header.h>, but if one does

#define EVIL_MACRO
import header;

then EVIL_MACRO is not defined while building the module
'header'. Obviously this is something that needs to be
considered when porting header files to be modular, you
cannot just blindly replace all inclusions with module
imports.

Naturally, a lot of the details are still subject to change,
particularly about the mechanism for mapping module names to
header files, and about the syntax for importing a module.

In terms of timeframe, I don't think the Committee will
consider standardizing anything until there isn't a complete
implementation, especially in light of what happened with
'export'. So, I'm guessing C++17 at the earliest.

Botond

[Botond Ballo]

> what i've really been wondering about for a while is
> whether there are any considerations of static / compile-time introspection,
> and if not, why.
> It's nothing pressing, i'm just really curious and i haven't found anything
> on it (besides the rare musings of other C++ users on this).
>
> Basically static introspection would allow meta-programming to take it a step
> further; e.g. to use template-meta-programming to iterate at compile-time
> through information about members of namespaces and classes. You would be
> able to get their signatures/addresses/names/attributes/... and generate
> code for them.
> Use-cases would e.g. be:
> * generation of bridging code (C++ ↔ script)
> * various wrapper scenarios (forward/filter/... interfaces)
> * runtime reflection for select code subsets
> … for which currently separate pre-build steps (e.g. Qts moc), pre-processor
> markup (say Boost Reflect), repetitive code etc. are necessary - so it's
> either crude or requires specific toolchains.

This is definitely an active area of investigation in the Committee.

There is a Reflection Study Group (a sub-group of the Committee which
focuses on a particular area) which is tasked with investigating
language and library extensions for compile-time and runtime reflection.

The majority of the interest so far has been for compile-time reflection,
but I believe some of the infrastructure for compile-time reflection
will enable runtime reflection as well.

The Reflection Study Group met in Chicago last week, and talked about

a rough outline of the sorts of things C++ programmers would like to

be able to do with reflection, from straightforward things like
iterating over the members of a class at compile-time for purposes
such as serialization and equality comparison, to more sophisticated
things like synthesizing new types by transforming existing types.

I believe the plan is to issue a call for proposals, with some
guidance about the general direction that is desired, derived from
that outline. The Study Group will then look at the proposals at
future meetings and provide feedback, with the aim of converging
towards a cohesive set of proposals to present to the Committee at
large.

Since this is a very broad area to explore, I believe the Study

[Botond Ballo]

> I have a laundry list of stuff that I want a fly-on-the-wall perspective.
>
> First is the discussion of the standardization support macros (so we
> don't have to maintain crummy stuff like mfbt/Compiler.h), although that
> meeting may have already passed.

The latest proposal for these macros can be found here [1]. The
Evolution Working Group (the subgroup of the committee that deals with
new language features) accepted the recommendations in that proposal
as-is.

A minor procedural blemish arose, which is that some C++14 features
for which the proposal contained macros have since been removed from
C++14, making the proposal technically out of date. As a result,
the committee decided that this proposal will not be put into the
standard document itself but into a separate document with its own
update cadence. I don't believe this should affect whether/how
compilers implement these macros.

> I'm also interested in seeing proposals for standardization of more
> complex attributes that we have static analysis results for--in
> particular, the stack class/heap class/etc. annotations, the
> must_override analysis, and expanding override/must_override to refer to
> nonvirtual as well as virtual methods.

I'm not familiar with these annotations (other than 'override') -
can I find more information about them somewhere?

> The implementation timeframe of modules is also interesting, since it
> appears to be the best-proposed solution to solving various #include
> problems.

See my previous post about modules. In a nutshell, C++17 at the earliest.

> The new threading paradigms (MS is proposing an async/await framework
> that basically plays out like the |yield| keyword in JS or python) could
> also prove useful for Mozilla.

The latest proposal for async/await can be found here [2]. There was
also a proposal to standardize the Boost.Coroutines library [3] which
provides similar capabilities. Both proposals were presented and
discussed in Chicago. I wasn't there for the discussion of [2], but I
believe the authors were given feedback and encouraged to prepare an
updated proposal. I was there for the discussion of [3], where the
primary feedback was that two aspects of the proposal, the proposed
communication mechanism between two execution contexts, and the
proposed mechanism for launching an independently executing context
and for switching contexts, be cleanly separated.

Neither of these proposals are on track for C++14. I *believe*
they're not on track for the Concurrency Technical Specification
that will follow, either, though I don't think the contents of
that have been finalized yet.

> Finally, I'm interested in seeing what APIs are going to come out of the
> networking and filesystem TS groups, particularly because trying to
> track down progress on them is maddening.

The latest version of the filesystem proposal can be found here [4].
I believe this is on track to be released as a Technical Specification
in the 2014 timeframe.

For networking, there are three proposals in the works: URIs [5],
IP addresses [6], and byte order [7]. I believe URIs and IP addresses
are headed towards one Technical Specification, and byte order towards
another. Presumably more will follow that build on these (e.g. TCP
socket communication).

Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm#recs
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3722.pdf
[3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3708.pdf
[4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html
[5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3720.html
[6] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3603.html
[7] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3646.pdf

[Joshua Cranmer 🐧]

On 10/1/2013 4:51 PM, Botond Ballo wrote:
>> I'm also interested in seeing proposals for standardization of more
>> complex attributes that we have static analysis results for--in
>> particular, the stack class/heap class/etc. annotations, the
>> must_override analysis, and expanding override/must_override to refer to
>> nonvirtual as well as virtual methods.
> I'm not familiar with these annotations (other than 'override') -
> can I find more information about them somewhere?

<http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384>
is the list of analyses we currently do in Mozilla. I know must_override
has been mentioned once or twice with respect to C++ standardization,
but I can't recall where.

>> The implementation timeframe of modules is also interesting, since it
>> appears to be the best-proposed solution to solving various #include
>> problems.
> See my previous post about modules. In a nutshell, C++17 at the earliest.

What is the feedback from non-Clang developers about prototyping in
their compilers? Are we likely to see this implemented as soon as stable
wording is finalized, or are compiler vendors likely to drag their feet
and implement it in the last tranche of updates (basically, is the
uptake going to be like auto or rvalue references, or will it be like
generalized attributes or alignof).

> Neither of these proposals are on track for C++14. I *believe* they're
> not on track for the Concurrency Technical Specification that will
> follow, either, though I don't think the contents of that have been
> finalized yet.

Huh.

> For networking, there are three proposals in the works: URIs [5],
> IP addresses [6], and byte order [7]. I believe URIs and IP addresses
> are headed towards one Technical Specification, and byte order towards
> another. Presumably more will follow that build on these (e.g. TCP
> socket communication).

It's a shame that sockets come so much later, but nonetheless totally
understandable.

[Botond Ballo]

> >> I'm also interested in seeing proposals for standardization of more
> >> complex attributes that we have static analysis results for--in
> >> particular, the stack class/heap class/etc. annotations, the
> >> must_override analysis, and expanding override/must_override to refer to
> >> nonvirtual as well as virtual methods.
> >
> > I'm not familiar with these annotations (other than 'override') -
> > can I find more information about them somewhere?
>
> <http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384>
> is the list of analyses we currently do in Mozilla. I know must_override
> has been mentioned once or twice with respect to C++ standardization,
> but I can't recall where.

Interesting. How is this static analysis implemented - a clang plugin?
Does it cause compiler errors or warnings when the annotations aren't
obeyed?

I haven't heard any discussion of such annotations in Chicago. One
attribute, [[deprecated]], was standardized, but that's it. I'll keep
my eyes open and let you know if I come across any talk of them.

> >> The implementation timeframe of modules is also interesting, since it
> >> appears to be the best-proposed solution to solving various #include
> >> problems.
> > See my previous post about modules. In a nutshell, C++17 at the earliest.
>
> What is the feedback from non-Clang developers about prototyping in
> their compilers? Are we likely to see this implemented as soon as stable
> wording is finalized, or are compiler vendors likely to drag their feet
> and implement it in the last tranche of updates (basically, is the
> uptake going to be like auto or rvalue references, or will it be like
> generalized attributes or alignof).

I'm not aware of other compilers actively working on it at the moment.
It sounded like they were waiting for clang to implement it to see
if the idea is viable at all.

An EDG developer present at the meeting pointed out that many of the
difficulties in implementing modules are the same difficulties that
are involved in implementing 'export'. EDG was the only compiler
that implemented 'export', so that's not a very encouraging sign,
but I also think the level of demand is much higher for modules
(which most people agree will be very useful) than it was for export
(which most people agreed was useless).

One thing that was brought up is that clang was able to leverage
its PCH (pre-compiled header) implementation, which is basically
just a serialized AST, for its implementation of modules, but
GCC's PCH implementation, which is just a compiler memory dump,
is less suitable for this purpose. This suggests that it will
require more effort for GCC to implement modules than clang.

> > Neither of these proposals are on track for C++14. I *believe* they're
> > not on track for the Concurrency Technical Specification that will
> > follow, either, though I don't think the contents of that have been
> > finalized yet.
>
> Huh.

I'll post a follow-up email about the various Technical
Specifications that are in the works, and what's likely to be
in them.

Botond

[Ehsan Akhgari]

On 2013-10-02 11:38 AM, Botond Ballo wrote:
>>>> I'm also interested in seeing proposals for standardization of more
>>>> complex attributes that we have static analysis results for--in
>>>> particular, the stack class/heap class/etc. annotations, the
>>>> must_override analysis, and expanding override/must_override to refer to
>>>> nonvirtual as well as virtual methods.
>>>
>>> I'm not familiar with these annotations (other than 'override') -
>>> can I find more information about them somewhere?
>>
>> <http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384>
>> is the list of analyses we currently do in Mozilla. I know must_override
>> has been mentioned once or twice with respect to C++ standardization,
>> but I can't recall where.
>

> Interesting. How is this static analysis implemented - a clang plugin?
> Does it cause compiler errors or warnings when the annotations aren't
> obeyed?

It is implemented as a clang plugin here:
<http://mxr.mozilla.org/mozilla-central/source/build/clang-plugin/clang-plugin.cpp>.
The compiler will emit an error if it detects a violation of the
annotations.

Cheers,
Ehsan

> I haven't heard any discussion of such annotations in Chicago. One
> attribute, [[deprecated]], was standardized, but that's it. I'll keep
> my eyes open and let you know if I come across any talk of them.
>

>>>> The implementation timeframe of modules is also interesting, since it
>>>> appears to be the best-proposed solution to solving various #include
>>>> problems.
>>> See my previous post about modules. In a nutshell, C++17 at the earliest.
>>
>> What is the feedback from non-Clang developers about prototyping in
>> their compilers? Are we likely to see this implemented as soon as stable
>> wording is finalized, or are compiler vendors likely to drag their feet
>> and implement it in the last tranche of updates (basically, is the
>> uptake going to be like auto or rvalue references, or will it be like
>> generalized attributes or alignof).
>

> I'm not aware of other compilers actively working on it at the moment.
> It sounded like they were waiting for clang to implement it to see
> if the idea is viable at all.
>
> An EDG developer present at the meeting pointed out that many of the
> difficulties in implementing modules are the same difficulties that
> are involved in implementing 'export'. EDG was the only compiler
> that implemented 'export', so that's not a very encouraging sign,
> but I also think the level of demand is much higher for modules
> (which most people agree will be very useful) than it was for export
> (which most people agreed was useless).
>
> One thing that was brought up is that clang was able to leverage
> its PCH (pre-compiled header) implementation, which is basically
> just a serialized AST, for its implementation of modules, but
> GCC's PCH implementation, which is just a compiler memory dump,
> is less suitable for this purpose. This suggests that it will
> require more effort for GCC to implement modules than clang.
>

>>> Neither of these proposals are on track for C++14. I *believe* they're
>>> not on track for the Concurrency Technical Specification that will
>>> follow, either, though I don't think the contents of that have been
>>> finalized yet.
>>
>> Huh.
>

> I'll post a follow-up email about the various Technical
> Specifications that are in the works, and what's likely to be
> in them.
>
> Botond

[Botond Ballo]

So, after writing about a bunch of things that _won't_ be in C++14,
let me summarize what _will_ be. Here are the highlights:

* Return type deduction

In C++11, we have decltype() and late-specified return types
(return types written after the argument list so they can
mention arguments). These were often combined to write code
like this:

auto function(A a, B b) -> decltype(expr)
{
return expr;
}

Having to repeat 'expr' is rather unfortunate, and C++14
fixes that. You can now write:

auto function(A a, B b)
{
return expr;
}

It works even if the function body contains multiple
statements, control flow, etc. The only restriction is
that if there are multiple return expressions, they
must all have the same type.

* Improved lambdas

* Generic lambdas

These are lambdas with 'auto' arguments which acts as
template parameters rather than concrete types:

// This lambda can be called with arguments of any type.
[](auto a, auto b){ return a > b; }

Implementation-wise, they are just local structures with
a templated call operator (while ordinary lambdas are
local structures with a non-templated call operator).

* Init-captures

These allow you to declare new variables in the capture-list
rather than just capture existing variables from the outer
scope. The new variables can be initialized in any way,
including by move, something that wasn't possible before.

std::unique_ptr<Foo> p = ...;
...
// No way to capture 'p' in C++11. Can't capture it by
// value because it's not copyable; don't want to capture
// it by reference because the reference could become
// dangling if the lambda is passed out of the function.
// In C++14 we can do this:
[newp = move(p)](...){...}

* Variable templates

Up until now, only functions and classes/structures could be
templates. Now, variables can be too.

* More powerful constexpr

Up until now, constexpr functions were limited to containing
a single return expression. Now they can contain multiple
statements, loops, and so on. Basically, they can now be
written in an imperative style rather than a functional
style. They still can't modify non-local state.

* Improved literals

* Binary literals: 0b00101010101

* Digit separators: int x = 1'000'000; // don't ask

* Standard user-defined literals

C++11 introduced user-defined literals. C++14 intoduces
some standard ones:

"foo"s // std::string literal

30s // std::chrono::seconds literal

Yes, they are both 's'. C++ knows when to use which.
Other durations have them too, so you can write things
like

1h + 10min + 30s


Botond

[Botond Ballo]

In addition to the C++14 standard, the Committee is working on a
number of follow-up documents called Technical Specifications (TS),
which carry less weight than the standard, but indicate an
intention to standardize a new library or language feature in a
future standard:

* Concepts Lite TS (my favourite)

Concepts are a mechanism for constraining template parameters.
Today we often write code like this:

template <typename Container>
void sort(Container& c);

Our intention is that the type used as a template argument for
'Container' be a container type, but the compiler doesn't
enforce this - it will accept any type there, and then give
cryptic errors from deep within the template's implementation
when it tries to use the argument as a container.

Concepts allows us to define a concept called 'Container'
which expresses what we mean by a 'container type', and then
write the template like this instead:

template <typename C> requires Container<C>
void sort(C& c);

Or as a short form:

template <Container C>
void sort(C& c);

When calling this function, the compiler checks at the call
site whether the template argument satisfies the Container
concept, and give a much friendlier error if it doesn't.

It's also possible to check the definition of a template
to make sure it doesn't do anything with the template
arguments that's not specified by the concepts to which they
conform.

A 'full' concepts feature would include both directions of
checking (checking the call sites and the definitions).
The committee tried standardizing full concepts for C++11,
but ran into a lot of complexity. It is now resurrecting
the feature in a 'lite' form that only includes checking
of the call sites.

The details of Concepts Lite can be found here [1].

* Array Extensions TS

Support for arrays whose size isn't known at compile time.
C calls these Variable-Lengths Arrays (VLAs). C++ stubbornly
refuses to call them VLAs, and calls them Arrays of Runtime
Bound (ARBs) instead (there are some minor differences
between the two flavours, for example you can call sizeof()
on a VLA (and it will be evaluated at runtime), but not on
an ARB).

The TS will also include a library that wraps ARBs into
a nicer interface, much like how std::array wraps regular
arrays into a nicer interface.

These were originally going to be in C++14, but were moved
into a TS because the library interface isn't fully fleshed
out yet.

* Library Fundamentals TS

This will contain the new <optional> library (originally
headed for C++14 but the committee felt it was safer to
put it into a TS instead) and possibly some other utilities.

* Networking TS

There will actually be a series of Networking TS's. The
first will specify URIs and IP addresses. The second will
specify byte-order conversions. Future ones may deal with
higher-level functionality like sockets.

* Filesystem TS [2]

There may also be a follow-up TS to this that provides
additional features e.g. for enterprise filesystems.

* Transactional Memory TS

A synchronization primitive built into the language.
The proposal can be found here [3].

* Parallelism Extensions TS

Parallel versions of standard library algorithms.
This is in a relatively early stage, but it will possibly
be based on [4].

* Concurrency Extensions TS

Language features that make it easier to write
asynchronous/concurrent code. Also in an early stage,
proposals being considered include [5] and [6].

I believe that most of these are planned for publication in
2014, though probably not the last two, nor the follow-ups
to the Networking and Filesystem TS's.

Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3718.pdf
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3724.pdf
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3731.pdf
[6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3721.pdf

[Botond Ballo]

Finally, let me describe the process for submitting proposals
to the committee for new libraries or language features.

First, let me briefly describe the internal organization of
the committee. The committee is subdivided into four
Working Groups: Core, Evolution, Library, and Library
Evolution.

Evolution looks at proposals for new language features at
a high-level: how well do they fit into the design of the
language. Core looks at them at a lower-level: is the
specific wording consistent with the wording of the rest
of the standard.

Library Evolution and Library are analogous to Evolution
and Core, but for the standard libraries rather than for
language features.

In addition, some feature areas have a Study Group which
looks at proposals before sending them to Evolution or
Library Evolution.

So, a language proposal progresses through the following
stages to become standardized:

* the relevant Study Group (if there is one)
* Evolution
* Core
* vote by the full committee

A library proposal progresses in a similar way but goes
through Library Evolution and Library instead.

(This is illustrated very nicely here [1].)

If someone is interested in writing a proposal, here's what to
do:

* Bring up the idea on the std-proposals discussion group [2]
to gauge the community's level of interest.
* Write up an initial draft of the proposal, get some more
feedback on it at std-proposals. This initial draft does
not need to contain standard wording yet.
* Formally submit the proposal. I believe this is done by
emailing the committee's project editor, but I can check up
on this. The proposal will get an Nxxx number and show up
in committee mailing like this one [3].
* Present the proposal to the appropriate Study Group if
one exists, or else to the Evolution Working Group, at a
committee meeting. The committee meets 2-3 times a year,
and the meetings are open for anyone to attend. If you
can't attend in person, you can find someone to champion
the proposal for you.
* It's rare for a Study Group or Evolution to accept a
proposal right away. Most often they will give you feedback
on the proposal and encourage you to write an updated
proposal and come back. Several iterations of this can
happen before Evolution accepts the proposal.
* At some point in this process, standard wording for the
proposal needs to be written. Once Evolution has approved
the proposal, Core will look at the wording. Sometimes
they find problems and send the proposal back to Evolution.
If not, the proposal is ready to be voted on in full
committee. Most proposals pass in full committee after
being approved by Core and Evolution.

(If proposing a library feature rather than a language feature,
replace 'Evolution' with 'Library Evolution' and 'Core' with
'Library' in the above).

OK, that was my last long email :) Feel free to ask me any
questions.

Botond

[1] http://isocpp.org/std/the-committee
[2] https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals
[3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/#mailing2013-09

[Zack Weinberg]

On 2013-10-02 12:06 PM, Botond Ballo wrote:
> * Digit separators: int x = 1'000'000; // don't ask

Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which
doesn't?

zw

[Botond Ballo]

> > * Digit separators: int x = 1'000'000; // don't ask
>
> Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which
> doesn't?

Because "_" followed by any number of digits is a valid identifier,
so that would have created an ambiguity with C++11 user-defined
literals. For example, "1_000" would be ambiguous between the
number "1000", and the number "1" suffixed with a user-defined
literal named "_000".

As for pp-numbers, the proposal extends the preprocessor grammar to
handle the separator.

Botond

[Zack Weinberg]

On 2013-10-03 11:16 AM, Botond Ballo wrote:
>>> * Digit separators: int x = 1'000'000; // don't ask
>>
>> Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which
>> doesn't?
>
> Because "_" followed by any number of digits is a valid identifier,
> so that would have created an ambiguity with C++11 user-defined
> literals. For example, "1_000" would be ambiguous between the
> number "1000", and the number "1" suffixed with a user-defined
> literal named "_000".

This would be better resolved by requiring user-defined-literal names to
begin with a non-hexdigit letter or an underscore followed immediately
by a non-hexdigit letter.

(I don't like the "non-hexdigit" part of that but I don't see an
alternative. Note that the standard integer suffixes already are
restricted to non-hexdigit letters.)

> As for pp-numbers, the proposal extends the preprocessor grammar to
> handle the separator.

Tokenization incompatibilities with C are a Bad Idea.

zw

[Jeff Walden]

On 10/02/2013 06:06 PM, Botond Ballo wrote:
> Having to repeat 'expr' is rather unfortunate, and C++14
> fixes that. You can now write:
>
> auto function(A a, B b)
> {
> return expr;
> }
>

> The only restriction is
> that if there are multiple return expressions, they
> must all have the same type.

Same type as in the std::is_same sense? Or same type in the a?b:c sense, where b/c can be different types, and one expression must convert to the other's type? I assume you mean the former, but I can imagine cases (think pointers and nullptr) where the latter would definitely be nice.

Jeff

[Botond Ballo]

> There is a Reflection Study Group (a sub-group of the Committee which
> focuses on a particular area) which is tasked with investigating
> language and library extensions for compile-time and runtime reflection.
> The majority of the interest so far has been for compile-time reflection,
> but I believe some of the infrastructure for compile-time reflection
> will enable runtime reflection as well.
>
> The Reflection Study Group met in Chicago last week, and talked about
> a rough outline of the sorts of things C++ programmers would like to
> be able to do with reflection, from straightforward things like
> iterating over the members of a class at compile-time for purposes
> such as serialization and equality comparison, to more sophisticated
> things like synthesizing new types by transforming existing types.
>
> I believe the plan is to issue a call for proposals, with some
> guidance about the general direction that is desired, derived from
> that outline. The Study Group will then look at the proposals at
> future meetings and provide feedback, with the aim of converging
> towards a cohesive set of proposals to present to the Committee at
> large.
>
> Since this is a very broad area to explore, I believe the Study
> Group is initially interested particularly in proposals that
> provide infrastructure that compile-time reflection features can
> be built on top of. This should become more clear when the
> call for proposals is issued.

The call for proposals has now been posted. It can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html

It states that all reflection-related proposals will be considered,
but the focus is on compile-time reflection, and gives a list of
focus areas and representative use cases.

Botond

[Botond Ballo]

> some things that I've seen that we'd probably like to see end up in the
> language include.
>

> ...

> - ability to say classes should only be used on stack / heap or not used
> in one of those

There's a proposal in the pre-Urbana mailing for something related: the
ability to say that a class should only be used as an lvalue, or only
as a temporary [1].

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4149.pdf