Re: [boost] [GSoC] [Boost.Hana] Formal review request

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
wants
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
of
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
variable
trick then it looks like you are exposing a hole in Clang. Of course, I
coulde
be wrong.

--
View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-tp4665622p4665955.html
Sent from the Boost - Dev mailing list archive at Nabble.com.