[Review] Type Traits Extension by Frederic Bron - Review summary and decision
Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto? I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_. Frédéric
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
I think this is worse than has_operator_xxx or is_xxxable. - Jeff
At Sun, 27 Mar 2011 15:07:17 -0700, Jeffrey Lee Hellrung, Jr. wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
I think this is worse than has_operator_xxx or is_xxxable.
The C++ standard proposal for concepts used HasXXX (e.g. HasRightShift) for such syntactic tests (see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2502.pdf). I think the word "_operator_" doesn't add much here. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, 29 Mar 2011, Dave Abrahams wrote:
At Sun, 27 Mar 2011 15:07:17 -0700, Jeffrey Lee Hellrung, Jr. wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
I think this is worse than has_operator_xxx or is_xxxable.
The C++ standard proposal for concepts used HasXXX (e.g. HasRightShift) for such syntactic tests (see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2502.pdf). I think the word "_operator_" doesn't add much here.
I anticipate facing a chunk of templated code and saying something like "these templates are breaking for type T, what operators are they dispatching on?". # grep -r have_op_ headers Short, distinctive names may help with the code archaeology side of things. Later, Daniel
Perhaps I'm too late to influence anything, but during my talk at BoostCon, Rob Stewart brought this thread up as it relates to my Generic library. The truth is, I've sort of purposely been staying away from the thread until now because I loathe these types of discussions, but I suppose that I should at least poke my head in and voice my opinion. That said, I hate to make things more complicated, but I faced this operator naming problem when making my Generic library and I used the names specified in N2914 (the last working paper that had concepts), only I converted everything to all lower-case with underscores for spaces. This is similar to what Dave suggested here: On Tue, Mar 29, 2011 at 8:11 AM, Dave Abrahams <dave@boostpro.com> wrote:
The C++ standard proposal for concepts used HasXXX (e.g. HasRightShift) for such syntactic tests (see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2502.pdf). I think the word "_operator_" doesn't add much here.
If anyone wants to see all of the operator names that I used in one place, as based on N2914, see slide 67 of my talk: https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic.... The only ones on that table that don't come directly from N2914 are the ones that didn't have an associated "HasXXX" concept, which are, iirc, -> ->* new new[] delete delete[] For the above few operators I just picked names that made the most sense to me and I doubt there is much controversy with respect to them anyway. The operator() concept also used a different concept name in N2914 (it's not HasCall, it's Callable), and so I settled on simply "call". As I mentioned, there was a very brief discussion of this thread and my rationale during the talk, so I'll link that whenever the video becomes available. In short, given that these names were all listed in the last working paper which had concepts, I'd say that they are the closest thing that we have to a complete and consistent set of operator names in the standard. At the very least, I present the above list as a reference for the names that C++0x concepts would have used had they not been cut. -- -Matt Calabrese
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
I like short prefixes when they are meaningful, but is_add/is_addition/is_plus means nothing. is_callable_add/is_callable_addition/is_callable_plus isn't much better (though using the "is_" prefix and "_callable" suffix works: is_addition_callable). "is_" seems to work well for some, like is_equal_to, until you realize that the implication is whether two types are equal, not whether the equality operator can be used with the two types. "can_add" works for the addition case, but works awkwardly for equality: "can_equal_to." "can_call_" seems to be a nice, reasonably short prefix: can_call_addition, can_call_equal_to, can_call_bitwise_xor, can_call_left_shift, etc. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
I like short prefixes when they are meaningful, but is_add/is_addition/is_plus means nothing.
sigh ... I assume this is clear for everyone, particularly as Frédéric's proposal has an additional suffix _callable in combination here. I am particularly interested if there is a rational against a short prefix *in general* as Frédéric's statement
... but I like to have a common prefix longer than is_.
seem to imply such a general rule. Frédéric, are you generally prefer prefix name extensions? Why not consider suffixes, if they read better, e.g. xxxx_is_callable or xxxx_callable or (shorter and may implicitly be correct for "is_" and "are_") xxxx_applicable Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
I like short prefixes when they are meaningful, but is_add/is_addition/is_plus means nothing.
sigh ... I assume this is clear for everyone, particularly as Frédéric's proposal has an additional suffix _callable in combination here.
I'm sorry to frustrate you, but I took the foregoing to ask whether something like "is_plus" would work.
I am particularly interested if there is a rational against a short prefix *in general* as Frédéric's statement
... but I like to have a common prefix longer than is_.
seem to imply such a general rule. Frédéric, are you generally prefer prefix name extensions? Why not consider suffixes, if they read better, e.g.
I have no problem with a short prefix per se. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
I like short prefixes when they are meaningful, but is_add/is_addition/is_plus means nothing.
is_callable_add/is_callable_addition/is_callable_plus isn't much better (though using the "is_" prefix and "_callable" suffix works: is_addition_callable). "is_" seems to work well for some, like is_equal_to, until you realize that the implication is whether two types are equal, not whether the equality operator can be used with the two types.
"can_add" works for the addition case, but works awkwardly for equality: "can_equal_to."
"can_call_" seems to be a nice, reasonably short prefix: can_call_addition, can_call_equal_to, can_call_bitwise_xor, can_call_left_shift, etc.
These naming debates tend to become a little tiring. Given the names that have been chosen in the standard and other boost libraries and a simple and uniform semantics of these operator traits I would prefer a naming that is simple and uniform as well. As I stated in my review already I can live with a simple has_xxxx where xxxx are most unifying names as proposed in https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
is_callable_add/is_callable_addition/is_callable_plus isn't much better
"can_call_" seems to be a nice, reasonably short prefix: can_call_addition, can_call_equal_to, can_call_bitwise_xor, can_call_left_shift, etc.
These naming debates tend to become a little tiring. Given the names that have been chosen in the standard and other boost libraries and a simple and uniform semantics of these operator traits I would prefer a naming that is simple and uniform as well.
OK, but I didn't think I was suggesting otherwise.
As I stated in my review already I can live with a simple
has_xxxx where xxxx
are most unifying names as proposed in https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
I know that, but there is wiggle room yet in what goes in your MUP column and I was proposing "can_call_" as a shorter version of Frédéric's "is_callable_" idea that reads better and is shorter. Since he raised the question, he apparently hasn't accepted your "has_" prefix suggestion yet and is still fishing for ideas. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mon, 28 Mar 2011, Stewart, Robert wrote:
Joachim Faulhaber wrote:
2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
As I stated in my review already I can live with a simple
has_xxxx where xxxx
are most unifying names as proposed in https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
I know that, but there is wiggle room yet in what goes in your MUP column and I was proposing "can_call_" as a shorter version of Frédéric's "is_callable_" idea that reads better and is shorter. Since he raised the question, he apparently hasn't accepted your "has_" prefix suggestion yet and is still fishing for ideas.
I kind of like something like has_op_X or check_op_X as a naming scheme. Clear, short, and distinctive. While names like can_call_X or is_X_callable work, they don't emphasize that X is an operator nor do they seem distinctive for text searches. Also, the naming table on the wiki may be missing a few entries. Compare table 5.1.3 in the following link. (I am not recommending its abbreviations, just its coverage.) http://www.codesourcery.com/public/cxx-abi/abi.html#mangling Later, Daniel
Is there any problem related to using a short prefix like "is_"?
I have nothing against "is_" but what follows must be descriptive enough, "is_xxxx" is too short. I do not like to add "able" to all operators because it looks strange for some of them (needs to add "_comparable" for <, >,...; "orable", "andable", "xorable" are very strange...). "has_xxxx" looks too short to me and the review reveiled that "has_operator_xxxx" or "has_xxxx" alone was confusing because it is the wrong meaning: we are not testing if the types have the operator (as member) but if that operator can be applied. However, I like the new proposal from Stewart (thank you) "can_call_xxxx" which could also be "can_apply_". I like it because: - it means what it checks, - they will all be sorted alphabetically; what happens when I want to use such a trait? I remember easily the prefix and go straight ahead to the alphabetical list to get the end. Not so easy with a suffix. Now the question is do we need "_operator" in the name which seems logical to me: "can_call/apply_operator_xxxx". But it is quite long. Some propose just "_op" -> "can_call/apply_op_xxxx". This is not something that will be written very often when used so that maybe a longer name is better because then when you read it again months later, you understand it immediately. Kind regards for all comments received, Frédéric
Message du 29/03/11 02:29 De : "Frédéric Bron" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
Is there any problem related to using a short prefix like "is_"?
I have nothing against "is_" but what follows must be descriptive enough, "is_xxxx" is too short. I do not like to add "able" to all operators because it looks strange for some of them (needs to add "_comparable" for <, >,...; "orable", "andable", "xorable" are very strange...). "has_xxxx" looks too short to me and the review reveiled that "has_operator_xxxx" or "has_xxxx" alone was confusing because it is the wrong meaning: we are not testing if the types have the operator (as member) but if that operator can be applied.
However, I like the new proposal from Stewart (thank you) "can_call_xxxx" which could also be "can_apply_". I like it because: - it means what it checks, - they will all be sorted alphabetically; what happens when I want to use such a trait? I remember easily the prefix and go straight ahead to the alphabetical list to get the end. Not so easy with a suffix.
Now the question is do we need "_operator" in the name which seems logical to me: "can_call/apply_operator_xxxx". But it is quite long. Some propose just "_op" -> "can_call/apply_op_xxxx". This is not something that will be written very often when used so that maybe a longer name is better because then when you read it again months later, you understand it immediately.
Hi, I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator? BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library? Thanks, Vicente
I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator? BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library?
I have updated this page for this (last column of the table): https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators This is my current proposal which is very close to Boost.Proto apart for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus (to keep symmetry with unary_plus). If I do not see too much yuk on this proposal by end of this week (Sun. April, 3rd), this is what I am going to use. Regards, Frédéric
On Tue, 29 Mar 2011, Frédéric Bron wrote:
I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator? BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library?
I have updated this page for this (last column of the table): https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators This is my current proposal which is very close to Boost.Proto apart for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus (to keep symmetry with unary_plus).
Those names are a bit long... Here are some brainstormed names. I reduced "operator" to "op" for uniform brevity. assert_op_equal_to affirm_op_equal_to can_call_op_equal_to check_op_equal_to confirm_op_equal_to detect_op_equal_to find_op_equal_to has_op_equal_to // implies the operator belongs to a class.. have_op_equal_to // better form of the verb probe_op_equal_to test_op_equal_to trait_op_equal_to verify_op_equal_to Reducing underscore counts is good for the fingers. Here are a few options there. I picked "check" for uniformity. Most of the prefixes above would also work. check_op_equal_to // base X_op_Y form check_opequal_to opcheck_equal_to checkop_equal_to check::op_equal_to check_op::equal_to Again, I'm still not seeing the predicates for operators like "," and "->". Was that by design? (Sorry; I missed most of the conversation.) - Daniel
Daniel Herring wrote:
Here are some brainstormed names. I reduced "operator" to "op" for uniform brevity.
assert_op_equal_to
-1 There's no assertion.
affirm_op_equal_to confirm_op_equal_to
-1 The use is to enable/disable compilation in most cases. No affirmation or confirmation of anything occurs.
can_call_op_equal_to
+1 Better without the "op_" part.
check_op_equal_to
-1 Shorter than "can_call" but doesn't connote the right idea to me.
detect_op_equal_to find_op_equal_to probe_op_equal_to
-1 Detecting/finding/probing isn't the same as ascertaining whether it is possible to call the operator.
has_op_equal_to // implies the operator belongs to a class..
Agreed. Membership isn't the question.
have_op_equal_to // better form of the verb
"Has" works fine if you consider the question to be whether the pair of types, used in an expression, supports the operator. However, this still has the membership connotation.
test_op_equal_to
-1 This isn't far from being acceptable, but the "test" prefix is too general to be meaningful.
trait_op_equal_to
-1 Meaningless.
verify_op_equal_to
-1 This is better than "test" but still too general.
Reducing underscore counts is good for the fingers. Here are a few
+1
options there. I picked "check" for uniformity. Most of the prefixes above would also work.
check_op_equal_to // base X_op_Y form
check_opequal_to opcheck_equal_to checkop_equal_to check::op_equal_to check_op::equal_to
-1 Namespaces have been rejected and the compressed form doesn't read as well and only saves a single underscore. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/3/29 Frédéric Bron <frederic.bron@m4x.org>:
I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator? BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library?
I have updated this page for this (last column of the table): https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators This is my current proposal which is very close to Boost.Proto apart for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus (to keep symmetry with unary_plus).
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable") agree on "negate". Why celebrate diversity here?
If I do not see too much yuk on this proposal by end of this week (Sun. April, 3rd), this is what I am going to use.
I don't think component "operator_" should be inserted. The prefix "can_call_operator_" accounts for over 60% of information of the proposed names. Name components shall only be added, if they carry indispensable information. Yet the fact, that we deal with operators here is completeley clear from the context of use. Apart from that I think can_call_xxxx is o.k. and I can also live with is_callable_xxxx has_xxxx Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
2011/3/29 Joachim Faulhaber <afojgo@googlemail.com>:
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable")
correction "negatable" is not in boost::operators. Yet in contrast to unary_minusable, negatable is expressible. If negatable is truly admissible or rather negligible might be negotiable ;)
agree on "negate". Why celebrate diversity here?
Joachim
Joachim Faulhaber wrote:
2011/3/29 Frédéric Bron <frederic.bron@m4x.org>:
I have updated this page for this (last column of the table): https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators This is my current proposal which is very close to Boost.Proto apart for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus (to keep symmetry with unary_plus).
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable") agree on "negate". Why celebrate diversity here?
I agree with Frédéric. Consistency with "unary_plus" is beneficial. It would be possible to include both, I suppose, but I'd prefer "unary_minus" to "negate." The name in the standard is not for a type trait, but a function object which, as you know, I don't find a compelling precedent. ISTR that Eric was willing to alter Proto to match any common naming to produce intra-Boost consistency, so Proto's use of "negate" may be of limited import.
I don't think component "operator_" should be inserted. The prefix "can_call_operator_" accounts for over 60% of information of the proposed names. Name components shall only be added, if they carry indispensable information. Yet the fact, that we deal with operators here is completeley clear from the context of use.
+1 I'm not concerned with length for typing's sake so much. Instead, the name lengths must be considered in light of their effect on line lengths when used in expressions like "typename boost::enable_if<boost::can_call_bitwise_and_assign<T,U>,my_type>::type". The longer the name, the sooner line wrapping applies. If the "operator" part is considered important, then I'd definitely prefer "op" over "operator" because of the latter's length and because it is a common abbreviation of "operator" and "operation," which both work in this context.
Apart from that I think can_call_xxxx is o.k. and I can also live with is_callable_xxxx has_xxxx
That makes three of us, at least, in favor of the "can_call" prefix. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/3/30 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/29 Frédéric Bron <frederic.bron@m4x.org>:
I have updated this page for this (last column of the table): https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators This is my current proposal which is very close to Boost.Proto apart for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus (to keep symmetry with unary_plus).
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable") agree on "negate". Why celebrate diversity here?
I agree with Frédéric. Consistency with "unary_plus" is beneficial.
Where exactly is the benefit of creating a deviation from a naming that is already consistent across the standard and boost libraries?
It would be possible to include both,
For me uniformity is the major value here: Simplicity, uniqueness across libraries, ease of use for users. In contrast: Diversity? multiplicity? What value is added? Every developer on earth who is deeply disturbed by a perceived violation of symmetry is free to write her own functor template. In my own library I renamed some functions after Barend told me that there are different identifiers for them in geometry standards, although I liked my function names better. I love name convergence. It allows us to perceive higher level patterns and fosters abstraction. Sometimes one has to let go from ones personal views, likes and dislikes to achieve this. BTW, something like naming convergence taking place across different software libraries on a global level without hierarchies and application of force is a little miracle in itself. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/30 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable") agree on "negate". Why celebrate diversity here?
I agree with Frédéric. Consistency with "unary_plus" is beneficial.
Where exactly is the benefit of creating a deviation from a naming that is already consistent across the standard and boost libraries?
Could you have expressed that question any more negatively? Why are you trying to be obtuse? The obvious answer is that if one discovers and uses "unary_plus," one would quite easily assume that the related trait is "unary_minus." Furthermore, I don't agree that the standard uses "negate" for this purpose. Proto does, of course. That means I see no convention "consistent across the standard and boost libraries."
It would be possible to include both,
For me uniformity is the major value here: Simplicity, uniqueness across libraries, ease of use for users.
Sure. I was just trying to suggest that it is possible to make both camps happy -- so long as they don't have to read one another's code.
In my own library I renamed some functions after Barend told me that there are different identifiers for them in geometry standards, although I liked my function names better. I love name convergence. It allows us to perceive higher level patterns and fosters abstraction. Sometimes one has to let go from ones personal views, likes and dislikes to achieve this.
I agree easily with this result, given the weight of the industry terminology, but I contend that doesn't apply in this case. The only precedent I recognize in the "negate" case is Proto's name. It's the same reason I argue against "multiplies" and "divides." Those names are reasonable for function objects, but they are not the right names for the operators. Clearly, you and I won't see this the same way, but the names aren't up to us. Frédéric will make a choice and we'll accept it whether or not it matches our own predilection. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/3/30 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/30 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
Standard and boost (proto, accumulator, phoenix, ..., boost::operator: "negatable") agree on "negate". Why celebrate diversity here?
I agree with Frédéric. Consistency with "unary_plus" is beneficial.
Where exactly is the benefit of creating a deviation from a naming that is already consistent across the standard and boost libraries?
Could you have expressed that question any more negatively? Why are you trying to be obtuse?
Don't take it too personal. Generally I like your fine sense for precise and nuanced naming. In this case I have a strong opinion that leads me to a different conclusion. We may agree that we disagree here ;) Cheers, Joachim
2011/3/29 Frédéric Bron <frederic.bron@m4x.org>:
Is there any problem related to using a short prefix like "is_"?
I have nothing against "is_" but what follows must be descriptive enough, "is_xxxx" is too short. I do not like to add "able" to all operators because it looks strange for some of them (needs to add "_comparable" for <, >,...; "orable", "andable", "xorable" are very strange...).
is_xxxxable, will lead to some of those difficulties. I recognized that when I summarized the wiki table for a Most Unifying Proposal. I think a simple schema prefix_xxxx or xxxx_suffix is the best solution.
"has_xxxx" looks too short to me
not to me
and the review reveiled that "has_operator_xxxx" or "has_xxxx" alone was confusing because it is the wrong meaning: we are not testing if the types have the operator (as member) but if that operator can be applied.
Unfortunately I started this discussion. Meanwhile has_xxxx is one of my favorites.
However, I like the new proposal from Stewart (thank you) "can_call_xxxx" which could also be "can_apply_". I like it because: - it means what it checks,
is_callable_xxxx or xxxx_is_callable are good names as well. I'd prefer xxxx_is_callable, because it seems closest to natural language.
- they will all be sorted alphabetically;
with and without prefix ...
what happens when I want to use such a trait? I remember easily the prefix and go straight ahead to the alphabetical list to get the end. Not so easy with a suffix.
To me such considerations are of almost no significance. Sequences of lists and synoptic tables are always subject to the context of usage. For instance many times people are searching operators under the aspect of precedences. Would we start prefixing the operator names with precedence_i_has_operaotor_xxxx only to support ease of perception for this particular aspect? The basic naming of entities that are so fundamental to a language like operators should IMO be completely free from considerations like this.
Now the question is do we need "_operator" in the name which seems logical to me: "can_call/apply_operator_xxxx". But it is quite long.
yes
Some propose just "_op" -> "can_call/apply_op_xxxx". This is not something that will be written very often when used so that maybe a longer name is better because then when you read it again months later, you understand it immediately.
op_ is an abbreviation which is generally discouraged in std/boost naming. operator_ is a prefix that is redundant, because it is clear from the context. Best, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
At Mon, 28 Mar 2011 09:42:29 +0200, Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open
What about is_callable_plus, is_callable_plus_assign, ... i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
I know that is_xxxx_callable reads better but I like to have a common prefix longer than is_.
Is there any problem related to using a short prefix like "is_"?
The problem is that it tends to connote conformance to semantic requirements as well as syntactic ones. That's why we had EqualityComparable and HasEqual in the standard proposal for concepts. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I have updated the type traits extension for operators: - new names beginning with can_call_ - simpler names for helper traits - fixed typos in documentation - dont_care as default return type; check for exact void return when Ret=void - names of template parameters now begin with a capital letter followed by lower case letters (RHS->Rhs, LHS->Lhs, RET->Ret...) - removed non ASCII characters This updated version can be downloaded by different ways: - from the sandbox (r71385): http://svn.boost.org/svn/boost/sandbox/type_traits/ - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension& Headers only: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only-dos.tar.bz2&directory=Extension& Documentation: http://svn.boost.org/svn/boost/sandbox/type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html (best presented in tarball). It is not finished; more to come... Frédéric PS: Please, find below the list of chosen names. I would appreciate not to start again a discussion about the good/bad of this choice. I am sure there are at least 2 persons that like it, sorry if not more... However feel free to report any typo as it is probably also in the code. # binary + can_call_addition - can_call_subtraction * can_call_multiplication / can_call_division % can_call_modulus += can_call_addition_assignment -= can_call_subtraction_assignment *= can_call_multiplication_assignment /= can_call_division_assignment %= can_call_modulus_assignment & can_call_bitwise_and | can_call_bitwise_or ^ can_call_bitwise_xor &= can_call_bitwise_and_assignment |= can_call_bitwise_or_assignment ^= can_call_bitwise_xor_assignment << can_call_left_shift >> can_call_right_shift <<= can_call_left_shift_assignment >>= can_call_right_shift_assignment == can_call_equal != can_call_not_equal < can_call_less <= can_call_less_equal > can_call_greater >= can_call_greater_equal && can_call_and || can_call_or # prefix ! can_call_not + can_call_unary_plus - can_call_unary_minus ~ can_call_complement * can_call_dereference ++ can_call_pre_increment -- can_call_pre_decrement # postfix ++ can_call_post_increment -- can_call_post_decrement
On 4/19/2011 6:29 PM, Frédéric Bron wrote:
I have updated the type traits extension for operators: - new names beginning with can_call_ - simpler names for helper traits - fixed typos in documentation - dont_care as default return type; check for exact void return when Ret=void - names of template parameters now begin with a capital letter followed by lower case letters (RHS->Rhs, LHS->Lhs, RET->Ret...) - removed non ASCII characters
Thanks, Frederic.
Hi Frédéric, 2011/4/20 Frédéric Bron <frederic.bron@m4x.org>:
I have updated the type traits extension for operators: - new names beginning with can_call_ - simpler names for helper traits - fixed typos in documentation - dont_care as default return type; check for exact void return when Ret=void - names of template parameters now begin with a capital letter followed by lower case letters (RHS->Rhs, LHS->Lhs, RET->Ret...) [..] It is not finished; more to come...
Frédéric
[..]
+ can_call_addition - can_call_subtraction * can_call_multiplication / can_call_division [..] += can_call_addition_assignment [..]
PS: Please, find below the list of chosen names. I would appreciate not to start again a discussion about the good/bad of this choice.
I am sorry that I don't live up to your expectations here, but I think that you did not complete the discussion about the rationals of good naming for those names and that I did not see you addressing arguments that I raised, specifically those that prefer inter library consistency over personal taste...
I am sure there are at least 2 persons that like it, sorry if not more...
... and that the naming issues on operator traits shall not be a question of taste, whether someone likes them or dislikes them temporarily, but a question of usability and cross library simplicity that honors the choices made by others in the past and acknowledges the fact, that those choices can not be altered without breaking existing code. When I read your list of name choices I noticed that I got pretty annoyed. And then I wondered why this issue upsets me so much. I realized that I value the effort of maintaining naming uniformity, consistency and simplicity *across* libraries a lot and I think it is pretty unwise to sacrifice that value for temporary and personal matters of taste. Moreover I feel that important arguments and efforts pursuing that goal have not been addressed in the discussion. I don't think it is boost style or good style in general to end an open discussion like this by declaration of a final list. Your list of final namings (in this thread) introduces a number of names that are neither used for the analogous identifiers in the standard nor in Boost.Proto or other boost libraries. I see you deliberately introducing a diversification of names without giving a justification. (1) I think that this ignores my main argument that cross library naming consistency is more important than local taste considerations. (2) I also think that you ignore choices of other language and library designers that have been made in the past, including the choice to value consistency over personal taste. Implied in ignoring those choices is the attitude that their choices from the past are inferior to your current choices. (3) I feel that efforts made to support cross library naming consistency by e.g. setting up the wiki page are ignored and unused. (4) The new choices are inconsistent to the standard and prevailing boost libraries and are in addition inconsistent in themselves: (4.1) I see you using prefer the grammatical form of substantives now. Hmm, ok. So addition for plus, assignment for assign etc. If you choose "addition" instead of "plus", you should consistently also use "conjunction" instad of "and", "disjunction" instead of "or". If you use "assignment" instead of assign, you should also use "equality" instead of "equal" and "negation" instead of "unary_minus" and so on. (4.2) Instead of reducing diversity and enhancing cross library naming consistency you seem to introduce new problems. (5) I think the rationals and rules you are working with for naming choices are in themselves inconsistent and changing. (5.1) In the last version of your docs you justified your name choices referring to choices made in the standard (although not following this rule consistently), which I strongly second. Now your seem to abandon this maxim completely. (5.2) In the review version of you library extension, you chose the has_ prefix in order to be consistent with you parent library that uses the same prefix for many of its traits. Now you are introducing inconsistency against your parent library using a novel prefix can_call_. (6) If we consistently chose to the best of our current knowledge names and ignoring prevailing names, what would happen. Suppose we had a bunch boost authors each of them working on a library that has some names refering to operators. (6.1) Author A finds substantives unfortunate and feels the rule that a name associated to a operator should be completable to its concept name and she thinks that prefix has_ is nice because Boost.Typetraits uses is already: She chooses has_add, has_subtract, has_multiply, has_divide,... instead of can_call_addition, can_call_subtraction, ... (6.2) For a different library referring to operators in some way author B considers, that operators can be implemented for different semantics. Therefore he chooses for extremely good reasons general names. He loves his names to be auto sorted by those general names first, so he chooses a suffix: for + : combine_is_applicable, - : uncombine_is_applicable, * : product_is_applicable, / quotient_is_applicable (6.3) Author C has the insight, that authors before her were ignorant of the fact, that any specific or general name suffers from that fact that implementing a special semantics for the operator may lead to a wrong meaning anyway. So deliberately she chooses names that refer to the syntactic nature of the op sign: For +: has_plus, -: has_minus, *: has_asterisk. /: has_slash, ^ : has_caret etc. (6.4) Author D loves Haskell and short concise naming. He decides that the applicability of an operator is nicest expressed by the third form of a verb like "adds" which means that addition can be called on some matching signature of types. So he chooses: For +: adds, -: subtracts, *: multiplies, /: divides (6.5) Author E ... etc. (6.5) Every Author X is deeply convinced of their points of view and finds some support in discussions on the list, so they decide, that their personal superior choice of naming is indispensable. So each of them implements their own superior naming in their library ignoring their fellow authors and the namings that have been chosen in the past. They might regret a little that very similar things are now expressed more and more diverse in the lands of c++ and boost and that users might constantly stumble over problems related to that naming chaos. (7) Behavior described in (6) not only is malicious, because it leads to naming chaos where users not only are hampered but also disgusted. It also leads to hodgepodge of different rules and rationals. In contrast to that a rule that aims to maintain inter library naming consistency is very simple (See my concrete proposal here https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators). I'd like to propose a meta rule A naming consistency L that is local, temporary and specific has to be sacrificed for a naming consistency G that is global, durable and general, even if G contains partial inconsistencies from a current point of view. Local: Single library Global: Cross library and/or language stadard Temporal: New library Durable: Existing libraries are affected. Specific: A current discussion. Specific point of view General: A general process relating to many libraries Finally as I have done before I'd like to stress that this is not a small thing. Since operators are at the core of the language, I expect that your operator type traits will be used by thousands of developers for years and decades. Naming inconsistencies will make it more difficult for them to memoize, use and manipulate operator traits in their programs. This means that in choosing names you have a responsibility not only to serve your taste but to serve the users. Inconsistency is very easily created but it is impossible to get rid of it, once your extension is in the boost release and people start writing programs. So my request is this: Please use those names that are the *most unifying names* with respect to the language standard and the existing boost libraries. These names or name components are contained in the MUP column of the wiki page: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators ... and please don't confuse me further ;-) As I just looked to the wiki page I fould that meanwhile there are *3* different versions of *your* proposals for your names! (1) The list in this thread. Flavor "substantives" (2) The list edited by you in the wiki page. Columns proposed new names and (3) a new table with different names yet again. I hope you'll get my point. Please don't take it too personal, if I appear a little harsh. It's because I think inter library consistency really matters a lot. Confused and frustrated .... Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/4/20 Frédéric Bron <frederic.bron@m4x.org>:
I have updated the type traits extension for operators: - new names beginning with can_call_ - simpler names for helper traits [..] + can_call_addition - can_call_subtraction * can_call_multiplication / can_call_division [..] += can_call_addition_assignment [..]
PS: Please, find below the list of chosen names. I would appreciate not to start again a discussion about the good/bad of this choice.
I am sorry that I don't live up to your expectations here, but I think that you did not complete the discussion about the rationals of good naming for those names and that I did not see you addressing arguments that I raised, specifically those that prefer inter library consistency over personal taste... [snip] ... and that the naming issues on operator traits shall not be a question of taste, whether someone likes them or dislikes them temporarily, but a question of usability and cross library simplicity that honors the choices made by others in the past and acknowledges the fact, that those choices can not be altered without breaking existing code.
Well, since you restarted the discussion, I'll add a bit more myself in answer to your charges and conclusions. I'm sure this comes as a surprise. :)
When I read your list of name choices I noticed that I got pretty annoyed. And then I wondered why this issue upsets me so much. I realized that I value the effort of maintaining naming uniformity, consistency and simplicity *across* libraries a lot and I think it is pretty unwise to sacrifice that value for temporary and personal matters of taste.
First, let's note that your concerns are matters of taste as well. Your persistence that, for example, consistency with functor names in traits names is merely one of taste. My taste differs, of course, on that point. Let's also note that reasonable people can disagree on points of relative value and taste without getting carried away.
Moreover I feel that important arguments and efforts pursuing that goal have not been addressed in the discussion.
Really? Myriad arguments were raised on all sides of the issue *during* the discussion. With matters of taste, ultimately, there can be no right answer. I don't know what more Frédéric could have done.
I don't think it is boost style or good style in general to end an open discussion like this by declaration of a final list.
I think Frédéric followed both Boost style and good style. He suggested names. He considered other suggestions. He tried to find common ground. He considered arguments and rationales. He, as the library author, produced a final set in the hopes of finally putting the discussion to rest.
Your list of final namings (in this thread) introduces a number of names that are neither used for the analogous identifiers in the standard nor in Boost.Proto or other boost libraries. I see you deliberately introducing a diversification of names without giving a justification.
The reasons for the names were part of the discussion. Do you mean that the names should be justified in the documentation?
(1) I think that this ignores my main argument that cross library naming consistency is more important than local taste considerations.
There was no true consistency among the libraries. First, this library queries capabilities, so it differs from many of the others in purpose. Thus, naming differences are reasonable. The same is true of Boost.Operator concept names: they differ from the other libraries because their purpose is different. Second, there were some names that were inconsistent among the existing libraries. That means some choices must be made and those are matters of taste.
(4.1) I see you using prefer the grammatical form of substantives now. Hmm, ok. So addition for plus, assignment for assign etc. If you choose "addition" instead of "plus", you should consistently also use "conjunction" instad of "and", "disjunction" instead of "or".
Those names were selected because they name the operations, as commonly expressed, rather than worrying about grammatical consistency. I know that I refer to the "addition operator," not the "plus operator" or "add operator," etc. I know that some do use "plus operator," but that's a minority in my experience. I certainly never refer to the "conjunction operator." The names in the latest list look reasonable to me from that viewpoint.
If you use "assignment" instead of assign, you should also use "equality" instead of "equal" and "negation" instead of "unary_minus" and so on.
Your argument for "equality" is sound, but then what are the names for <, >, etc.? By contrast, I think "equal" is consistent with "less_than," etc. It is common to refer to operator ==() as "operator equal," but I generally use "equality operator," so I'd be happy with using "equality." The choice of "unary_minus" versus "negation" was for consistency with "unary_plus," of course, for which there doesn't appear to be a viable alternative.
(4.2) Instead of reducing diversity and enhancing cross library naming consistency you seem to introduce new problems.
You see problems where I see none.
(5.1) In the last version of your docs you justified your name choices referring to choices made in the standard (although not following this rule consistently), which I strongly second. Now your seem to abandon this maxim completely.
If it was inconsistently applied, then reconsidering that approach was wise. Furthermore, other arguments were made which were, apparently, compelling, if different from yours.
(5.2) In the review version of you library extension, you chose the has_ prefix in order to be consistent with you parent library that uses the same prefix for many of its traits. Now you are introducing inconsistency against your parent library using a novel prefix can_call_.
This is disingenuous. During the naming discussion, it was plain that "has_" was disliked by a number of people because these traits were unlike the existing ones. What's more, not every trait in Boost.TypeTraits begins with "has_." "can_call_" seems the best choice among the suggested alternatives when applied across the full set of these new traits. (Others worked better or worse, depending upon the trait to which they were attached.)
(6) If we consistently chose to the best of our current knowledge names and ignoring prevailing names, what would happen. Suppose we had a bunch boost authors each of them working on a library that has some names refering to operators.
This is a straw man argument. The names in the list are not widely divergent and are quite reasonable for many reasons. Besides, I believe Eric was willing to consider modest alterations, suggesting he wasn't convinced that he had selected the best names. [snip scenarios of libraries using different naming conventions]
(7) Behavior described in (6) not only is malicious, because it leads to naming chaos where users not only are hampered but also disgusted. It also leads to hodgepodge of different rules and rationals. In contrast to that a rule that aims to maintain inter library naming consistency is very simple (See my concrete proposal here https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators).
Your proposal is based upon your own tastes. I, for one, found fault with it as you well know. Consequently, it can hardly be considered unambiguously better.
Finally as I have done before I'd like to stress that this is not a small thing. Since operators are at the core of the language, I expect that your operator type traits will be used by thousands of developers for years and decades. Naming inconsistencies will make it more difficult for them to memoize, use and manipulate operator traits in their programs.
We certainly agree here. However, you have different notions of where conformance is applicable and not. "A foolish consistency is the hobgoblin of little minds" is a quote I try to keep in my mind in such discussions because I can get carried away with naming, etc. In this case, I think creating a self-consistent set of traits is as important as one that kowtows to existing names. If a trait were named in the standard, I would in no way suggest deviating from it. However, the names of functors for operators do not require that traits determining whether the same operator can be called with specific types should be identical. I see absolutely no reason to consider those names as precedent for the traits names.
So my request is this: Please use those names that are the *most unifying names* with respect to the language standard and the existing boost libraries. These names or name components are contained in the MUP column of the wiki page: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
According to your tastes, those might be the "most unifying names," but not to mine.
(1) The list in this thread. Flavor "substantives" (2) The list edited by you in the wiki page. Columns proposed new names and (3) a new table with different names yet again.
Surely that shows that Frédéric was appropriately influenced by the discussion, gained useful ideas, and created a new list that he likes better than those he created before. Furthermore, his recent post indicated the list you should be studying now. Why is that a problem? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/4/21 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/4/20 Frédéric Bron <frederic.bron@m4x.org>:
I have updated the type traits extension for operators: [snip] ... and that the naming issues on operator traits shall not be a question of taste, whether someone likes them or dislikes them temporarily, but a question of usability and cross library simplicity that honors the choices made by others in the past and acknowledges the fact, that those choices can not be altered without breaking existing code.
Well, since you restarted the discussion, I'll add a bit more myself in answer to your charges and conclusions. I'm sure this comes as a surprise. :)
Hey Robert, I really didn't expect to meet you here in this thread ;) Nice surprise though!
When I read your list of name choices I noticed that I got pretty annoyed. And then I wondered why this issue upsets me so much. I realized that I value the effort of maintaining naming uniformity, consistency and simplicity *across* libraries a lot and I think it is pretty unwise to sacrifice that value for temporary and personal matters of taste.
First, let's note that your concerns are matters of taste as well.
I don't like the names that the standard chose for the operator-functors and that proto and other libs adopted either, which are plus, minus, multiplies, divides and, if I could choose freely according to my personal preferences and *taste*, today I would probably choose: add, subtract, multiply, divide. But my preference are different: (1) Simplicity and uniqueness across standard and libraries which enhances (2) Usability: Memorability. Ease of refactoring via textual substitution. Perception of reoccurring patterns (3) Honoring and respecting choices of other language and library designers in the past. So I defer personal taste in favor of the more valuable goal of inter library naming consistency. And I did that. In my own library I had chosen some names that I liked very much (taste) an I replaced them which other names that I did not like so much, that were found in other libraries and standards: (consistency goal).
Your persistence that, for example, consistency with functor names in traits names is merely one of taste. My taste differs, of course, on that point.
As everyone knows the functor objects in question are very thin wrapper classes around operators that just call the wrapped operator. It is completely reasonable to start from there using these names for the operators in other contexts. IMO yours this a very weak argument. You are stressing a tiny technical point, while I'd like to look at the big picture.
Let's also note that reasonable people can disagree on points of relative value and taste without getting carried away.
... your sidenote makes me wonder whether wise people would reply to an open sharing in such a way. And another argument. Given that one agrees on the goal of inter library naming consistency, the choice of names is determined by the prevailing names and can be chosen by an algorithm. So my approach is also not a matter of taste here. The best, "most unifying" choices can be computed and a measure of the consistency can also be computed. Completely in absence of taste. This, by the way, makes the choices extremely simple and easy to do, so one can concentrate on more interesting work instead of loosing oneself in matters of taste.
Moreover I feel that important arguments and efforts pursuing that goal have not been addressed in the discussion.
Really?
Maybe you can help me finding the threads, where my main argument has been addressed. And where it has been addressed by Frederic. You did some remarks e.g. 2011/3/24 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
Comparing the names I tried to find "Most Unifying Proposals" for names in column MUP:
https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
The summary table was helpful, Joachim. Thanks.
Oh, thank you for that :)
Names in the standard are certainly appropriate candidates for use in the Type Traits library, even if I would rather the standard's names were different.
And you also reiterated your argument of the big difference between operators and operator-functors in order to argue that naming consistency efforts were not applicable.
Myriad arguments were raised on all sides of the issue *during* the discussion.
On my main argument of inter library naming consistency there were only a few pretty weak ones. Maybe you can cite some more.
With matters of taste, ultimately, there can be no right answer.
Yeah, and global naming consistency is not a matter of personal taste but a matter of transpersonal beauty, (1) the beauty of simplicity and uniqueness (2) the beauty of a large group of people agreeing in an evolutionary process of convergence.
I don't know what more Frédéric could have done.
Making a strong case against that and for his choices and why they need to introduce divergence. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
Yeah, and global naming consistency is not a matter of personal taste but a matter of transpersonal beauty, (1) the beauty of simplicity and uniqueness (2) the beauty of a large group of people agreeing in an evolutionary process of convergence.
I agree that naming consistency is not a matter of taste, but you could have supported that point better. Naming consistency is of practical value because of "Usability: Memorability. Ease of refactoring via textual substitution. Perception of reoccurring patterns". Naming consistency makes the library easier to use in the larger context of boost, the language and the standard library. Ease of use is not a matter of taste and is a very important consideration for library design. If taste is at odds with ease of use considerations ease of use should always win. People can disagree on how much naming consistency helps ease of use in this case, but calling that concern a matter of taste is just wrong. Boost libraries are frequently hard to use, the so called "expert friendly" characteristic. We should make extra effort to design for ease of use. Luke
Joachim Faulhaber wrote:
2011/4/21 Stewart, Robert <Robert.Stewart@sig.com>:
In my own library I had chosen some names that I liked very much (taste) an I replaced them which other names that I did not like so much, that were found in other libraries and standards: (consistency goal).
You adopted standardized names for the same or similar behavior in your library. That's a good thing.
Your persistence that, for example, consistency with functor names in traits names is merely one of taste. My taste differs, of course, on that point.
As everyone knows the functor objects in question are very thin wrapper classes around operators that just call the wrapped operator.
OK
It is completely reasonable to start from there using these names for the operators in other contexts. IMO yours this a very weak argument.
I consider your argument that they apply weak. Where does that leave us? It's subjective.
You are stressing a tiny technical point, while I'd like to look at the big picture.
I'm stressing that the purpose of the functors is to encapsulate the operation. The purpose of the traits is to determine whether the operation is applicable in a particular context. Since they do different things, have different semantic purposes, they don't need the same names.
Let's also note that reasonable people can disagree on points of relative value and taste without getting carried away.
... your sidenote makes me wonder whether wise people would reply to an open sharing in such a way.
I was referring to the length of your post, and its repetitiveness, but also hoping to preclude much further wrangling.
And another argument. Given that one agrees on the goal of inter library naming consistency, the choice of names is determined by the prevailing names and can be chosen by an algorithm. So my approach is also not a matter of taste here. The best, "most unifying" choices can be computed and a measure of the consistency can also be computed. Completely in absence of taste.
Whether a name should be considered as a precedent can be subjective. Once admitted as applicable, a name should be used to influence future choices. I don't consider the standard functor names or the concept names in Boost.Operators as applicable.
Moreover I feel that important arguments and efforts pursuing that goal have not been addressed in the discussion.
Really?
Maybe you can help me finding the threads, where my main argument has been addressed. And where it has been addressed by Frederic.
I really don't have the time, but my recollection is that everything was discussed at length. I can't, however, control whether you feel that was the case.
Myriad arguments were raised on all sides of the issue *during* the discussion.
On my main argument of inter library naming consistency there were only a few pretty weak ones. Maybe you can cite some more.
You seem to be labeling any counterargument as weak. I think I covered the issues against your MUP more than once now and pretty thoroughly, and that includes discussion of the consistency among the libraries.
global naming consistency is not a matter of personal taste but a matter of transpersonal beauty, (1) the beauty of simplicity and uniqueness (2) the beauty of a large group of people agreeing in an evolutionary process of convergence.
I'm still waiting for that large group to weigh in. We've had some others participate previously, but I suggest letting this ride and get more opinions on the new list. OTOH, if no others weigh in, then Frédéric's choices win, since he's the author (unless John Maddock chooses to intervene). In the meantime, try this exercise. Pretend you've forgotten the traits names (or, because there have been so many, you can't remember any now)! Suppose you're writing code and need to determine whether t @ u can be called, for some operator "@." What is the trait name for that operator, given that you remember it starts with "can_call_," of course? For example, what name do you think of to determine whether t + u is callable? Do you think of "plus," "add," "addition," "addable," or something else? I think of "addition." How about t * u? Is it "multiplication," "multiply," "multiplies," "times," "star," or something else? I think of "multiplication." Do that honestly for each operator and see whether the names in the latest list are what you think of first or close to it. I find Frédéric's latest list about perfect on that score. If there's consensus that the names are very close to ideal when considered this way, then we'll find that those names will make using the library about as good can be.
I don't know what more Frédéric could have done.
Making a strong case against that and for his choices and why they need to introduce divergence.
I'll leave that for him, then, with the caveat that I see much less divergence than you. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Thu, Apr 21, 2011 at 10:29 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Joachim Faulhaber wrote:
[...]
You are stressing a tiny technical point, while I'd like to look at the big picture.
I'm stressing that the purpose of the functors is to encapsulate the operation. The purpose of the traits is to determine whether the operation is applicable in a particular context. Since they do different things, have different semantic purposes, they don't need the same names.
FWIW, I agree with Joachim on this point. Since they both deal with builtin C++ operators (something in common), *it would be nice* if the part of the name referring to the operator (the common part) were the same (or a slightly varied). The semantic difference between the functor and the trait should, IMO, primarily be conveyed by the prefix or suffix or the particular variation on the "primary" operator name. Also, while we're on the topic of what *I* prefer: I still prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits. I can sympathize with arguments against "has_xxx" / for "can_call_xxx", I just never thought they were convincing enough :/ The decision is ultimately Mr. Bron's, though, and I'm sure he's doing his best to try to please everyone :) My 2c, - Jeff
Also, while we're on the topic of what *I* prefer: I still prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits. I can sympathize with arguments against "has_xxx" / for "can_call_xxx", I just never thought they were convincing enough :/
The decision is ultimately Mr. Bron's, though, and I'm sure he's doing his best to try to please everyone :)
There are two things: the names and the prefix. And they are related. About the prefix: I don't like can_call_. It is novel as Joachim says, and AFAIK not widely used, and looking a bit awkward (in my opinion). In such cases I normally use "supports", so: supports_addition, supports_equal, supports_not. It is not shorter (neither longer) but reads more smoothly. Next step: inserting the "operator_ " is even more clear. So supports_operator_not is more convenient: longer, but more clear. Next step: then "has_" is more convenient, because complying to existing practice. So: "has_operator_not". Perfect. But "has_operator_addition" is not perfect, is awkard. This shows the problem, the prefix and the name are related: it should then be has_operator_plus... It is not the "operator_addition" it supports, it is the "operator_plus" it supports (doing an addition). About the names (and the names only), I agree with Joachim, conform to existing practice, don't invent the wheel again. Proto has all of the presented list, but using other terms. So why type types extensions would present another compilation? Why should it be proto::plus and can_call_addition? proto::equal_to and can_call_equal? proto::shift_left and can_call_left_shift Very confusing. OK, it is not consistent among Boost libraries (which is bad), but then take the library having the complete list (which is probably Proto). So I prefer what (if I'm right) has been proposed before: proto::plus and has_operator_plus proto::equal_to and has_operator_equal_to proto::shift_left and has_operator_shift_left all exactly like proto, but having the "has_operator_" prefix. I cannot remember what was the objection to has_, but then supports_ would be the alternative of my choice. The only exception would be, for logical reasons, and_ and or_ and not_, so proto::and_ and has_operator_and proto::or_ and has_operator_or Regards, Barend
Barend Gehrels wrote: Yet another round. Oh boy. I'll address the points you (re)raised, but I plan to stop after this. There's really not much more we can say, unless there's a sudden epiphany. We've covered most everything that can be covered, so I'll just leave things for Frédéric to sort out after this. If you haven't done so, do try the thought experiment I suggested in my reply to Joachim.
There are two things: the names and the prefix. And they are related.
About the prefix: I don't like can_call_. It is novel as Joachim says, and AFAIK not widely used, and looking a bit awkward (in my opinion). In such cases I normally use "supports", so: supports_addition, supports_equal, supports_not. It is not shorter (neither longer) but reads more smoothly.
"can_call_" is novel, but I don't find it awkward. "supports_" is a bit vague, but passable.
Next step: inserting the "operator_ " is even more clear.
Now you run afoul of Joachim and others (including me). I don't think that adds anything useful. It just makes the name longer.
Next step: then "has_" is more convenient, because complying to existing practice. So: "has_operator_not". Perfect.
Nope. As has been noted before, that implies ownership. A global operator doesn't belong to anything, so nothing "has" the operator.
But "has_operator_addition" is not perfect, is awkard.
Yep, but "can_call_addition" works. You could argue that it should be "can_call_addition_operator" but then we reopen an earlier discussion.
This shows the problem, the prefix and the name are related:
They are related and the prefix must not only be sensible, but work for all of the operators, not just a few.
it should then be has_operator_plus... It is not the "operator_addition" it supports, it is the "operator_plus" it supports (doing an addition).
If you go that route, as we've discussed already, then you must use symbol names for all operators and they don't all have convenient names. You'd have "asterisk" or "star," "slash," "percent," etc.
Why should it be proto::plus and can_call_addition? proto::equal_to and can_call_equal? proto::shift_left and can_call_left_shift
Very confusing.
You don't find the admixture of "plus," "multiplies," "equal_to," "negate," and "unary_plus" confusing? I certainly do. To use "plus" implies "asterisk," "equal," and "unary_minus" for a consistent set of names. I missed my chance to object when Proto was being reviewed, but I hope to do better with TypeTraits. Do the thought experiment and see whether the "can_call_" names aren't about right.
OK, it is not consistent among Boost libraries (which is bad), but then take the library having the complete list (which is probably Proto).
That's unfortunate, but all too true. However, Proto is not used nearly as much as TypeTraits, so I'm not sure Proto must be the prototype. I've used TypeTraits often, but have yet to use Proto, as one datum.
So I prefer what (if I'm right) has been proposed before:
proto::plus and has_operator_plus proto::equal_to and has_operator_equal_to proto::shift_left and has_operator_shift_left
With such a list and infrequent use, I know I'll always have to refer to the documentation to figure out the names. Such "consistency" fails to help me in any way. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 21-4-2011 21:42, Stewart, Robert wrote:
Barend Gehrels wrote:
Yet another round. Oh boy. I'll address the points you (re)raised, but I plan to stop after this. There's really not much more we can say, unless there's a sudden epiphany.
Sorry about the other round, but the supports_ is new (I checked) and maybe (didn't check) the relation of prefix/naming and why they are related. As you felt sorry about not being part of the proto review, I think I may take this chance to add something to the type traits after-review, now that it is not yet written in stone and the discussion was revived anyway.
There are two things: the names and the prefix. And they are related.
About the prefix: I don't like can_call_. It is novel as Joachim says, and AFAIK not widely used, and looking a bit awkward (in my opinion). In such cases I normally use "supports", so: supports_addition, supports_equal, supports_not. It is not shorter (neither longer) but reads more smoothly. "can_call_" is novel, but I don't find it awkward. "supports_" is a bit vague, but passable.
I'm not a native speaker, but for me they bear the same meaning. But I've never seen can_call before.
Next step: then "has_" is more convenient, because complying to existing practice. So: "has_operator_not". Perfect. Nope. As has been noted before, that implies ownership. A global operator doesn't belong to anything, so nothing "has" the operator.[...]
Thanks for your explanations. I think that supports_ works right. You are right about ownership, I didn't read all the previous discussions, and didn't realize this when writing my mail, sorry about that. So, of course, the has_ prefix is indeed not logical for those cases. Is it, by the way, possible to distinguish between these cases or has that been discussed before as well? About the mixtures, yes, plus and multiplies, modulus and percent, right. It is not perfect. But I doubt if we therefore should invent another operator list again... But I admit, the can_call works about everywhere. However, I'm still finding can_call inconvenient, so "supports_" is my only suggestion left (actually that was the reason for me to react on that operator list). Then without operator to avoid the mixture. Thanks, Barend
On 22.04.2011 0:50, Barend Gehrels wrote:
On 21-4-2011 21:42, Stewart, Robert wrote:
Barend Gehrels wrote:
Next step: then "has_" is more convenient, because complying to existing practice. So: "has_operator_not". Perfect. Nope. As has been noted before, that implies ownership. A global operator doesn't belong to anything, so nothing "has" the operator.
Global operator is a part of class' interface.
You are right about ownership, I didn't read all the previous discussions, and didn't realize this when writing my mail, sorry about that. So, of course, the has_ prefix is indeed not logical for those cases. Is it, by the way, possible to distinguish between these cases or has that been discussed before as well?
??? :/ -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
Barend Gehrels wrote:
On 21-4-2011 21:42, Stewart, Robert wrote:
Barend Gehrels wrote:
Yet another round. Oh boy. I'll address the points you (re)raised, but I plan to stop after this. There's really not much more we can say, unless there's a sudden epiphany.
Sorry about the other round, but the supports_ is new (I checked) and maybe (didn't check) the relation of prefix/naming and why they are related.
That's why I wrote "raised."
As you felt sorry about not being part of the proto review, I think I may take this chance to add something to the type traits after-review, now that it is not yet written in stone and the discussion was revived anyway.
Quite right. I was just foreseeing another lengthy round of discussions as a consequence. I'm sorry I sounded so off-putting.
You are right about ownership, I didn't read all the previous discussions, and didn't realize this when writing my mail, sorry about that.
That's why I wrote "re-raised." _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Apr 21, 2011 at 10:29 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Joachim Faulhaber wrote:
FWIW, I agree with Joachim on this point. Since they both deal with builtin C++ operators (something in common), *it would be nice* if the part of the name referring to the operator (the common part) were the same (or a slightly varied). The semantic difference between the functor and the trait should, IMO, primarily be conveyed by the prefix or suffix or the particular variation on the "primary" operator name.
OK. Is "multiplication" a slight enough variation of "multiplies?" If not, what variation would you consider slight enough? Did you try the thought experiment I suggested in my last post?
Also, while we're on the topic of what *I* prefer: I still prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits.
What about all of the "is_" prefixed traits and other names in Boost.TypeTraits with prefixes like "add_" and "remove_," and those without a prefix? There's clear precedent for different prefixes for different purposes within the library. Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Thu, Apr 21, 2011 at 12:13 PM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Apr 21, 2011 at 10:29 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Joachim Faulhaber wrote:
FWIW, I agree with Joachim on this point. Since they both deal with builtin C++ operators (something in common), *it would be nice* if the part of the name referring to the operator (the common part) were the same (or a slightly varied). The semantic difference between the functor and the trait should, IMO, primarily be conveyed by the prefix or suffix or the particular variation on the "primary" operator name.
OK. Is "multiplication" a slight enough variation of "multiplies?"
[...] Yes... Did you try the thought experiment I suggested in my last post?
To some extent, as I already have a number of these traits lying around. Looks like, at the time I created these, I preferred the "is_xxxable" form for those traits (is_left_shiftable, is_pre_incrementable, etc.). I guess I was naming the trait after the operation rather than the operator. I think some for some operators, though, that formula is a bit awkward, e.g., with "+=". I would think to call that "has_plus_equal" or "has_operator_plus_equal" or "can_call_plus_equal" depending on what the understood prefix was. It seems we're going with the "name after the operator" route, here, which I have no problem with; it's easier to apply that formula universally to all operators, I think, and that's probably what Frederic discovered as well. Then a question is what to call each operator. I wouldn't initially think to call "+=" the "addition assignment" operator, but that's just me.
Also, while we're on the topic of what *I* prefer: I still
prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits.
What about all of the "is_" prefixed traits
Those, too!
and other names in Boost.TypeTraits with prefixes like "add_" and "remove_,"
Those aren't predicates...
and those without a prefix?
Such as...?
There's clear precedent for different prefixes for different purposes within the library. Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator.
Well, I don't think it's confusing to say that "A has a plus operator" is equivalent to "A + A is well-formed". Like I said, I understand that arguments against "has_xxx", but it's still more natural to me than "can_call_xxx". - Jeff
Hello everybody, It would be a shame if we all get angry from this discussion. I can propose the following to stop arguing: 1. each member of boost or boost-user can contribute (deadline April 29th 11:59pm CET) by giving his/her list of best names (just one list per member; only FULL lists are valid in the same order as described here: https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames). 2. we put it to a one week ballot so that each member of boost or boost-user can say which of all proposals he/she prefers (no vote before all contributions are received, deadline May 6th 11:59pm CET) 3. my vote counts for 2 and we choose the proposal that gets the highest score. Does that sounds right? During this time, I can continue improving the library according to the other comments from the review which are more consensual. Frédéric PS: I have put on this page all contributions about naming from the review: https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
AMDG On 04/21/2011 01:48 PM, Frédéric Bron wrote:
It would be a shame if we all get angry from this discussion. I can propose the following to stop arguing:
Personally, I think you should just say that the discussion is over and stick with what you have no matter what anyone says at this point. In Christ, Steven Watanabe
Hi Frédéric, list, I was off for some days over Easter and am now trying to catch up with the discussion that I have reignited a week ago. Thank you for your efforts to summarize and propose practical ways to a final solution. 2011/4/21 Frédéric Bron <frederic.bron@m4x.org>:
It would be a shame if we all get angry from this discussion. I can propose the following to stop arguing:
Naming discussions can get pretty nasty and tedious as some have expressed. On the other hand I think that this is also a discussion about naming consistency with a wider perspective (boost < generic libraries < language standard c++ < programming languages < ...). Since an operator sign like '+' is extremely universal and ubiquitous even beyond programming languages, its naming has a somewhat fundamental character. This being said, I think that the discussions about consistency aspects and the evolution of standards is worth the effort. If we were able to agree on some rules and rationals here, the discussion result could be a contribution for similar naming problems in the future.
1. each member of boost or boost-user can contribute (deadline April 29th 11:59pm CET) by giving his/her list of best names (just one list per member; only FULL lists are valid in the same order as described here: https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames).
2. we put it to a one week ballot so that each member of boost or boost-user can say which of all proposals he/she prefers (no vote before all contributions are received, deadline May 6th 11:59pm CET)
3. my vote counts for 2 and we choose the proposal that gets the highest score.
Does that sounds right? During this time, I can continue improving the library according to the other comments from the review which are more consensual.
Although I appreciate your efforts for a practical solution, I'd prefer the evolution of a consensus about rules and rationals around naming and naming consistency as a basis on which the names are chosen. After scanning across the postings of the last week, I have the impression, that there is at least some consensus about the value of cross library consistency considerations. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Hi Frédéric, list, 2011/4/21 Frédéric Bron <frederic.bron@m4x.org>:
Hello everybody,
It would be a shame if we all get angry from this discussion. I can propose the following to stop arguing:
1. each member of boost or boost-user can contribute (deadline April 29th 11:59pm CET) by giving his/her list of best names (just one list per member; only FULL lists are valid in the same order as described here: https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames).
Here is my proposal for the operator trait names. Consistent with my preference on cross library and c++ standard naming consistency these are the collections of names that are (measurably) most consistent with the names used for operators in the standard (header <functional>), Boost.Proto and other Boost libraries. They are the name component called "Most Unifying Proposal (MUP)" from Wiki-page https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators prefixed by "has_". I chose "has_" for the same reason: Consistency within boost, because the type traits library uses has_ in similar instances. The argument, that this is an imprecise naming because for free standing operators ownership can not be determined is unimportant, because we may conceive the complete type signature as the type that "owns" the operator: A x B -> B has_plus Both name components, prefix "has_" and the most unifying operator component are simple, commonly used, known from the language standard and boost libraries, so they will be *expected* by users and most easily recognized and remembered which leads to optimal usability. To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 28.04.2011 15:57, Joachim Faulhaber wrote:
Here is my proposal for the operator trait names.
Consistent with my preference on cross library and c++ standard naming consistency these are the collections of names that are (measurably) most consistent with the names used for operators in the standard (header<functional>), Boost.Proto and other Boost libraries. [...]
To save you some time, I have inserted my proposal as *column D* into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
+1 nearly optimal for me -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On 28 April 2011 07:14, Max Sobolev <macsmr@ya.ru> wrote:
On 28.04.2011 15:57, Joachim Faulhaber wrote:
Here is my proposal for the operator trait names.
Consistent with my preference on cross library and c++ standard naming consistency these are the collections of names that are (measurably) most consistent with the names used for operators in the standard (header<functional>), Boost.Proto and other Boost libraries. [...]
To save you some time, I have inserted my proposal as *column D* into the
Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
+1
nearly optimal for me
+0.5. As a frequent user of Boost.TypeTraits, the names suggested by Joachim Faulhaber would be the ones I would look for. * I would prefer to see the word 'bitwise' instead of 'bit' however. * To be consistent with at least proto, has_left_shift should be has_shift_left (in all permutations of left/right + assign) - Christian
2011/4/28 Christian Holmquist <c.holmquist@gmail.com>:
On 28 April 2011 07:14, Max Sobolev <macsmr@ya.ru> wrote:
On 28.04.2011 15:57, Joachim Faulhaber wrote:
Here is my proposal for the operator trait names.
Consistent with my preference on cross library and c++ standard naming consistency these are the collections of names that are (measurably) most consistent with the names used for operators in the standard (header<functional>), Boost.Proto and other Boost libraries. [...]
To save you some time, I have inserted my proposal as *column D* into the
Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
+1
nearly optimal for me
+0.5. As a frequent user of Boost.TypeTraits, the names suggested by Joachim Faulhaber would be the ones I would look for.
* I would prefer to see the word 'bitwise' instead of 'bit' however.
I agree. "bitwise" would be nicer and the naming consistency with proto would be higher. Yet my #1 priority is naming consistency across libraries. In other words I am aiming for standardisation. Accordingly I have rules: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators And of course, if there *is* a true standards, if I like it or not, this existing standard hat priority #1 for the name choice. Names bit_and, bit_or, bit_xor related to bitweise operators are not in the current standard, but in the new standard, that is almost completed, AFAIK. So we have three options here: (1) Trying to change the new stadard in this specific point before its too late. (2) Accepting names bit_xxx as the standard names for bitwise operators. (3) Abandone the consistency goal. The numbers indicate my prefereces here.
* To be consistent with at least proto, has_left_shift should be has_shift_left (in all permutations of left/right + assign)
There is no naming from the standard for shift operators. Boost.Proto and Boost.Operator disagree. I chose left_shift right_shift because they can be "conceptified" by appending suffix "able". (Rule 4.b from https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators) left_shiftable right_shiftable which are the names used by Boost.Operators Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
I chose "has_" for the same reason: Consistency within boost, because the type traits library uses has_ in similar instances. The argument, that this is an imprecise naming because for free standing operators ownership can not be determined is unimportant because we may conceive the complete type signature as the type that "owns" the operator:
A x B -> B has_plus
Thinking of A and B as a universe that may or may not include a particular operator, whether through a member function or not, is a reasonable way to interpret things. On that basis, I now find "has_" acceptable. That's one hurdle behind us (assuming Frédéric is likewise convinced)! _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/4/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
I chose "has_" for the same reason: Consistency within boost, because the type traits library uses has_ in similar instances. The argument, that this is an imprecise naming because for free standing operators ownership can not be determined is unimportant because we may conceive the complete type signature as the type that "owns" the operator:
A x B -> B has_plus
Thinking of A and B as a universe that may or may not include a particular operator, whether through a member function or not, is a reasonable way to interpret things. On that basis, I now find "has_" acceptable.
the beauty of generic designs based on concepts is, that it gently dissolves object oriented views of membership anyway. So we can think of a triple of types (A1, A2, R) that "has" an implementation for an operator @ which means that it is applicable, can be called on or supports those type arguments. has_ reads well under this "modern" interpretation. We can prefer it for consistency sake concerning other uses of has_ in Boost.TypeTraits and because
it has simplicity and brevity; as Jeff wrote
Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 04/28/2011 07:57 PM, Joachim Faulhaber wrote:
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
Cheers, Joachim
+1 for column D Cheers, Joseph
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
On 04/28/2011 07:57 PM, Joachim Faulhaber wrote:
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
Cheers, Joachim
+1 for column D
Cheers,
Joseph
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options ie column A has the best operator names. Given the 4 options, I would pick A for this reason alone. - supports_ is better than can_ or can_call. - has_operator_ is somehow better than has_ (makes the wording work better) - supports_ might be better than has_operator_. (Being a "mathy") I understand Joachim's reasoning for "has", but I think "supports" flows well and is also quite accurate in the meaning we are trying to express. So I'd vote for supports_A, if that column existed, else A. supports_A is as short as D, flows like A and is accurate. I'm not at all concerned that "supports" hasn't been used in meta-templates before - I think that is possibly a plus. Obviously just my opinion, Tony
2011/4/29 Gottlob Frege <gottlobfrege@gmail.com>:
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
On 04/28/2011 07:57 PM, Joachim Faulhaber wrote:
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
Cheers, Joachim
+1 for column D
Cheers,
Joseph
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options
interesting ... ... could you give us a deeper insight in the superiority of this particular name? Joachim
2011/4/29 Joachim Faulhaber <afojgo@googlemail.com>:
2011/4/29 Gottlob Frege <gottlobfrege@gmail.com>:
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
On 04/28/2011 07:57 PM, Joachim Faulhaber wrote:
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
Cheers, Joachim
+1 for column D
Cheers,
Joseph
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options
interesting ... ... could you give us a deeper insight in the superiority of this particular name?
Hi Tony, I'm still wondering about your preference for "plus_equal". My own considerations here are these: I remember a lecture by my professor in compiler construction two decades ago, who raged against the use of operator = in c. I'd be stupid to assign the assignment semantics to an operator = that is used in maths with a semantics of "is equal to" for centuries. He preferred to use := for assignment and = for equality. I agreed with him then and I still agree today. Alas ranting and raving of professors didn't influence c: Operator = is associated to assignment and operator == is associated to equality. And because we were drilled differently in maths, one of the most frequent error amongst c-novices was buried in code like if(x=y).. that led to seemingly bizarre behavior, both on the program's and on the programmer's part. Once attached to the = sign, the assignment semantics is used consistently in c and later c++ x += y for x = x + y assign after plus. In contrast to x +:= y for x := x + y in the family of algol languages. Similar for other operations o x o= y for x = x o y This perfectly justifies plus_assign for += if + is named plus and = is named assign at least I think so ... Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Sat, Apr 30, 2011 at 10:49 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2011/4/29 Joachim Faulhaber <afojgo@googlemail.com>:
2011/4/29 Gottlob Frege <gottlobfrege@gmail.com>:
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options
interesting ... ... could you give us a deeper insight in the superiority of this particular name?
Mostly I just wanted to voice my "vote". It is just my opinion. But when I stop and think about my underlying reasoning, I think it basically comes down to this: In over 20 years of programming, across countries and continents, I've never heard anyone call += "plus-assign". I've always heard it called plus-equals. I can get philosophical (and often do) and/or pedantic (again often do), I thus I can understand reasoning about ambiguities, consistencies, etc. But I think common language trumps all that, if it is common enough. So maybe plus-assign is used elsewhere and I just haven't heard it, but I know I hear plus-equals regularly. Also, maybe it is important for standard or near-standard libraries to strive for a higher, well, standard, and thus maybe it is our job to use the "correct" terms. But I fear it just comes off too ivory tower, instead of practical and pragmatic, in this case. I think about the general problem of naming (of variables in code, etc) a lot (including Bertrand Russell's essays on "the King of Spain", etc), and I always think back to when I was a kid and we added a room onto the back of our house (taking us from 800sq ft to 1000, pretty small for a 3-child family, in Canada at least). Anyhow, we always (and still) referred to the room as "the back room". Not "the room at the back of the house" nor the den or family room or back porch or... (because it wasn't exactly any of those things). "the back room" was the shortest but still accurate / unambiguous / descriptive name. This is how language (at least English, it seems) tends to work - we instinctively find short names that work (or keep looking until we do - which is why a lean towards "supports" or "can-call" or even "has", and which is why this whole discussion exists, I think). Now, interestingly, I notice that in everyday talk about = and ==, there can be ambiguity, which is why, when reading code aloud, everyone I've ever heard, says "x equals 10" when reading "x = 10", yet when talking about overriding it, everyone calls it the "assignment operator" since the "equals operator" might be ambiguous. Which maybe is an argument on behalf of "assigns". I notice that "=" is not on the list at all - would it be called "supports_equals" in my scheme? No, I would actually call it "supports_assignment". Yet I'd still go with "supports_plus_equals" for +=. Is that inconsistent? Maybe, but it is (in my world) consistent with common usage. Common usage has decided to favour short words unless there is ambiguity. And thus the scheme would be consistent (plus is plus is plus) except where ambiguity dictates otherwise (equals becomes assignment only when ambiguity forces it to). Lastly, I often wonder if it comes down to brain chemistry/behaviour/etc. Maybe other people are different, but when I'm typing, I often hear the words in my head as I type it (of course now that I'm conscious of it, typing becomes more difficult!). So I find overly long function names or variable names are actually a hindrance. Not just to typing, but to understanding. If I have to think about "the room at the back of the house" instead of "the back room" it actually affects my thinking. As a mathematician, I will just replace a long term with X or an abbreviation (it seems we all do). This isn't just for shorter typing - for me at least. It is for more concise thinking - if a phrase can be turned into a single word, it can be thought of as a thing of its own (a higher level object) and no longer just a conglomeration of parts. To me "plus-assign" or "plus-assignment" is a conglomeration of parts. "plus-equals" has become a thing of its own, via years of usage. I don't think of it as "add then assign back to x" I think of it as "increase" or something like that. Maybe plus-assign would eventually become the same thing, but we haven't called it that yet as programmers, and unless we start doing so day to day (unlikely, given the "rules" of language as I see them), we will still refer to it as plus-equals, except for the special case of this boost library. Or maybe it is just my opinion and gut reaction. Just one voice, one "vote", hoping that it counts for something. But since you asked (thanks for your interest - I do believe you are looking for reasoning and being open to ideas, which is great), when I stop and think about it, I *think* that's my reasoning behind my gut instinct. Tony
On Tue, May 3, 2011 at 2:11 AM, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Sat, Apr 30, 2011 at 10:49 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2011/4/29 Joachim Faulhaber <afojgo@googlemail.com>:
2011/4/29 Gottlob Frege <gottlobfrege@gmail.com>:
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options
interesting ... ... could you give us a deeper insight in the superiority of this particular name?
Mostly I just wanted to voice my "vote". It is just my opinion.
But when I stop and think about my underlying reasoning, I think it basically comes down to this:
<snip> blah blah blah... Also I wanted to mention, that as a mathematician, when I do x = 10 ... in a math proof, is that assignment or equality? To me it is a statement of equality. It is more like the early days of BASIC and "let": LET X = 10 Or in math proofs, "given that x = 10, ...." which is really more like "modus ponens" of logic, "if P then Q...". A statement more than an assignment. But maybe that's just me. I wonder what prolog programmers think about "=". Tony
2011/5/3 Gottlob Frege <gottlobfrege@gmail.com>:
On Sat, Apr 30, 2011 at 10:49 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2011/4/29 Joachim Faulhaber <afojgo@googlemail.com>:
2011/4/29 Gottlob Frege <gottlobfrege@gmail.com>:
On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu@yahoo.com> wrote:
I think (in order of strength of my opinion) - naming is very important - plus-equal (et al) is better than any of the other options
interesting ... ... could you give us a deeper insight in the superiority of this particular name?
I enjoyed reading your answer. I also think naming is important and specifically in this case because operators are not only at the core of c++ but completely integrated in many fields of language specifically those that use maths in some way. Your main point is the spontaneous and commonly observed "spoken" version of those operator signs. And it took me a little by surprise that this aspect has not been risen before (or has it? I'm loosing overview). I immediately remembered spoken c and c++ during my 20+ years with c/c++ and I notice that I can not compare my auditive experience to yours because my "spoken operatorish" is in German ;-) which is also pretty bizarre, because c++ spoken by Germans it is a wild mixture of German and English words and typically operators are spoken in German by German c++ narrators. This happens in a way as if, in the face of reading c++ operators the human brain degenerated to a lexical scanner that scans the tokens and translates them (using mother tongue) in those words sequentially that it has most frequently been drilled to use for the respective digits. [..]
In over 20 years of programming, across countries and continents, I've never heard anyone call += "plus-assign". I've always heard it called plus-equals.
and it comes, in German tongue, to a similar result as the English speaking brain, using English words: DE: plus-gleich UK: plus-equals
I can get philosophical (and often do) and/or pedantic (again often do), I thus I can understand reasoning about ambiguities, consistencies, etc. But I think common language trumps all that, if it is common enough. So maybe plus-assign is used elsewhere and I just haven't heard it, but I know I hear plus-equals regularly. Also, maybe it is important for standard or near-standard libraries to strive for a higher, well, standard, and thus maybe it is our job to use the "correct" terms.
which may not exist in the domain of naming
But I fear it just comes off too ivory tower, instead of practical and pragmatic, in this case.
agreed
I think about the general problem of naming (of variables in code, etc) a lot (including Bertrand Russell's essays on "the King of Spain", etc),
sounds interesting, is the essay accessible via the web?
and I always think back to when I was a kid and we added a room onto the back of our house (taking us from 800sq ft to 1000, pretty small for a 3-child family, in Canada at least). Anyhow, we always (and still) referred to the room as "the back room". Not "the room at the back of the house" nor the den or family room or back porch or... (because it wasn't exactly any of those things). "the back room" was the shortest but still accurate / unambiguous / descriptive name.
This is how language (at least English, it seems) tends to work - we instinctively find short names that work (or keep looking until we do - which is why a lean towards "supports" or "can-call" or even "has", and which is why this whole discussion exists, I think).
Nice, I like short names as well. BTW, column D not only has the most unifying but also the shortest names.
Now, interestingly, I notice that in everyday talk about = and ==, there can be ambiguity, which is why, when reading code aloud, everyone I've ever heard, says "x equals 10" when reading "x = 10", yet when talking about overriding it, everyone calls it the "assignment operator" since the "equals operator" might be ambiguous. Which maybe is an argument on behalf of "assigns". I notice that "=" is not on the list at all - would it be called "supports_equals" in my scheme? No, I would actually call it "supports_assignment". Yet I'd still go with "supports_plus_equals" for +=. Is that inconsistent? Maybe, but it is (in my world) consistent with common usage. Common usage has decided to favour short words unless there is ambiguity. And thus the scheme would be consistent (plus is plus is plus) except where ambiguity dictates otherwise (equals becomes assignment only when ambiguity forces it to).
Lastly, I often wonder if it comes down to brain chemistry/behaviour/etc. Maybe other people are different, but when I'm typing, I often hear the words in my head as I type it (of course now that I'm conscious of it, typing becomes more difficult!). So I find overly long function names or variable names are actually a hindrance. Not just to typing, but to understanding. If I have to think about "the room at the back of the house" instead of "the back room" it actually affects my thinking. As a mathematician, I will just replace a long term with X or an abbreviation (it seems we all do). This isn't just for shorter typing - for me at least. It is for more concise thinking - if a phrase can be turned into a single word, it can be thought of as a thing of its own (a higher level object) and no longer just a conglomeration of parts.
[..] So, a lot of your very interesting point of view relates to "spoken" language and "spoken" c++ in particular (also inner speaking while typing). Let me repeat this: ... I can not compare my auditive experience to yours because my "spoken operatorish" is in German ;-) which is also pretty bizarre, because c++ spoken by Germans it is a wild mixture of German and English words and typically operators are spoken in German by German c++ narrators. This happens in a way as if, in the face of reading c++ operators the human brain degenerated to a lexical scanner that scans the tokens and translates them (using mother tongue) in those words sequentially that it has most frequently been drilled to use for the respective digits. As stated on the outset, this operatorish narrator produces seemingly natural results e.g. UK plus-equals DE plus-gleich for += that seems to be "paralell natural" for the two languages, but I have heard it producing cumbersome names like DE Prozent-gleich for %= or DE Doppelpunkt-gleich for := (not c of course) because it seems not to "think" very much ;) Since no one ever says "modulus" for % in Germany, but everyone says "Prozent". Everyone would say DE Prozent-gleich for %= which would be 'percent-equals' in English. I see three Problems with your Spokenness Paradigm (1) Spokenness of operators leads to non systematic sometimes awkward conglomeration of parts. (2) There are loads of differences of spoken operators in different languages. (3) Spokenness as a guideline is again not consistently used. Specifically not used consistently within column A We would, for example, need to name pre_increment as pre_plus_plus
Or maybe it is just my opinion and gut reaction. Just one voice,
I can get philosophical (and often do)
The spokenness point of view is a new point of view, well explained. There are other points of view that have more or less been well explained in the quest for correct naming. What let's us be certain, that a point of view A is more valid that a point of view B. Arguments although very interesting seem to be diverse and "organic", dependent on setting some context (spokenness in this case) sometimes fuzzy and ambiguous as language itself. This "correctness" of naming. Can it be measured for a point of view A? Can it be deduced by pure logic? If the answer is NO and all points of view are equally valid, including those chosen for naming in the past, I propose to accept the prevailing naming as valid and opt for the goal of "standard and cross library consistency of naming" (did I mention this already?). In this case the quality of a new naming proposal is even measurable! Moreover the rationals that govern the choice of names is very simple. See https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
one "vote", hoping that it counts for something.
provided it doesn't drown in flood of words that is called boost mailing list. (I've heard this has happened, watch out!)
But since you asked (thanks for your interest - I do believe you are looking for reasoning and being open to ideas, which is great), when I stop and think about it, I *think* that's my reasoning behind my gut instinct.
Thanks for your thoughts . . . Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Wed, May 4, 2011 at 10:27 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
Your main point is the spontaneous and commonly observed "spoken" version of those operator signs. And it took me a little by surprise that this aspect has not been risen before (or has it? I'm loosing overview).
"Spoken-ness" is one point. Common usage is the other. Related points, but there are differences...
I think about the general problem of naming (of variables in code, etc) a lot (including Bertrand Russell's essays on "the King of Spain", etc),
sounds interesting, is the essay accessible via the web?
I had to do some googling: I'm pretty sure it was an essay called "On Denoting" (http://en.wikipedia.org/wiki/On_Denoting). Although I think when I read it, it was in a book, one chapter called "the definite article" and another called "the indefinite article", and I recall thinking it was pretty funny that someone could write so much about the word 'a' and so much about the word 'the' (and that I could find it so interesting). See also http://en.wikipedia.org/wiki/Theory_of_descriptions, http://evans-experientialism.freewebspace.com/frege_russel_is.htm, etc.
So, a lot of your very interesting point of view relates to "spoken" language and "spoken" c++ in particular (also inner speaking while typing).
... I can not compare my auditive experience to yours because my "spoken operatorish" is in German ;-) which is also pretty bizarre, because c++ spoken by Germans it is a wild mixture of German and English words and typically operators are spoken in German by German c++ narrators. This happens in a way as if, in the face of reading c++ operators the human brain degenerated to a lexical scanner that scans the tokens and translates them (using mother tongue) in those words sequentially that it has most frequently been drilled to use for the respective digits.
As stated on the outset, this operatorish narrator produces seemingly natural results e.g. UK plus-equals DE plus-gleich for += that seems to be "paralell natural" for the two languages,
but I have heard it producing cumbersome names like DE Prozent-gleich for %= or DE Doppelpunkt-gleich for := (not c of course)
because it seems not to "think" very much ;) Since no one ever says "modulus" for % in Germany, but everyone says "Prozent". Everyone would say DE Prozent-gleich for %= which would be 'percent-equals' in English.
I tend to call it - or at least speak it - percent-equals as well, although I might not want to use that as the name in this library - it could be confused with an operation that actually calculated percentages. Although, I guess since operators can be overloaded, in some sense the symbolic name "percent" is more accurate than how it operates on integers. x % y doesn't mean modulus for arbitrary classes. Maybe it does calculate percentages.
I see three Problems with your Spokenness Paradigm
(1) Spokenness of operators leads to non systematic sometimes awkward conglomeration of parts. (2) There are loads of differences of spoken operators in different languages. (3) Spokenness as a guideline is again not consistently used. Specifically not used consistently within column A We would, for example, need to name pre_increment as pre_plus_plus
Ah, but no one calls it pre-plus-plus. This is where spokenness and common usage diverge. We call it pre and post increment when we need to differentiate. If it was understood in context, I would explain to someone that "a list iterator overrides operator plus-plus to move to the next node in the list". But if I needed to give someone a task, I would probably be more precise - "you need to use pre-increment here, as it tends to be more efficient...". Etc. This, I think, is an important point. Possibly more important than "spokenness". I think we, for the most part, have already decided the names of these operators. By "we" I mean programmers at large. I mean common usage. Now maybe it is hard to measure common usage (maybe tallying google search results would help), but I think common usage has already decided it. (And yes, google says "plus equals" is 10x more common than alternatives) So it has already been determined via the genetic algorithms of programmers using terms and having some catching on and others not.
Moreover the rationals that govern the choice of names is very simple. See https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
That is a useful page. Obviously anything that aligns with the standard (current or C++0x) is pretty compelling. That leaves, I think: +=, -=,... plus_equal vs plus_assign <<... left_shift vs shift_left ++... pre_increment vs ... - unary_minus vs negate (std uses negate but std doesn't have anything for unary_plus) ~ and * are not in the standard, but I see no conflicting proposals there. And I'm NOT going to argue that symbols have no meaning (since the can be overloaded) such that ~ should be called 'tilde' and * should be called 'asterisk'. I'm not going to argue that. I'm fine with compliment and dereference. - is in the standard as 'negate', but I find the 'unary_plus' matches 'unary_minus' argument compelling. Of course, what would be even better would be to find a name for unary + that matches negate - ie 'posit' or 'positate' or something :-) Probably not going to happen. So I could live with either, or even both - ie include unary_minus and negate. But I personally prefer unary_minus. Not sure if I have a good argument for why. ++ pre_increment, prefix_increment, pre_inc,... is there any argument here? I suspect not. pre_increment works, I think. << left_shift vs shift_left. I find 'shift_left' to be the verb, and 'left_shift' to be the noun - ie the name of the operator. So I agree with left_shift. += I left this for last, hoping to have a good argument or good solution... I just don't like plus_assign. I see the idea of separating comparison from assignment. And the standard already set the standard for comparison, so I don't suggest changing it to equality or equivalence (nor do I suggest getting into the discussions about the possible different meanings of equality, equivalence, indentity, etc). The best I can do is suggest "equals" vs "equal" - ie note that the comparison operators use "equal" but multiplies, divides, etc, add an 's', and basically, I would say "plus-equals" not "plus-equal". Actually, I read "x += y" as "plus-equal" but I read "operator+=" as "operator plus-equals". I don't feel that is a great argument. So let me go back to common usage. Let's assume all the others (<<, ++, ~, *, etc) are decided, and only the += problem is left. If you gave the table to N programmers, with everything filled in except the += group, and asked them to fill in the blanks... no wait. Better yet, show them the rest of the table, then let them go write some code that requires type_traits::supports_+=, what will they automatically to type? I suspect plus_equals, or plus_equal or maybe even a plus_assignment, but 0 will assume that is is called supports_plus_assign or (has_plus_assign, etc). In this case I think common usage is more important than a slight ambiguity with equality. (You could even argue that plus_equals is *consistent* with equal_to, since they both use the same term for the same(ish) symbol :-) And/or feel free to argue that the standard should have used a term like "equality" or "omparable" or something. Basically the standard used common usage, I think, and to be consistent with that, we should too. (You could also argue that the standard's usage of common usage is an example of how it can later cause problems...) Lastly, I find these type_traits useful, so I will use whatever is decided, even if it is in German. But I appreciate the effort of finding good names. Actually, the last thing I wanted to mention (again) is that I really like "supports" over "has" or "can_call" or has_operator or etc. Tony
2011/5/8 Gottlob Frege <gottlobfrege@gmail.com>:
On Wed, May 4, 2011 at 10:27 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
... I can not compare my auditive experience to yours because my "spoken operatorish" is in German ;-) which is also pretty bizarre, because c++ spoken by Germans it is a wild mixture of German and English words and typically operators are spoken in German by German c++ narrators. This happens in a way as if, in the face of reading c++ operators the human brain degenerated to a lexical scanner that scans the tokens and translates them (using mother tongue) in those words sequentially that it has most frequently been drilled to use for the respective digits.
As stated on the outset, this operatorish narrator produces seemingly natural results e.g. UK plus-equals DE plus-gleich for += that seems to be "paralell natural" for the two languages,
but I have heard it producing cumbersome names like DE Prozent-gleich for %= or DE Doppelpunkt-gleich for := (not c of course)
because it seems not to "think" very much ;) Since no one ever says "modulus" for % in Germany, but everyone says "Prozent". Everyone would say DE Prozent-gleich for %= which would be 'percent-equals' in English.
I tend to call it - or at least speak it - percent-equals as well, although I might not want to use that as the name in this library - it could be confused with an operation that actually calculated percentages. Although, I guess since operators can be overloaded, in some sense the symbolic name "percent" is more accurate than how it operates on integers. x % y doesn't mean modulus for arbitrary classes. Maybe it does calculate percentages.
operator %= is a good example that "spokenness" and "common calledness" can be rooted in unsystematic decisions and historic choices that have not been done from an intention of consistent, intuitive and semantically sound naming for operators. Someone decided to attach the modulus operation to % and "assign-modulus" to % and %= (1) We spontaneously speak percent-equal (2) We might even call it an operator percent-equal, when talking about it but we (3) dislike percent_equal or percent_assign as the operator's name within a boost library, ... why? because it is obviously inconsistent with (a) the default semantics for operator %= in c++ (b) the existing standard name for %-wrapper-functor modulus As stated before, "spokenness" seems to produce clumsy results, because it tends to combine names for lexical tokens without any reflexion and thinking. In contrast, names from boost libraries and even more so from the standard need to pass a process of thinking, sometimes discussion (like this one) and an informed decision finally.
I see three Problems with your Spokenness Paradigm
(1) Spokenness of operators leads to non systematic sometimes awkward conglomeration of parts. (2) There are loads of differences of spoken operators in different languages. (3) Spokenness as a guideline is again not consistently used. Specifically not used consistently within column A We would, for example, need to name pre_increment as pre_plus_plus
Ah, but no one calls it pre-plus-plus.
In my experience it is spoken: plus-plus called: (1) plus-plus-operator (omitting the pre post attribute) and also (2) (pre/post)-increment-operator
This is where spokenness and common usage diverge. We call it pre and post increment when we need to differentiate. If it was understood in context, I would explain to someone that "a list iterator overrides operator plus-plus to move to the next node in the list". But if I needed to give someone a task, I would probably be more precise - "you need to use pre-increment here, as it tends to be more efficient...". Etc.
This, I think, is an important point. Possibly more important than "spokenness". I think we, for the most part, have already decided the names of these operators. By "we" I mean programmers at large. I mean common usage. Now maybe it is hard to measure common usage (maybe tallying google search results would help), but I think common usage has already decided it. (And yes, google says "plus equals" is 10x more common than alternatives)
Googled today: 85,400 "plus equals" 8,110 "plus assign" 355,000 "add equal" 42,800,000 "add it" 589,000 "add it up" 55,100 "percent equal" 3,670 "modulus equals"
So it has already been determined ? ;-) via google? Ok, everything is determined today by google, of course :)
BTW add-it-up is kind of nice ... (but it's not a MUP so I won't propose it)
via the genetic algorithms of programmers using terms and having some catching on and others not.
[Ok, ... forgive me my irony ...] I get your point and I think it is a good one. If I understand you right you say. (1) There is a common usage, that emerged through genetic (or memetic) evolution. (2) This common usage is the *best choice* for the operator names. I continue this reasoning ... ... because from the perspective of (1) usablility (2) memorability (3) ease of perception (4) least astonishment it is the best choice to use those names that *are* THE common sense. What I like about this reasoning is that is proposes to let the choice be made in acknowledgement of a larger view or context. It is similar to what I am proposing. Only the contexts are different. Both proposals are claiming that the choice has already been made. (1) Tony: The choice is taken by spokenness and common usage. (2) Joachim: The choice is taken by the standard and prevailing (boost) libraries. End of part I. (To be continued ;) Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Tue, May 10, 2011 at 3:12 PM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
(1) Tony: The choice is taken by spokenness and common usage. (2) Joachim: The choice is taken by the standard and prevailing (boost) libraries.
To be clear, I tend to agree that the standard comes first (except that nasty 'negate' problem), which leaves "memetics" vs prevailing (non-standard) libraries. And that's where I start weighing back and forth, and maybe decide on a case-by-case basis. Tony
2011/5/12 Gottlob Frege <gottlobfrege@gmail.com>:
On Tue, May 10, 2011 at 3:12 PM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
(1) Tony: The choice is taken by spokenness and common usage. (2) Joachim: The choice is taken by the standard and prevailing (boost) libraries.
To be clear, I tend to agree that the standard comes first (except that nasty 'negate' problem),
Why is it nasty? Standard *and* boost libraries agree on 'negate' -- perfect! nobody desires 'unary_multiplies' in order to be consistent with unary_plus unary_minus unary_... Everybody is happy with 'dereference' that follows boost::proto in this case. Nobody demands a 'binary_plus' in order to be consistent with arity-prefixing 'Xary_op'. All those considerations may come along the way and the inventor may be very proud of some of those rationals. But they can be pretty "local" and "personal" maybe "egoic" sometimes. If this is the case, we can just choose the Most Unifying Names, for the clear goal to converge to standard and inter library consistency. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Part II: On Memetic Evolution 2011/5/10 Joachim Faulhaber <afojgo@googlemail.com>:
2011/5/8 Gottlob Frege <gottlobfrege@gmail.com>:
This, I think, is an important point. Possibly more important than "spokenness". I think we, for the most part, have already decided the names of these operators. By "we" I mean programmers at large. I mean common usage. Now maybe it is hard to measure common usage
I get your point and I think it is a good one. If I understand you right you say. (1) There is a common usage, that emerged through genetic (or memetic) evolution. (2) This common usage is the *best choice* for the operator names.
I continue this reasoning ... ... because from the perspective of (1) usablility (2) memorability (3) ease of perception (4) least astonishment it is the best choice to use those names that *are* THE common sense.
What I like about this reasoning is that is proposes to let the choice be made in acknowledgement of a larger view or context. It is similar to what I am proposing. Only the contexts are different. Both proposals are claiming that the choice has already been made.
(1) Tony: The choice is taken by spokenness and common usage. (2) Joachim: The choice is taken by the standard and prevailing (boost) libraries.
End of part I. (To be continued ;)
What is the difference between those points of view? Why are there differences between common usage and the results of standardization processes or global discussion in the first place? I think one interesting aspect about those two contexts and their differences is memetic evolution. There is an interesting book by the American psychologist Mihaly Csikszentmihalyi: The Evolving Self. See http://www.scottlondon.com/reviews/csik.html for a summary. I've read the book 15 years ago but I remember its very interesting theory on memes and memetic evolution. Memes are patterns of information, that emerge, mutate, replicate and evolve, similar to genes. In contrast to genes that depend on biological metabolism to replicate, memes use human consciousness or mental energy as habitat. Like an earworm that you catch because you heard someone singing and then you pass it on by singing the melody yourself. Earworms can be nasty sometimes. We may even have earworms of songs we do not really like. One of the messages of Csikszentmihalyi's book is, that memes inhabit our minds and many if not most of them do this beyond our conscious perception, without us being aware of them. They use up the most precious resources of human life: Mental energy and time. Csikszentmihalyi proposal is to look at the memes with awareness, reflecting on them and to start to decide about the memes we want to invest mental energy into (e.g. boost discussions) and the ones we won't (e.g. watching, talking about, thinking about a daily soap). Looking from the theory of memes, I'd say that spokenness and common usage of an operator += is a meme, that just evolved without any reflexion and consciousness out of the sudden necessity to read, speak and spontaneously name this funny lexeme '+='. Here we automatically combine two very universal memes: + sign and =sign, not thinking and reflecting about their adequacy and semantical correctness in the context of the c++ operator usage. This automatism is even more obvious with %= where "percent-equal" is so obviously contradicting the default semantics of this operator in c++. This might set your (Tony's) statement in a new light
I think we, for the most part, have already decided the names of these operators. By "we" I mean programmers at large.
Maybe *no one* has decided this concsiously after thorough consideration and discussion. Maybe a common usage like "percent-equal" for %= is just a product of automatic memetic processing, a memetic artifact . . . End of part II. (To be continued ;) Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Apr 21, 2011 at 12:13 PM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Jeffrey Lee Hellrung, Jr. wrote:
Also, while we're on the topic of what *I* prefer: I still prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits.
What about all of the "is_" prefixed traits
Those, too!
OK, so there are names in TypeTraits with both "has_" and "is_," so "has_" isn't the only prefix you should associate with the library. That was my point.
and other names in Boost.TypeTraits with prefixes like "add_" and "remove_,"
Those aren't predicates...
and those without a prefix?
Such as...?
I was thinking of "existing use in Boost.TypeTraits" while forgetting "implicit association to the names of traits predicates" in what you wrote.
There's clear precedent for different prefixes for different purposes within the library. Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator.
Well, I don't think it's confusing to say that "A has a plus operator" is equivalent to "A + A is well-formed". Like I said, I understand that arguments against "has_xxx", but it's still more natural to me than "can_call_xxx".
That's a valid point in that case. However, don't forget that it can also be A + B, in which case the operator bridges two types and is, therefore, part of neither interface or else somehow part of both. "has_" doesn't work as nicely then. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 21.04.2011 23:13, Stewart, Robert wrote:
Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator.
Class must have only intrinsic member functions, without which it doesn't working. Extended part of interface defines out of class body (perhaps in a separate module) in the same namespace, in terms of intrinsic member functions. This decrease coupling of code. (This C++ Software Construction approach was clearly described and proposed in Czarnecki/Eisenecker "Generative Programming". - S.Meyers agree; H.Sutter agree; D.Abrahams :) agree.) Consider Barton/Nackman trick as it presents in Boost.Operators library: boost::equality_comparable<T> require from T operator < is being defined (as member or free operator function, doesn't matter). Operators >, <=,
= are generated automatically as free operator functions due to inheritance.
But there is no difference between 4 operators <, >, <= and >= from point of view its meaning and "status": they all makes interface of class T. Operators >, <=, >= aren't second class citizens, even if operator < is define as member operator function. -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On 21.04.2011 23:13, Stewart, Robert wrote:
Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator.
Maybe, but there's no way to tell the difference between an operator defined as a member function, and one defined at namespace scope. Plus we already have "has_new_operator". John.
John Maddock wrote:
On 21.04.2011 23:13, Stewart, Robert wrote:
Remember that "has_" implies ownership or inherent characteristic which doesn't apply to a namespace scope operator.
Maybe, but there's no way to tell the difference between an operator defined as a member function, and one defined at namespace scope.
Granted, but there can be operators mixing UDTs, so it belongs to neither. "has_" just connotes the idea poorly to me.
Plus we already have "has_new_operator".
That should have been "operator new," of course, because the new operator is a different animal. However, operator new must be a member function, so "has_" is the appropriate prefix. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
I'm still waiting for that large group to weigh in. We've had some others participate previously, but I suggest letting this ride and get more opinions on the new list. OTOH, if no others weigh in, then Frédéric's choices win, since he's the author (unless John Maddock chooses to intervene).
Nope. I have to be honest, I prefer the original names, but that's just my personal taste ;-) Ultimately someone has to stand up and make a decision based on what were rather conflicting suggestions during the review. And that's what Frederic has done. So unless the names are so completely screwy that no-one in their right minds would be happy with them (and they're clearly not that), then I'll support whatever decision is made. Regards, John.
- Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic.
I have been able to treat the references better. I can now use the real type provided to the trait without removing the reference qualifier. The counterpart is that, for example, can_call_addition_assignment<int>::value is false which may seem strange but: - can_call_addition_assignment<int&>::value is true - can_call_addition_assignment<int&, int>::value is true Same for can_call_pre_increment<int> which is false but can_call_pre_increment<int&> is true. This is of course logical and if nobody disagrees, this is what I will apply (the documentation will explain this in details as requested). Frédéric
participants (18)
-
Barend Gehrels -
Christian Holmquist -
Daniel Herring -
Dave Abrahams -
Edward Diener -
Frédéric Bron -
Gottlob Frege -
Jeffrey Lee Hellrung, Jr. -
Joachim Faulhaber -
Joel Falcou -
John Maddock -
Joseph Wu -
Matt Calabrese -
Max Sobolev -
Simonson, Lucanus J -
Steven Watanabe -
Stewart, Robert -
Vicente BOTET