[lmi] default-member-initializers vs. is_trivial

[Greg Chicares]

Vadim--Do you happen to know why default member initializers
prevent a default ctor from being trivial? The Standard is clear:

[class.default.ctor/3]
| A default constructor is trivial if it is not user-provided and if:
[...]
| no non-static data member of its class has a default member initializer

but I'd like to understand the purpose of that particular requirement.
If the reason is that a default member initializer might throw, then
a constexpr value could surely be allowed. For example, given
  struct foo{int i {1};};
shouldn't a compiler be able to default-construct a 'foo' quite easily?

Anyway, commit 10299f32061c6 attempts to show why I agonized over this.
Is it capricious for me to ignore is_trivially_default_constructible-ness
and forge blithely ahead, figuring that the compiler can optimize this
parameter-object well enough already? I'm tending to think that providing
default member initializers is a best practice, but I don't see why I
should care about trivial-constructibility of this object when it's
already trivially copyable and moveable.

I found this article interesting:
  https://foonathan.net/2021/03/trivially-copyable/
but all I've been able to conclude from it so far is that "triviality"
is deeper than I had imagined, and that I don't really understand it.
Am I missing something important?