Vec::operator[] use-after-move does not abort

[nigeltao]

PRINCIPLES.md says:

No use-after-move. All types abort if they are used after a move.

However:

TEST(Vec, UseAfterMoveAllowsCreatingBadPointer) {
  struct T {
    uint8_t pre_padding[0xBAD'0000];
    int field;
  };
  auto x = Vec<T>();
  auto y = std::move(x);
  int* bad_ptr = &x[0].field;  // Use-after-move but does not abort.
  printf("%p\n", bad_ptr);     // Prints "0xbad0000\n".
}

Is this Working As Intended?

[danakj]

TBH I'm not sure the best way to address use after move yet. I still have some hope that it's possible to ban it with static analysis, by banning move-from fields.

I had more use-after-move checks in Tuples but it was painful, C++ has some limitations here. :/

[nigeltao]

Yeah, ubiquitous runtime UAM checks might be too hard.

Perhaps, as a compromise, have "std::move(x)leaves x as if it was just default-constructed; there's no further runtime checks" as the guiding principle. x would be safe to use, in that there's no Undefined Behavior, but using it would still be bad practice that static analysis can hopefully pick up. "As if default-constructed, valid and specified" is stronger (more predictable and hence safer) than cppreference.com's Unless otherwise specified, all standard library objects that have been moved from are placed in a "valid but unspecified state".

Or taking it to an extreme, "as if default-constructed, as in the previous paragraph, but without any stigma". It's legit to assume that a moved-from Vec is empty, a moved-from Option is None, etc. No static analysis needed.

Just thinking out loud, and I haven't thought for very long about it.

[danakj]

Unfortunately not all types are default constructible. An example being Result<T, E>. Neither T nor E need be default constructible, and a default-constructed Result would not be holding either one.