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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-08-03 11:30:32

pfultz2 <pfultz2 <at> yahoo.com> writes:

> 
> > 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.

I don't see a way of doing that right now; you have to put the method in the 
type class to be able to give it a default definition which depends on the
MCD. I'll try to see if that can be achieved without re-designing the whole
type class system.

> [...]
>
> > 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.

Supposing this is not valid C++, then the following is equivalent (but
uglier 
to write):

    template <typename X, typename Y>
    void foo(X x, Y y) {
        static_assert(decltype(decltype_(x) == decltype_(y)){}, "");
    }  

I'll have a look at the standard and figure what should be accepted.

Regards,
Louis

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