Clarify normative status of future helper types

[Dan Bonachea]

Currently many of the prototypes in the API sections of the spec rely on the following "future helper types", which are never formally specified:

• future_element_t
• future_element_moved_t
• future_invoke_result_t

The "Notes to Implementers" appendix provides "possible implementations of template metaprogramming utilities for UPC++ features", implying that these helper types might be considered normative features. However it appears the current implementation does not actually provide these type utilities, ie if a user attempted to use them directly they would currently get a type name not found error.

I think we need to decide whether or not these "helper types" are normative (my inclination would be no) and make a clear statement about it. If we decide they are normative then they need paragraphs in an API section with a description and a backing implementation. Otherwise we need to document that these tokens are stand-ins for unspecified TMP goop implementing the specified semantics (and we probably still need to define what those semantics are). The "documented stand-ins" approach is a bit at odds with how we handled CType and RType (sec 7.2.2), which is even more reason to be clear about the normative status for these identifiers.

[Amir Kamil]

I'd prefer for them to be normative so that the user can take advantage of the types in their own template code.

[john bachan]

That sounds good, but not for this release as they are definitely not there.

[Dan Bonachea]

This issue was triaged at the 2019-07-24 Pagoda issue meeting and assigned a new milestone.

It makes sense to fix this along with serialization which will add at least one additional helper type

[Dan Bonachea]

This was discussed in the 2020-02-12 meeting and deferred to next release milestone.

[Dan Bonachea]

We discussed this in the 2020-07-15 meeting and the consensus was that we should not advertise these as normative, because there are cases where the computed type does not match the current implementation - specifically for "spooky" futures returned from when_all and operations chained on them like when_all().then(). So we currently cannot provide a compliant implementation of these helper types that computes the exactly correct type for all cases.

We could clearly mark these appendix types as "for explanatory purposes only" (or similar), however we'd need to avoid giving the impression of a type precision that does not exist in practice. Alternatively, we could remove the appendix entirely and add carefully worded prose sections describing the types they specify, (as we did with CType and RType in sec 7.2.2).

[Amir Kamil]

Excise non-normative future helper types. Fixes Issue #135.

→ <<cset 8ef2095c865a>>

[Amir Kamil]

Merged in akamil/upcxx-spec/issue135 (pull request #44)

Excise non-normative future helper types. Fixes Issue #135.

Approved-by: Dan Bonachea [e-mail]

→ <<cset 7dd7dd8b48d0>>