Specify semantics of passing nested views to RPC

[Amir Kamil]

This is supported in the implementation but is being left unspecified in the 2018.03.31 milestone release. Discussion of this is in the comments for commit a6bf567 and in PR #2. Here are some relevant details from one of the comments:

The type transformations will be nontrivial to specify. Consider the example of view<view<double, std::list<double>::iterator>, std::list<view<double, std::list<double>::iterator>>::iterator> turning into view<view<double, double*>, deserializing_iterator<view<double, double*>>> (the example in the commit discussion). This is not the same as the currently specified transformation of view<T, IterType> to view<T, deserializing_iterator<T>> (for non-DefinitelyTriviallySerializable T). Rather, it transforms view<T, IterType> to view<U, deserializing_iterator<U>> where T undergoes a recursive transformation to U.

What I see as the right way to do this is to define a type transformer, e.g. deserialized_t<T>, specify that RPC turns T into deserialized_t<T>, and then specify that deserialized_t<view<T, IterType>> is equivalent to view<deserialized_t<T>, view_default_iterator_t<deserialized_t<T>>>. We could then discuss whether or not to allow user types to provide an asymmetric deserialized type using this mechanism.

[Dan Bonachea]

This issue was triaged at the 2018-06-13 Pagoda meeting and assigned a new milestone/priority.

[Amir Kamil]

Comment copied from implementation issue 355:

We do not officially support nested views (spec issue 122), but we do have a test of them in test/view.cpp. That test assumes that view<view<T, Iter1>, Iter2> deserializes as view<view<T>>, which is not compatible with the wording in the spec and Dan’s clarification above. If we do decide to officially support nested views, we will need to tweak the wording to special-case how nested views deserialize.

‌

[Amir Kamil]

Comment copied from PR 47:

Possible text for nested views:

Deserializing a nested view results in a nested view with the default iterator at each level of nesting. Thus, \code{deserialized_type_t<view<view<T, Iter1>, Iter2>>} is \code{view<view<T>>} for any non-view type \code{T}.

‌