C++ Logo

std-proposals

Advanced search

Re: [std-proposals] is_trivially_copyable_in_reality

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Mon, 26 Jan 2026 10:47:22 +0000
On Sat, Jan 24, 2026 at 11:16 PM Jason McKesson wrote:
>
> Why would a class simultaneously 1) contain "several 512-byte RSA key
> pairs", 2) not otherwise be disqualified from bytewise-copies, 3) be
> polymorphic, and 4) need to be byte-wise copied frequently enough for
> this many changes to the standard to be worthwhile? When does this
> happen in real applications?
>
> Saying that a class *could* contain these things, that these
> circumstances *could* occur is speculation. What real-world
> applications would this actually be useful in?


In the Chromium codebase, inside "pc/video_rtp_receiver.cc", there is
a member function that returns a vector by value:

    std::vector<scoped_refptr<MediaStreamInterface>>
VideoRtpReceiver::streams() const;

The "scoped_refptr" class is polymorphic.

Also in "pc/rtp_transceiver.h":

    std::vector<rtc::scoped_refptr<RtpSenderProxyWithInternal<...>>>
senders() const ;

And also a few more similar functions inside "pc/peer_connection.h".

In the WebKit codebase, we have:

    Vector<RefPtr<WebProcessProxy>> WebProcessProxy::allProcesses();

In the Firefox codebase, there is "nsTArray<RefPtr<SomeInterface>>".

I'm just thinking now that a defect report might be in order, rather
than a proposal.

Specifically, "is_copy_constructible_v<T>" should be true for
polymorphic types that are marked 'final'. Having this trait evaluate
to false for 'final' classes is a defect.

Received on 2026-01-26 10:47:34