Opened 13 years ago
Closed 12 years ago
#4137 closed Bugs (wontfix)
boost::program_options::value_semantic missing 's' at the end
Reported by: | anonymous | Owned by: | Vladimir Prus |
---|---|---|---|
Milestone: | To Be Determined | Component: | program_options |
Version: | Boost 1.42.0 | Severity: | Cosmetic |
Keywords: | Cc: |
Description
I am not a native english speaker, but isn't value_semantic missing 's' at the end?
Change History (7)
follow-up: 2 comment:1 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Replying to vladimir_prus:
Thanks for the report. It is missing 's' indeed ('semantic' is adjective, 'semantics' is noun). However, I suspect changing it at this point will break source and binary compatibility, and therefore we're stuck with this naming forever.
You could provide the necessary typedefs
comment:4 by , 12 years ago
Replying to vladimir_prus:
That would still break ABI, I believe. Am I wrong?
typedef value_semantic value_semantics;
Note the order.
I'm not sure that Boost.ProgramOptions could/should provide any ABI compatibility given that Boost as a whole doesn't provide such.
comment:5 by , 12 years ago
Usage of the 'value semantic' phrase should be fixed in the docs regardless of the class name.
comment:6 by , 12 years ago
Milestone: | Boost 1.43.0 → To Be Determined |
---|
Is there a specific example in the docs that you think should be changed? I've just looked through them and it seems that "value_semantic" (without the 's') is used everywhere except in one case, where it is referring to one or more objects, and so the 's' on the end seems appropriate.
comment:7 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Since no one has responded, I am closing this ticket. If anyone has specific bugs in the docs, please re-open the ticket with pointers.
Thanks for the report. It is missing 's' indeed ('semantic' is adjective, 'semantics' is noun). However, I suspect changing it at this point will break source and binary compatibility, and therefore we're stuck with this naming forever.