These are chat archives for boostorg/hana

16th
Dec 2015
Louis Dionne
@ldionne
Dec 16 2015 03:02

Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.

I have no preference. Off the top of my head, I can't think of a reason to use a Pred const& member over std::declval, except for the need to include <utlity> to use std::declval. But <utility> is already included everywhere anyway, so this isn't a strong reason.

Those are the only two with that problem with the predicate returning a const& btw

Cool!

Actually idk, it looks pretty deliberate. I'll refrain from changing it.

What looks deliberate? The usage of Pred const& over std::declval()? It probably just happened that way, because both algorithms were implemented at different times.

Jason Rice
@ricejasonf
Dec 16 2015 03:19
It looked "deliberate" because filter.hpp actually had both (lift_or_empty uses declval), so I figured maybe there was a reason I didn't see. I just left it alone.
Louis Dionne
@ldionne
Dec 16 2015 13:33
That’s fine.
Jason Rice
@ricejasonf
Dec 16 2015 19:08
@ldionne Do you recommend any specific approach to named parameters?
Louis Dionne
@ldionne
Dec 16 2015 19:26
Use a hana::map from arguments to values.
Represent the names of the arguments however you prefer, compile-time strings or types or whatever else.
Then, define an operator to create pairs (syntactic sugar).
template <char ...s>
struct NamedParameter {
    template <typename Value>
    auto operator=(Value const& v) {
        return hana::make_pair(*this, v);
    }
};

template <char ...s>
auto operator""_param() {
    return NamedParameter<s...>{};
}

int main() {
    some_function("a"_param = 3, "b"_param = 4, ...);
}
Something along those lines. Then, some_function may create a hana::map to search through its arguments.
Louis Dionne
@ldionne
Dec 16 2015 19:31
It’s arguably annoying to have to create hana::map by hand inside some_function, so you might want to have a wrapper that does it automatically. Something like
auto wrapper = [](auto function) { 
    return [](auto ...args) { 
        return function(hana::make_map(args...)); 
    }; 
};
You can define function = [](auto args) { use(args[“a”_param]); }. You’ll need to make NamedParameter Comparable.
Jason Rice
@ricejasonf
Dec 16 2015 19:35
:heart_eyes: nice! ty
that's an interesting way to initialize a map
Louis Dionne
@ldionne
Dec 16 2015 19:41
Yes, quite. I used something similar for a library I was writing for a client recently.
Works well, but it is annoying to have to copy the arguments into the map.
The restriction of not having references in containers is a f*cking pain, but I don’t see an easy way around it. Just like std::vector won’t allow for references.
Jason Rice
@ricejasonf
Dec 16 2015 19:42
ah.. so it is not zero cost
Louis Dionne
@ldionne
Dec 16 2015 19:43
Well, you can move-in the arguments and it should be pretty-much zero cost. But it’s not zero cost strictly-speaking.
But if you pass arrays as named parameters, they’ll have to be moved (which may be inefficient).
Or you can store the arguments with std::reference_wrappers, but then you’ll have to use args[“a”_param].get() inside the function.
Jason Rice
@ricejasonf
Dec 16 2015 21:47
Would it be possible to add that auto operator= to type and integral_constant?
This message was deleted
Jason Rice
@ricejasonf
Dec 16 2015 21:56
You mentioned some things about improving map before. I would like to discuss it, when you are not too busy.