这是一个简单的例子， 我们可以定义一个低级union，如下所示：
static union
{
uint64_t a;
uint8_t b[8];
};
但是我们不能像这样声明std::variant(请不要关心语法，如果我错了，请纠正我！，抓住这个想法)
std::variant<uint64_t, uint8_t[8]> v
CPP偏好明确指出，
模板参数
类型- 可能存储在此变体中的类型。所有类型都必须是(可能符合 cv 标准的)非数组对象类型
此外，MSVC-v141(C++17) 编译器给出了编译错误：
错误 C2338 变体要求所有 T 都是非阵列 对象类型 ([variant.variant]/2)。
std::variant主要是一个类模板，因此，问题是它无法推断数组类型存储，因为它只需要数据布局/表示？
在国家机构评论 US116 之后，对数组的支持在 P0510R0 年被删除，我在下面转载：
支持 阵列替代方案似乎不起作用 不出所料。 例如，如果任何替代方案 是一个数组，当前规范无法满足 要求所有 6 个关系运算符的子句，并且 丢失(不应参与过载解决) 复制构造函数、移动构造函数、复制赋值 运算符，移动赋值运算符(尽管 交换函数将正常工作)。 很难 激活阵列替代方案 - 尽我所能 理解，它必须被安置，没有 参数，以便对数组进行值初始化，以及 然后每个元素的值可以赋值为 需要。 其中许多问题将得到解决，如果 数组替代方案是通过存储 std：：array 改为，然后将仅公开的数组成员(std：：array) 给 get 函数，但这似乎是一个实验性的变化 应该为下一个标准进行调查。 为 C++17，我们应该放弃对数组的支持(但不是 std：：array)作为替代方案，以便在下一个标准中留出正确支持它们的自由。
在std::variant提案的最初修订期间，似乎没有过多考虑数组类型的可能性，尽管对引用类型和无效类型的情况进行了一些考虑(P0510R0年也删除了对这些类型的支持)，并且一些修订通过强加Destructible要求(最终标准文本中不存在)来隐含地禁止数组。一旦标准草案被发送给国家成员机构，有人注意到阵列会带来困难，因为它们无法以预期的方式复制、移动或比较。所有这些问题也许都可以通过在规范和实现(成员比较等)中使用特殊大小写数组来解决，但这项工作留待将来对标准进行修订。