[func.wrap.func.con], [func.wrap.move.class], [func.wrap.copy.class], [any.class.general] Reword avoidance of 'dynamically allocated memory' as 'nesting an object within' #7328
Conversation
… [any.class.general] Reword avoidance of 'dynamically allocated memory' as 'nesting an object within'
|
|
||
| \pnum | ||
| Implementations should avoid the use of dynamically allocated memory for a small contained value. | ||
| Implementations should nest an object within\iref{intro.object} |
There was a problem hiding this comment.
The first "an object" seems both vague and unhelpful. Surely there is already some object nested within the any -- but the point is that there's a very specific object (namely the one that the user wants to store) should be nested within the any. The original wording was clearer about that since it at least said "contained value".
There was a problem hiding this comment.
I'm a bit confused about your comment. This is just applying the wording idiom that LWG came up with and replacing a term that is entirely undefined within the standard. That seems like a clear improvement (arguably an objective bug fix).
The part
for a small contained value
... remains unchanged, so why are you pointing out that its existence makes only the old wording clearer? Did you misread and come to the conclusion that that part is being deleted?
2 participants
Partially addresses #7261.
This PR replaces the informal "avoid the use of dynamically allocated memory" terminology with the more formal "should nest an object within" terminology, which similar to "is nested within", seen in LWG4141.
This does not yet fix all such issues pointed out in #7261 for the sake of keeping this PR minimal.