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.

1056. Must all Engines and Distributions be Streamable?

Section: 29.5 [rand] Status: NAD Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [rand].

View all issues with NAD status.

Discussion:

Both the concepts RandomNumberEngine and RandomNumberDistribution have requirements to be InputStreamable and OutputStreamable.

I have no problems leaving the WP in an inconsistent state on the best-faith assumption these concepts will be provided later, however disagree with the proposers that these constraints are not separable, orthogonal to the basic concepts of generating random number distributions.

These constraints should be dropped, and applied to specific algorithms as needed.

If a more refined concept (certainly deemed useful by the proposers) is proposed there is no objection, but the basic concept should not require persistence via streaming.

[ Batavia (2009-05): ]

Move to Open.

[ 2009-05-31 Alisdair adds: ]

Working on constraining the stream iterators, I have a few more observations to make on the concepts proposed while constraining the random number facility.

While I still believe the concerns are orthogonal, I don't believe the existing constraints go far enough either! The goal we want to achieve is not that a RandomNumberEngine / RandomNumberDistribution supports the stream operators, but that it is Serializable. I.e. there is a relationship between the insert and extract operations that guarantees to restore the state of the original object. This implies a coupling of the concepts together in a broader concept (Serializable) with at least one axiom to assert the semantics.

One problem is that istream and ostream may be fundamentally different types, although we can hook a relation if we are prepared to drop down to the char type and char_traits template parameters. Doing so ties us to a form of serialization that demands implementation via the std iostreams framework, which seems overly prescriptive. I believe the goal is generally to support serialization without regard to how it is expressed - although this is getting even more inventive in terms of concepts we do not have today.

[ 2009-11-03 Alisdair adds: ]

I can't find the record in the wiki minutes, but it was agreed at both Frankfurt and Santa Cruz that this issue is NAD.

The agreement in SC was that I would provide you with the rationale (see below) to include when moving to NAD.

[ 2009-11-03 Howard adds: ]

Moved to Tentatively NAD after 5 positive votes on c++std-lib.

Proposed resolution:

Rationale:

The issue suggests a more refined concept should be used if we want to require streaming, to separate concerns from the basic RandomNumberEngine behaviour. In Frankfurt it was observed that RandomNumberEngine is that more refined concept, and the basic concept used in the framework is UniformRandomNumberGenerator, which it refines.

We concur, and expect this to have no repurcussions re-writing this clause now concepts are removed.