Skip to content

The Standard should defend container constructors from bad CTAD #4261

Description

From #4254:

Stephan T. Lavavej (@StephanTLavavej)

Found by the upcoming libcxx update, where they test CTAD for (Iter, Iter, BadAlloc) and expect it to SFINAE away.

(The explicit deduction guides are already constrained to take only things that qualify as allocators. The issue is that every constructor generates an implicit guide, and those can lead to the container being instantiated with a BadAlloc unless we guard against that.)

It's actually unclear to me whether this is guaranteed by the Standard, but the defense is simple and we already do this in basic_string.

Casey Carter (@CaseyCarter)

It's not guaranteed but IMO it should be. The Standard tells us to do so explicitly for basic_string.

The Standard has wording for deduction guides but not for constructors. This is slightly confusing since pre-Standard language in WG21 used "implicit" and "explicit" deduction guides to distinguish between the function templates derived from constructors for use in CTAD and those derived from deduction guides.

We ought to file an LWG issue.

Note that this goes beyond the sequence container constructors with (Iter, Iter, BadAlloc); there are also scenarios with the associative containers found by libcxx that I haven't yet fixed, and presumably others.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    LWG issue neededA wording defect that should be submitted to LWG as a new issueduplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions