On Wed, Oct 1, 2014 at 9:16 AM, Howard Hinnant <[email protected]> wrote: > On Oct 1, 2014, at 12:00 AM, Arthur O'Dwyer <[email protected]> wrote: >> On Tue, Sep 30, 2014 at 6:47 PM, Eric Fiselier <[email protected]> wrote: >>> >>> http://reviews.llvm.org/D4467 >> >> Incidentally, and sorry if this is a dumb question, but what's the >> rationale for libc++ allowing either >> >> using A = std::array<double,3>; >> A a; >> std::tuple<A> t; >> t = a; > > The rationale for this is to support an extension which has been proposed for > standardization here: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3680.html > > This proposal makes the tuple constructor taking U… implicit if all U… > implicitly construct from all T…. This greatly aids (for example) in > returning tuple types from factory functions: > > std::tuple<int, int, int> > foo() > { > return {3, 4, 5}; > } > > >> or >> >> using A = std::array<double,3>; >> A a; >> std::tuple<double,double,double> t; >> t = a; > > This is another extension. This example would already work if A is pair, > instead of std::array. libc++ introduces the concept of “tuple-like”, and > tuple cleanly interoperates with tuple-like types. The set of tuple-like > types are pair and array. One might imagine making complex tuple-like as > well. > > See <__tuple> for the __tuple_like<T> trait which controls this behavior. > > This extension has not been proposed for standardization.
Thanks, Howard. :) –Arthur _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
