The "good" example for LP2 says span<string> when it means span<char>.
Both examples for LP2 misuse seeding: obviously constructing random_device
is not going to be "latency-preserving," and then on top of that mt19937
gen(r()) does not uniformly initialize the generator. See "The Twitter App
Mystery <http://www.pcg-random.org/posts/cpp-seeding-surprises.html>" for
the problem and P0205 "Allow Seeding Random Number Engines with
random_device" <https://github.com/jensmaurer/papers/issues/325> for the
solution.

LP3's example is not very good, because surely real code (even if not
latency-sensitive) would just document this precondition, maybe even use
C++2a contracts to document it, but never even check it, let alone throw if
the check fails. (And if we do bother to check and the check fails, we'd
probably just abort(), in the absence of any motivation to do otherwise.)

LP4 is slightly misleading when it *equates* TriviallyCopyable with
StorableInRegisters. Trivial copyability is currently necessary, but not
sufficient, for getting passed and returned in registers. For example,
std::array<int, 1000> is trivially copyable on every implementation I'm
aware of, but it will not be passed or returned in registers on *any* ABI
I'm aware of. I would prefer to see the pro-TriviallyCopyable position
motivated by something other than ABI concerns, and then a separate
guideline that gives motivation and strategies for reducing the overall
size of your data types.

I wish the examples for LP4 didn't use `rand()`. How about using something
like complex<int>::operator+ as a motivating example?

LP5 looks incomplete, and/or maybe the final page wasn't meant to be blank?

HTH,
Arthur


On Tue, Feb 26, 2019 at 10:57 AM Tjernstrom, Staffan <
Staffan.Tjernstrom_at_[hidden]> wrote:

> I had a bit of time to spare, and decided to attempt to re-write Niall's
> D1027 into something a bit more Core Guideline-like (as we discussed a few
> months ago). Apologies that I haven't been able to author it into the SG14
> github, but we don't have authenticated access here at work. If this seems
> promising I'll work out a way of getting it up there.
>
> Comments / flames very much invited.
>
> Kind Rgds
> Staffan Tj.
>
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments
> is confidential. If you are not the intended recipient, please notify the
> sender immediately by reply and immediately delete this message and all its
> attachments. Any review, use, reproduction, disclosure or dissemination of
> this message or any attachment by an unintended recipient is strictly
> prohibited. Neither this message nor any attachment is intended as or
> should be construed as an offer, solicitation or recommendation to buy or
> sell any security or other financial instrument. Neither the sender, his or
> her employer nor any of their respective affiliates makes any warranties as
> to the completeness or accuracy of any of the information contained herein
> or that this message or any of its attachments is free of viruses.
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>