1373. Customizable traits should have their own headers

Section: 22.2 [utility] Status: NAD Submitter: BSI Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [utility].

View all issues with NAD status.

Discussion:

Addresses GB-79

The library provides several traits mechanisms intended a customization points for users. Typically, they are declared in headers that are growing quite large. This is not a problem for standard library vendors, who can manage their internal file structure to avoid large dependencies, but can be a problem for end users who have no option but to include these large headers.

[ 2010 Rapperswil ]

There was no enthusiasm for touching char_traits or regex_traits. Consensus to move iterator_traits, allocator_traits and pointer_traits to their own respective headers once wording supplied.

[ 2010 Rapperswil ]

After some discussion, consensus is that moving these features into separate headers does not buy much in practice, as the larger headers will inevitably be included anyway. Resolve as NAD.

[ Resolution proposed in ballot comment ]

Move the following traits classes into their own headers, and require the existing header to #include the traits header to support backwards compatibility:

iterator_traits (plus the iterator tag-types)
allocator_traits
pointer_traits
char_traits
regex_traits

[ 2010 Batavia: ]

Closed as NAD with the rationale below.

Rationale:

This suggest is not a defect, as the likely benefit is small, if any, compared to the cost of not just implementating the feature, but also explaining/teaching it.

Proposed resolution: