Boost logo

Boost :

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-08-02 18:11:25

> Well, if you define the `sum` function, that's because you are defining an
> instance of the corresponding type class (Foldable). Hence, you are
> already
> choosing the MCD:
> namespace boost { namespace hana {
> template <>
> struct Foldable::instance<YourDatatype> : Foldable::the_mcd_you_want {
> // minimal complete definition here
> template <typename Xs>
> static constexpr auto sum_impl(Xs xs) {
> // your custom sum implementation
> }
> };
> }} // end namespace boost::hana
> Am I missing your point?

Yes, I shouldn't have used `sum` as an example. So say a another library
to implement `xor` or `bitand`, can they use different MCDs to optimize it
like what `sum` does? And if they can, then `sum` could do the same thing as
well. If they cannot, then this should be fixed. Its not possible to think
every single fold algorithms and put it into a typeclass beforehand.

> The truth is that I think users should not feel the need to add methods to
> existing type classes. If a method can be implemented in a type class
> _and_
> has a general utility, then it should be added to the type class for
> everyone
> to benefit. If, however, you need more "structure" than provided by
> existing
> type classes to do something, then you create a new type class which
> carries
> that additional "structure" and in which you can implement more
> operations.
> That's how I see it.

> It should be possible to build on top of your library to create general
> utilities without requiring the user to patch your library.
> It should work; Hana was designed exactly to deal with that. Here's what
> happens (that's going to be in the tutorial also):
> 1. decltype_(x) == decltype_(y) returns a bool_<true or false>
> 2. bool_* has a constexpr conversion to bool defined as:
> template <bool b>
> struct bool_type {
> constexpr operator bool() const { return b; }
> };
> Since the conversion is always constexpr, it's used in the `static_assert`
> and it works. Now, it does not __actually__ works because of what I think
> is a bug in Clang. For it to work, you have to define a dummy object like
> that:
> template <typename X, typename Y>
> void foo(X x, Y y) {
> auto dummy_result = decltype_(x) == decltype_(y);
> static_assert(dummy_result, "");
> }
> And that will compile. Am I exploiting some hole in Clang or is this
> correct
> w.r.t. C++14? I'm unfortunately not really a standards guy, so if someone
> can
> help here that'd be helpful.

According to my understanding of the language, if you try to call `foo` with
`std::vector` it will fail, since `std::vector` is not a literal type nor is
it constexpr-constructible. If it does work on clang using the dummy
trick then it looks like you are exposing a hole in Clang. Of course, I
be wrong.

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at