Why is std::seed_seq non-copyable according to C++11, and why doesn't gcc/clang conform?

Question

Consider the following minimal example:

// main.cpp
#include <random>

int main(int, char **)
{
  std::seed_seq seed1{1337, 42};
  std::seed_seq seed2(seed1);
  std::seed_seq seed3 = seed2;
  return 0;
}

According to the C++ standard, this shouldn't compile, as std::seed_seq is neither copy constructible, nor copy assignable.

However, this compiles fine with both g++ 4.9, and clang 3.4

g++-4.9 -std=c++11 -Wall main.cpp
clang++ -std=c++11 -Wall main.cpp

The android ndk's llvm-libc++ implementation seems to follow the "not copyable" property of seed_seq. Which can be confirmed in the source at

 android-ndk-r10d/sources/cxx-stl/llvm-libc++/libcxx/include/random:3553

Or by compiling the minimal example using

 ${NDK_HOME}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ \
 -std=c++11 -c -Wall \
 -I${NDK_HOME}/sources/cxx-stl/llvm-libc++/libcxx/include \
 -I${NDK_HOME}/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/include \
 -I${NDK_HOME}/sources/cxx-stl/llvm-libc++/../../android/support/include \
 -isystem ${NDK_HOME}/platforms/android-18/arch-arm/usr/include \
 main.cpp

---

I've previously used this (without being aware of my non-conforming code) to store a copy of the seed for logging purposes.*

I'm left wondering:

1. Why it is that seed_seq isn't copyable?

2. This is the first time I've encountered g++ and clang to not conform to the standard. Is it a conscious decision to deviate from the standard, or is this an implementation bug? How prevalent is this? I'd like to learn more.

---

* I realized that I was thinking of seed_seq wrong, and that if I'm only interested in the seed_seq::param values (the seed_seeq's initial seed values), that I should instead keep my copy in a vector<T>, instead of a type that is meant to generate integers.

Gad

gcc and clang often use the same C++ library implementation (libstdc++), so when there are problems in that, they will be visible in either gcc or clang. It doesn't mean that two independent implementors felt that this was a good idea. – Autophyte

I confirmed that both clang and gcc used the same /usr/include/c++/4.9/bits/random.h file. I wasn't aware of this, even though now that I think of it, I have been confused by this before, and it now makes perfect sense. Thank you. Good to know. – Gad

This program correctly does not compile with libc++, so it's a libstdc++ issue. – Joviality

Reported as bug 65631. For "why isn't it copyable" we'll probably have to dig out the paper/issue that made the change. Judging from LWG issue 972 it wasn't originally that way. – Pippo

open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3037.pdf : "First, the concept was wrong to require copyability (implied by Semiregular). The requirements table therefore imposes no such requirements as CopyConstructible or CopyAssignable. [...]" – Liegnitz

Also, "[Editor’s note: This paragraph has been inserted to address LWG Issue 1069. However, it is unclear (a) whether this is a good idea, and (b) why this type should be made to meet a requirement not imposed on other Seed Sequence types.]". Looks like the logic is 1) there's no reason to require Seed Sequences in general to be copyable/movable; 2) there's no reason to make seed_seq do more than is required of Seed Sequences in general, so 3) the copy functions are deleted. – Pippo

Answer 1

For those who see this in the future, as per T.C. and ecatmur, this is libstdc++ bug 65631. There's no ETA on a fix though; the behavior conformed with the original proposal, but this was changed to remove copyability from the concept to address LWG issue 1069, as per the N3037 paper.

Petua

It feels strange to add an answer that is a overview of the actions performed by the people who commented on the question. (e.g. issuing bug 65631, digging up the N3037 paper). I'm sure those who see this in the future, would also see those comments. I suppose it doesn't hurt to have a summary. – Gad

@Gad -- yeah, having a summary is good; also, there's really no point in letting a question sit around unanswered, yet with comments that add up to an answer :) Would you rather I made this community wiki? – Petua

I have no desire, stake or say in this :-) Do as you please. However, since you ask, giving credit where credit is due seems proper. – Gad