This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 1373. Customizable traits should have their own headers

Section: 20.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: