[lib] Replace bad uses of "instantiation" with "specialization"#8379
Conversation
eisenwave
added
the
P1-Important
| pointers, the library class | ||
| \tcode{complex}, |
There was a problem hiding this comment.
While we are here...should we also change this to say "specializations of complex" or something similar? complex is certainly not a class.
There was a problem hiding this comment.
Akin? Analogous to?
"Comparable to" would probably be the most natural term, but that's overloaded in C++ too.
There was a problem hiding this comment.
"In other words, value types." also looks broken. I guess it's better to fix this later.
Affected sections: - [allocator.requirements.general] - [namespace.std] - [pointer.traits.types] - [allocator.traits.types] - [tuple.general] - [format.context] - [numeric.requirements] - [rand.util.canonical] - [thread.req.lockable.timed] - [thread.sharedtimedmutex.requirements.general] In [rand.util.canonical], it would be clearer to just say `generate_canonical` instead of "the instantiation" or "the specialization". Drive-by change: - In [tuple.general], change "is similar to" to "behaves similarly to" to avoid confusing with "similar types" in the core specification.
frederick-vs-ja
force-pushed
the
lib-no-bad-instantiations
branch
from
1703553 to
f7b3241
Compare
|
While there might be other changes we want to pursue in this area, the changes in this pull request are an improvement as they are. |
| @@ -7761,7 +7734,7 @@ | |||
| \recommended | |||
| For a given type \tcode{charT}, | |||
| implementations should provide | |||
There was a problem hiding this comment.
Although it's a separate issue, is "provide" the right word here?
The library should use a single specialization for such cases, but it doesn't provide it in any way that users can access or use for themselves.
5 participants
Affected sections:
In [rand.util.canonical], it would be clearer to just say
generate_canonicalinstead of "the instantiation" or "the specialization".Drive-by change:
Fixes #8222.