Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Maik Klein
@MaikKlein
Is there an alternative to unpack?
  auto r4 =
    hana::unpack(t, [](auto&... r) { return ranges::view::concat(r...); });
this will always crash the compiler :(
I need to pass the elements of a tuple to a function
int
main()
{

  std::vector<int> iv{ 1, 3, 4, 5 };
  std::vector<float> fv{ 1, 3, 4, 5 };

  auto r1 = ranges::view::all(iv);
  auto r2 = ranges::view::all(fv);
  auto r3 = ranges::view::zip(r1, r2);
  auto rint =
    ranges::view::zip(r3, ranges::view::closed_ints(0ul, ranges::size(r3)));
  auto t = hana::make_tuple(rint, rint);
  auto r4 =
    hana::unpack(t, [](auto&... r) { return ranges::view::concat(r...); });
  //crash
  for(auto t: r4){

  }
}
Maik Klein
@MaikKlein
Also tried
  auto r4 =
    hana::unpack(t, ranges::view::concat);
oh nvm sorry, it is completely unrelated to hana.
Maik Klein
@MaikKlein
I run into way too many compiler errors lately, any ideas? How can I check which version of libstdc++ is used by clang?
Louis Dionne
@ldionne
@MaikKlein You can try clang++ -E -x c++ - -v < /dev/null and see if the header search paths help you. Otherwise, see this SO question.

@ricejasonf

Did your clang built-in ever get looked at?

Not yet... Still waiting.

The search bar in the docs appears to be broken.

How is it broken? It seems to work for me.

Jason Rice
@ricejasonf
Yesterday it wasn't populating search results box. It's working for me now though.
Louis Dionne
@ldionne
Strange; perhaps some javascript requirement was unable to load properly?
Jason Rice
@ricejasonf
idk.. I tried hard refreshing it yesterday without change. I saw xhr requests with 200 responses but no response body.
Louis Dionne
@ldionne
Well, as long as it works now. Plus, I have not changed anything significant that could have broken this.
Jason Rice
@ricejasonf
I guess they aren't actually xhr requests. naw it's working fine now. It could have been a github thing
Jason Rice
@ricejasonf
It would be handy to have a version of partial or capture that captures by reference.
Barrett Adair
@badair
Indeed!
Maik Klein
@MaikKlein
okay it seems clang3.7 on arch is broken
Louis Dionne
@ldionne
@ricejasonf Technically, you can achieve this with std::ref, but you’ll end up with reference wrappers instead of actual references.
Jason Rice
@ricejasonf
@ldionne Yes, I'm going to play around with that.
Louis Dionne
@ldionne
References are damn pests. They are very useful, but they just don’t behave like objects… Same problem in the STL.
Barrett Adair
@badair
I agree 100%. reference_wrapper is a decent bandaid, but the lack of ability to :: them makes them unappealing for metaprogramming.
The fact that you dont get implicit conversions on the SR operator isn't reference wrapper's fault, though
Louis Dionne
@ldionne
SR operator?
Barrett Adair
@badair
Scope resolution? Thats what I've always called it. ::
Louis Dionne
@ldionne
Oh, I couldn’t understand the accronym
Barrett Adair
@badair
Sorry, on mobile
Louis Dionne
@ldionne
No problem
Jason Rice
@ricejasonf
I played around with hana::partial and std::ref. It yielded nothing other than a slightly slower compile time. I also forgot that my stuff is, for the most part, empty. (Although the whole tree probably adds up to like 50-100 bytes)
Jason Rice
@ricejasonf
It also couldn't be used in only some of the constexprs which was weird. https://gist.github.com/ricejasonf/78f62e74d9dec0d72bbf
Barrett Adair
@badair
Are you familiar with the implementation of std::ref/cref and std::reference_wrapper?
If not, it might bring some clarity to issues you encounter. It's been some time since I've read the specs on them, but they are actually really simple
Barrett Adair
@badair
Is the code you posted
(Sorry, didn't mean to send that)
Barrett Adair
@badair
I honestly don't see a way to implement a perfect forwarding version of hana::partial without resorting to heavy type manipulation and lots of additional code I think
(Man this chat thing is touchy)
...I think it's probably in Hana's best interest to document hana::partial as a value-only tool, and to use a reference_wrapper for references
Barrett Adair
@badair
And to forget about a perfect forwarding partial. I know how I would implement it, but it would be a lot of code for an edge use case. The idea of reference forwarding in a partial application is kind of silly, since the reference needs to be in scope anyway.
TLDR; +1 for reference_wrapper
Barrett Adair
@badair
I will try to implement a perfect forwarding partial application in my project when i finish the changes I'm in the middle of making. I will let you know if I succeed
Louis Dionne
@ldionne

I think a perfect forwading partial would be easy to achieve. Go look at the rest of partial's implementation, but we would most likely need the following only:

template <std::size_t ...n, typename F, typename ...X>
struct partial_t<std::index_sequence<n...>, F, X...> {
    // ... same as before ...

    // Here, instead of storing actual values, store references
    basic_tuple<F, X&&...> storage_;

    // ... same as before ...
};

So I don't think the problem is the implementation complexity, but rather the use case we'd have for this, and how to make this variant of partial available without making the interface more complex (so without adding partial_ref).

Barrett Adair
@badair
how would you put lvalue references in the tuple above? X&& is not a universal reference - right?
Thats the heart of the problem, afaik
Louis Dionne
@ldionne
I think it would work if make_partial did not decay the arguments
Since X would be a reference type (some T&), and then X&& would be T& &&, which collapses to T& by reference collapsing rules.
Barrett Adair
@badair
That makes sense
Same logic as std::forward
Louis Dionne
@ldionne
Yyes.
Barrett Adair
@badair
Wouldn't you still need to move-construct from rvalue references? For safety? And then re-move on the re-forward?
Or probably const ref on the re-forward
That's a difficult decision, since you can't bind crefs to rrefs, but you can do the opposite. So it depends on the signature of the hosted callable