A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://cplusplus.github.io/LWG/issue3060 below:

XXX_scan algorithms are specified to work with move-only T, but are specified to make N copies of T into the destination range

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

3060. XXX_scan algorithms are specified to work with move-only T, but are specified to make N copies of T into the destination range

Section: 26.10.8 [exclusive.scan], 26.10.9 [inclusive.scan], 26.10.10 [transform.exclusive.scan], 26.10.11 [transform.inclusive.scan] Status: New Submitter: Billy O'Neal III Opened: 2018-02-06 Last modified: 2019-01-20

Priority: 2

View all other issues in [exclusive.scan].

View all issues with New status.

Discussion:

All of the scan algorithms ([exclusive.scan], [inclusive.scan], [transform.exclusive.scan], [transform.inclusive.scan]) have language like "If init is provided, T shall be MoveConstructible (Table 23); otherwise, ForwardIterator1's value type shall be MoveConstructible.". However, the algorithms operational semantics require that that type be written "by copy" to the destination range, making support for move only types impossible.

We probably need to examine real implementations of these things and see what requirements are actually necessary, as in general GENERALIZED_SUM and GENERALIZED_NONCOMMUTATIVE_SUM need to specify the type used to store intermediate calculations.

[2019-01-20 Reflector prioritization]

Set Priority to 2

Proposed resolution:

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4