experimental

New paper: N3582, Return Type Deduction for Normal Functions (Revision 3) -- Jason Merrill

[Ed.: Also of broad interest and on track for near-term standardization.]

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3582

Date: 2013-03-15

Return Type Deduction for Normal Functions (Revision 3)

by Jason Merrill

Excerpt:

Any C++ user introduced to the C++11 features of auto, lambdas, and trailing return types immediately wonders why they can't just write auto on their function declaration and have the return type deduced. This functionality was proposed previously in N2954, but dropped from C++11 due to time constraints, as the drafting didn't address various questions and concerns that the Core WG had. I have now implemented this functionality in GCC, and propose to add it to C++14. I discuss some of the less obvious aspects of the semantics below.

This proposal also resolves core DRs 975 (lambda return type deduction from multiple return statements) and 1048 (inconsistency between auto and lambda return type deduction).

 

New paper: N3580, Concepts Lite -- Andrew Sutton, Bjarne Stroustrup, Gabriel Dos Reis

[Ed.: We're calling particular attention to this paper as of broad interest to the community, although still undergoing standardization. This is one of the major papers being considered at the upcoming Bristol standards meeting in April for near-term standardization work.]

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3580

Date: 2013-03-17

Concepts Lite: Constraining Templates with Predicates

by Andrew Sutton, Bjarne Stroustrup, Gabriel Dos Reis

Excerpt:

In this paper, we introduce template constraints (a.k.a., “concepts lite”), an extension of C++ that allows the use of predicates to constrain template arguments. The proposed feature is minimal, principled, and uncomplicated. Template constraints are applied to enforce the correctness of template use, not the correctness of template definitions. The design of these features is intended to support easy and incremental adoption by users. More precisely, constraints:

  • allow programmers to directly state the requirements of a set of template arguments as part of a template’s interface,
  • support function overloading and class template specialization based on constraints,
  • fundamentally improve diagnostics by checking template arguments in terms of stated intent at the point of use, and
  • do all of this without any runtime overhead or longer compilation times.

This work is implemented as a branch of GCC-4.8 and is available for download at http://concepts.axiomatics.org/˜ans/. The implementation includes a compiler and a modified standard library that includes constraints. Note that, as of the time of writing, all major features described in this report have been implemented.

This paper is organized like this:

  • Tutorial: introduces the basic notions of constraints, shows examples of their use, and gives examples of how to define constraints.
  • Discussion: explains what constrains are not. In particular, we try to outline constraints’s relation to concepts and to dispel some common misconceptions about concepts.
  • User’s guide: provides many more tutorial examples and demonstrate the completeness of the constraints mechanism.
  • Implementation: gives an overview of our GCC compiler support for constraints.
  • Extensions: we discuss how constraints might be extended to interact with other proposed features.
  • Language definition: presents a semi-formal definition of constraints.

Concepts Lite: Constraining Templates with Predicates -- Andrew Sutton, Bjarne Stroustrup

During the C++11 standards development cycle, much work was done on a feature called "concepts" which aimed at providing systematic constraints on templates. Concepts was deferred from C++11 for lack of time to complete it, but work has continued.

In January 2012, the results of a major "concepts summit" were published as a 133-page report titled "A Concept Design for the STL" (WG21 paper N3351).

Now, a draft of new paper is available proposing a very useful subset of concepts, dubbed "Concepts Lite", for near-term consideration including at the spring ISO C++ meeting in Bristol, UK, this April. For example, imagine writing this template:

template<Sortable Cont>
void sort(Cont& container);

and when you call it like this:

list<int> lst = ...;   // oops, bidirectional iterators
sort(lst);             // today, results in very long "template spew" error message

getting this short and non-cryptic error message:

error: no matching function for call to ‘sort(list<int>&)’
   sort(l);
         ^
note: candidate is:
note: template<Sortable T> void sort(T)
   void sort(T t) { }
        ^
note: template constraints not satisfied because
note:   'T' is not a/an 'Sortable' type [with T = list<int>] since
note:     'declval<T>()[n]' is not valid syntax

That's an actual error message from the prototype GCC implementation linked below.

We're very excited about this feature and its continued progress. Here are links to the draft of the new paper:

Concepts Lite: Constraining Templates with Predicates (PDF) (Google Docs)

From the Introduction:

In this paper, we introduce template constraints (a.k.a., “concepts lite”), an extension of C++ that allows the use of predicates to constrain template arguments. The proposed feature is minimal, principled, and uncomplicated. Template constraints are applied to enforce the correctness of template use, not the correctness of template definitions. The design of these features is intended to support easy and incremental adoption by users. More precisely, constraints:

  • allow programmers to directly state the requirements of a set of template arguments as part of a template’s interface,
  • support function overloading and class template specialization based on constraints,
  • fundamentally improve diagnostics by checking template arguments in terms of stated intent at the point of use, and
  • do all of this without any runtime overhead or longer compilation times.

This work is implemented as a branch of GCC-4.8 and is available for download at http://concepts.axiomatics.org/~ans/. The implementation includes a compiler and a modified standard library that includes constraints. Note that, as of the time of writing, all major features described in this report have been implemented.

Related links:

Update from the Ranges Study Group

In December, we announced the opening of the SG9 (Ranges) mailing list. Since then, the activity on it has been nothing short of amazing, and the discussion is of a markedly high quality. Ranges promise a improvement in usability, power, and safety for the STL. If you have ever wanted to see how the C++ Standardization Committee crafts the future of C++, sidle on over to the Ranges group and learn about the future of the STL from many of the people who have helped shape it since its inception. Watch tomorrow's C++ take shape today, and maybe help shape it yourself.

Read the list archives here, or sign up to get the blow-by-blow here.

P.S. You can start using (one implementation of) Ranges today over at Boost (see Boost.Range's docs).

An implementation of generic lambdas (request for feedback) -- Faisal Vali

This week, Faisal Vali shared an initial "alpha" implementation of generic lambdas in Clang. Faisal is the lead author of the proposal (N3418), with Herb Sutter and Dave Abrahams.

To read and participate in the active discussion, see the message thread on std-proposals.

Here is a copy of Faisal's announcement:

Motivated by the positive feedback we received regarding Generic Lambdas (during the October 2012 ISO C++ Standards Meeting in Portland), I have implemented a reasonably complete (unless I am missing something obvious) implementation (http://faisalv.github.com/clang-glambda/) of most of the proposal (named lambda syntax for functions has not been attempted) using a fork of Clang.

 

We would like to encourage developers who are interested in this feature, to either compile the code or download the binaries (sorry, only Windows for now) and play with the implementation and provide us with feedback so that we can incorporate it within our next revision of the document.

The following link: http://faisalv.github.com/clang-glambda/, has some instructions (towards the bottom) on how to compile the code or use the binaries for Windows.

 

Any and all constructive feedback will be greatly appreciated.

The current version (12/2012) implements subproposals 2.1, 2.2, 2.3 and 2.5.

 

2.1 Allow the type-specifier within a parameter declaration of a lambda to be auto (i.e. auto is mandatory)

auto Sum = [](auto a, decltype(a) b) { return a + b; };
int i = Sum(3, 4);
double d = Sum(3.14, 2.77);

 

2.2 Allow the use of familiar template syntax in lambda expressions

auto NumElements = []<int N>(auto (&a)[N]) { return N; };
int arri[]{1, 2, 3};
double arrd[]{3.14, 2.77, 6.626};
auto total = NumElements(arri) + NumElements(arrd);

 

2.3 Permit a lambda body to be an expression

int local = 10;
auto L = [&](auto a) a + ++local;

 

2.5 Autogenerate a conversion to function pointer in captureless generic lambdas

auto L = [](auto a, decltype(a) b) { return a + b; };
int (*fp)(int, int) = L;

 

Thank you and looking forward to the feedback!

Modules update video available -- Doug Gregor

MP4 video of Doug Gregor's talk on Modules is now available via llvm.org. Combining links here:

Modules (MP4 video) (PDF slides)

Doug Gregor - Apple

The C preprocessor has long been a source of problems for programmers and tools alike.

Programmers must contend with widespread macro pollution and #include-ordering problems due to ill-behaved headers. Developers habitually employ various preprocessor workarounds, such as LONG_MACRO_PREFIXES, #include guards, and the occasional #undef of a library macro to mitigate these problems.

Tools, on the other hand, must cope with the inherent scalability problems associated with parsing the same headers repeatedly, because each different preprocessing context could effect how a header is interpreted – even though the programmer rarely wants it.

Modules seeks to solve this problem by isolating the interface of a particular library and compiling it (once) into an efficient, serialized representation that can be efficiently imported whenever that library is used, improving both the programmer’s experience and the scalability of the compilation process.

 

Modules: Update on work in progress -- Doug Gregor

[Updated to add video link]

Earlier this month, Doug Gregor gave a presentation on Modules at the November 2012 LLVM Developers' Meeting. Doug is lead Clang developer at Apple, chairs the WG21 Study Group on Modules (SG2), and in this talk reports his design goals and partial progress to date on designing and implementing a module system for C++. This talk is an extended version of the presentation Doug made at the Feb 2012 ISO C++ meeting in Kona.

The talk slides and video recording is available via the 2012 DevMeeting page.

Standardization note: SG2 was formed in February and has been relatively quiet as a handful of experts (notably Doug with Clang) make further progress on proof-of-concept designs and implementations. As this prototyping work coalesces, SG2 is expected to become active early in the new year.

Modules (MP4 video) (PDF slides)

Doug Gregor -- Apple

The C preprocessor has long been a source of problems for programmers and tools alike.

Programmers must contend with widespread macro pollution and #include-ordering problems due to ill-behaved headers. Developers habitually employ various preprocessor workarounds, such as LONG_MACRO_PREFIXES, #include guards, and the occasional #undef of a library macro to mitigate these problems.

Tools, on the other hand, must cope with the inherent scalability problems associated with parsing the same headers repeatedly, because each different preprocessing context could effect how a header is interpreted -- even though the programmer rarely wants it.

Modules seeks to solve this problem by isolating the interface of a particular library and compiling it (once) into an efficient, serialized representation that can be efficiently imported whenever that library is used, improving both the programmer's experience and the scalability of the compilation process.

Continue reading...

Unifying Generic Functions and Function Objects -- Dave Abrahams

From Dave Abrahams:

Unifying Generic Functions and Function Objects

I just got finished collaborating on a proposal with Faisal Vali and Herb Sutter to include generic lambdas and pythy functions in the core language. After the upcoming Portland committee meeting, we should have a good sense of how much appetite there is on the committee for including these features in C++.

While we were writing that paper, we got some of our most helpful comments and insights from Mathias Gaunard. It was a pivotal moment when Mathias reminded us that we could create operator overload sets explicitly with inheritance and using declarations, and then used it to demonstrate "overloaded lambda expressions..."

[more]

 

"Panel: Static If, C++11, Modern Libraries, and Metaprogramming" -- Alexandrescu, Meyers, Sutter

The first panel from C++ and Beyond 2012 is now available on Channel 9:

On Static If, C++11 in 2012, Modern Libraries, and Metaprogramming

Andrei Alexandrescu, Scott Meyers, Herb Sutter

Channel 9 was invited to this year's C++ and Beyond to film some sessions (that will appear on C9 over the coming months!)...

At the end of day 2, Andrei, Herb and Scott graciously agreed to spend some time discussing various modern C++ topics and, even better, answering questions from the community. In fact, the questions from Niners (and a conversation on reddit/r/cpp) drove the conversation.

Here's what happened...

[more]