On Sunday, February 28, 2016 7:15 AM, Vicente J. Botet Escriba
Le 27/02/2016 17:41, Steven Watanabe a écrit :
AMDG
On 02/27/2016 09:16 AM, Vicente J. Botet Escriba wrote:
The formal review of Paul Fultz II's Fit library starts on Wednesday, 2nd March and ends on 13th March.
Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects.
constexpr infix_adaptor
plus = {}; int r = 3 <plus> 2; This is clever idea, but I'd really like to see an analysis of how it interacts with operator precedence.
You should consider the normal precedence for operator<() and operator>() and use parenthesis when you are not sure what will be the result ;-) There is no magic.
Idealy I would like that we can use a different symbol to enclose the function name e.g;the back-quote '`' which is not used now and have left associativity with the highest precedence, but this is not possible now and would very probably never be :(
I found it useful e.g. if you have a binary function
mbind(Monad, Callable) -> Monad
Using the infix notation allows to chain the continuations in a more natural way
m <mbind> []() {....} <mbind> []() {....}
instead of
mbind(mbind(m, []() {....}), []() {....} );
What is terrible is that the following (I believe) will work also :(
m < mbind > []() {....} < mbind > []() {....}
Yes it is designed to easily chain the operations together. x <op> y <op> z
and also that :( :(
((m < mbind) > []() {....} < mbind) > []() {....}
Of course we don't want to write code like this one, but ...
With the first proposal of uniform call syntax we were able to have something similar
m.mbind(f).mbind.(g);
but this equivalence has not been retained for the time been.
But that can be achieved using pipable functions: m | mbind(f) | mbind(g)
So I could summarize the infix adaptor is just syntactic sugar that
doesn't respond completlly to my final goal, and should be used sparsely.
For most cases, I found pipable functions work much better to achieve the goal. The only advantage of an infix operator is lack of parenthesis, but I have never found it to be too much an issue. Finally, Boost.Hana uses the ^ operator to achieve infix notation instead. Ideally, I could create a decorator such as `infix_with` that could set the type of operator to use with infix notation, because sometimes the user may want to control precedence. However, I would like to see how widely this would be used before taking on such an endeavor. Currently it is only used in a few instances that don't need this type of customization.
Vicente
P.S. Paul, maybe you can add something about this in the documentation of infix.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users