Date: Mon, 10 Feb 2020 21:25:30 -0800
I'm tempted to start teaching this as soon as wording has consensus.
On Mon, 10 Feb 2020 at 11:06, Jonathan Wakely via Lib-Ext <
lib-ext_at_[hidden]> wrote:
> [I sent this from the wrong address so it got bounced, sorry]
>
>
> Strike the "valid but unspecified" definition. Stop using it.
>
> Up-front in the "method of description" front matter, state some things
> about standard library types:
>
> "Types defined in the standard library describe preconditions on their
> functions and operations. Those functions can be used whenever
> preconditions
> hold (implying functions without preconditions can always be called). These
> guarantees hold during the object's entire lifetime (including after the
> object has been moved from)."
>
> This reinforces [basic.life]. Of course the object meets its invariants
> (whatever that means) so let's not say that, it is tautological. Now we
> never need to say "the object is in a valid but unspecified" state in the
> specification of standard library types. It's just a truism that they are
> always valid.
>
> Also add:
>
> "For program-defined types the standard library does not require that
> objects have a state where all supported operations are still allowed to
> be used.
> [Note: this follows from the fact that the library cannot know a
> program-defined type's preconditions on its operations.]
> The operations required on a type by standard library components
> are explicitly specified, and (except for equality preserving operations)
> are only performed on the values provided as arguments [Note: For example,
> such operations are not performed on values created after an object has
> been moved, unless specified otherwise.]"
>
> We might then need to make it very clear that assignment and swap are
> required to work for any value, including moved-from.
>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2020/02/14469.php
>
On Mon, 10 Feb 2020 at 11:06, Jonathan Wakely via Lib-Ext <
lib-ext_at_[hidden]> wrote:
> [I sent this from the wrong address so it got bounced, sorry]
>
>
> Strike the "valid but unspecified" definition. Stop using it.
>
> Up-front in the "method of description" front matter, state some things
> about standard library types:
>
> "Types defined in the standard library describe preconditions on their
> functions and operations. Those functions can be used whenever
> preconditions
> hold (implying functions without preconditions can always be called). These
> guarantees hold during the object's entire lifetime (including after the
> object has been moved from)."
>
> This reinforces [basic.life]. Of course the object meets its invariants
> (whatever that means) so let's not say that, it is tautological. Now we
> never need to say "the object is in a valid but unspecified" state in the
> specification of standard library types. It's just a truism that they are
> always valid.
>
> Also add:
>
> "For program-defined types the standard library does not require that
> objects have a state where all supported operations are still allowed to
> be used.
> [Note: this follows from the fact that the library cannot know a
> program-defined type's preconditions on its operations.]
> The operations required on a type by standard library components
> are explicitly specified, and (except for equality preserving operations)
> are only performed on the values provided as arguments [Note: For example,
> such operations are not performed on values created after an object has
> been moved, unless specified otherwise.]"
>
> We might then need to make it very clear that assignment and swap are
> required to work for any value, including moved-from.
>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2020/02/14469.php
>
Received on 2020-02-10 23:28:21