C++ version (C++11, 14, or 17) for the spec

[Amir Kamil]

What version of C++ should the API references adhere to? We have a choice of C++11, 14, or 17. I'm not in favor of C++17, since it has not yet been approved. But using C++14 over C++11 can simplify some of the code in the API reference.

Note that I'm only asking about the spec here. The actual implementation can be backwards compatible with C++11 even if the spec is written with C++14.

A concrete example where this is relevant is where we need the result type of a function call. For instance, here is the current (non-standards-compliant) declaration of future<T...>::then():

template<typename ...T>
template<typename Lambda>
/*future<?>=*/decltype(to_future(lam(std::declval<T>()...)))
  future<T...>::then(Lambda lam);

Here are some standards-compliant formulations:

• C++11:

template<typename ...T>
template<typename Lambda>
decltype(to_future(typename std::result_of<Lambda, T...>::type))
  future<T...>::then(Lambda lam);

• C++14:

template<typename ...T>
template<typename Lambda>
decltype(to_future(std::result_of_t<Lambda, T...>))
  future<T...>::then(Lambda lam);

• C++17:

template<typename ...T>
template<typename Lambda>
decltype(to_future(std::invoke_result_t<Lambda, T...>))
  future<T...>::then(Lambda lam);

This example is just for illustration. I'm actually planning to reformulate it further as follows (using C++17 here):

template<typename Func, typename... ArgTypes>
using future_invoke_result_t = decltype(to_future(std::invoke_result_t<Func, ArgTypes...>));

template<typename ...T>
template<typename Lambda>
future_invoke_result_t<Lambda, T...> future<T...>::then(Lambda lam);

Which do you prefer for the spec?

[Former user]

Good question. I think 14 should be fine.

[BrianS]

what is wrong with C++11 std::result_of ?

That is the C++11 version of what 17 is using for invoke_result.

[Amir Kamil]

C++11 is lacking std::result_of_t, which was introduced in C++14. This means we'd have to use typename std::result_of<L, T...>::type rather than std::result_of_t<L, T...>. I think the former is much more cumbersome.

[Former user]

I just emailed Bryce about this and he says he doesn't have a simple answer. Unfortunately I take that to mean there is a good reason to stick to C++11 but it would take him too much work to explain. I'm all in favor of playing fast and loose with this version of the spec. This is the "marketing" spec after all.

[BrianS]

I've been using the ::type prefix in prototyping. It is not that much more cumbersome. I do not know under what conditions it fails to work though.

Given that most target collaborations will be C++11 at best I think we need to put V1.0 out with C++11 structure.

I'm trying to find a concise and compact "synopsis" for the start of each section, and have the pedantic API as the end of each section. I think it is OK to have the hand-waving or 14/17 magic forms in the synopsis and the pedantic C++11 at the end.

[Amir Kamil]

I think we need to prioritize readability for our users, and I think the combination of the typename prefix and the ::type suffix is much less readable than the C++14 alternative. I would suggest having a separate C++11 compatibility section in the spec if we want to list the C++11 alternatives.

[b]

If the question is "what version of C++ should the document use", I don't care at all. The document is just pseudo-code after all. Hand waving is fine.

Brian, please don't do what you described with the synopsis up front and the API at the back, I don't think this is wise if users are meant to read the document. But, I don't think the purpose of this document is clear so I defer to others.

The question of what version of C++ the implementation should support is really just the question "how many compilers and platforms do we intend to support", which is really a question about workforce and time investment. I don't think we have the manpower to support more than clang and gcc, so C++14/17 is fine.

[BrianS]

The Intel compiler will be required for ECP. We will also have to work with whatever compilers they deliver on Summit and Sierra. Maybe it will be clang, but then again the host my be xlC as the preferred compiler.

Pagoda is 100% funded by DoE ECP effort, we will run in the platforms our users want to run on. I think C++14 is fine. but we will have users with builds based on C++11. In those cases they won't have to change their build flags to accommodate us. I think the safe compromise is a C++14 spec document, and note and implementation for users staying with C++11.

for similar reasons I will resist compiler flags for our package, or .rc files.

[Scott Baden]

UPC++ is not 100% funded by ECP and looking forward that may continue.

[b]

Brian,

I am sorry but asking to support xlc is completely and totally unreasonable.

Please be aware that ALCF ported Clang/LLVM and invested years of effort into bgclang because they thought that was a more viable path to a C++11 compiler than betting on xlc.

Supporting xlc would mean we cannot use C++11. Supporting ICPC would mean we cannot use C++14, and we would be encouraging people to use a compiler that has terrible codegen for C++.

I am not sure what you mean by fully funded. It is still unclear to me who will write the C++ code for this project, but I think you, John and I will lead that effort. I do not believe we have the workforce or time investment to support compilers like xlc (or even Intel), at least at first. I want us to be cautious about how we use precious engineering hours so that the project can be more successful and impactful.

-- Bryce Adelstein Lelbach aka wash Lawrence Berkeley National Laboratory ISO C++ Committee Member CppCon and C++Now Program Chair

Transmitted from my Android Mobile Command Center

[Dan Bonachea]

I believe this issue is resolved in Spec 1.0 Draft 2.
Language compliance-level details are mostly avoided by the normative sections, and the Appendix collects some template goop and shows both C++11 and C++17 versions.

The question of which compilers will be supported by our implementation is an implementation issue. The Sept'17 release supports clang and gcc. Issue 9 in that repo tracks the current status of adding support for Intel C++.