Bloated.
What will C++17 be?
81–86 of 86 posts
Re: What will C++17 be?
#82Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n370... operator. (for proxies): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…
Why is uniform call syntax a good addition? What is the benefit? I only ever remember hearing of one programming language supporting it, and I can't even remember what it is. Maybe it was Nim?
It can simplify templates; allowing you to treat free functions and class methods the same way.
Re: What will C++17 be?
#83Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n370... operator. (for proxies): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…
Pattern matching might be similar to this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344...
Source code (implemented with a lot of help from C macros): https://github.com/snaewe/typeswitch
Re: What will C++17 be?
#84Earlier quoted context omitted.
Why is uniform call syntax a good addition? What is the benefit? I only ever remember hearing of one programming language supporting it, and I can't even remember what it is. Maybe it was Nim?
It can simplify templates; allowing you to treat free functions and class methods the same way.
I see. Thanks for the reply.
Re: What will C++17 be?
#85Earlier quoted context omitted.
LtU posts about concepts being rejected for c++0x : http://lambda-the-ultimate.org/node/3518 (voted off) http://lambda-the-ultimate.org/node/4450 (suggestions for future work)
There were two fundamentally different proposals for concepts: Indiana— concepts are records of signatures; checking is done "by signature"; an arbitrary mapping (adapter) can be defined. Notable authors: Doug Gregor, Jeremy Siek, Jaakko Jarvi, a lot of others I'm insulting by forgetting. Texas— concepts are predicates of "actions" (usage of signatures; expressions). Notable authors: Bjarne Stroustrup, Gaby Dos Reis;…
To be fair, Stroustrup has made an effort to explain his reason for encouraging the Committee to drop the Indiana proposal ( http://www.drdobbs.com/cpp/the-c0x-remove-concepts-decision/... ).
He's also mentioned the Indiana proposal led to increased compile times (as in at least 100% slower) and that the Committee came up with a ridiculous number of concepts for the standard library, which suggested they were looking at things wrong. For instance, there's little value in having CanCompareForEquality, CanCompareForInequality, HasLessThan, HasGreaterThan, HasLessThanOrEqual, and HasGreaterThanOrEqual be separate concepts; they should be grouped into, say, HasTotalOrdering, EqualityComparable, and HasPartialOrdering. The current STL gets this wrong, it wants a concept of HasPartialOrdering but it actually requires HasLessThan (and fakes equality comparison by assuming if a is not less than b and b is not less than a, then a and b must be equal). I don't fault Stepanov for this mistake, it's not obvious and it's relatively easy to tell people "just implement operator, and others operators < and <=, and yet others operators <, !=, and ==, etc."
Re: What will C++17 be?
#86How about making the language more accessible to newcomers by providing a sane default way of doing package management and builds. Go is a great example of both things done reasonably well out of the box.
That would be the modules proposal. And the standardized ABI.