Here's my basic test code:
#include <iostream>
#include <variant>
int main(int argc, char** argv) {
std::variant<int> v{5};
std::cout << std::get<0>(v) << std::endl;
}
When I compile it using Clang as follow: clang++ -std=c++1z -g Sources/main.cpp
I'm getting these errors:
In file included from Sources/main.cpp:2:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:235:46: error: cannot cast 'std::variant<int>' to its private base class
'std::__detail::__variant::_Variant_storage<true, int>'
return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:1192:35: note: in instantiation of function template specialization
'std::__detail::__variant::__get<0, std::variant<int> &>' requested here
return __detail::__variant::__get<_Np>(__v);
^
Sources/main.cpp:6:20: note: in instantiation of function template specialization 'std::get<0, int>' requested here
std::cout << std::get<0>(v) << std::endl;
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:878:7: note: constrained by private inheritance here
: private __detail::__variant::_Variant_base<_Types...>,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:235:74: error: '_M_u' is a private member of
'std::__detail::__variant::_Variant_storage<true, int>'
return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:878:7: note: constrained by private inheritance here
: private __detail::__variant::_Variant_base<_Types...>,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/variant:377:34: note: member is declared here
_Variadic_union<_Types...> _M_u;
But when I compile with GCC, with the same options, I haven't any errors, and I get the right output (5).
So I would like to know if it is really an implementation bug or if it comes from me.
