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
Louis Dionne
@ldionne
However, a variant that knows which type it contains is pretty much equivalent to the type it contains itself, see what I mean?
So such a construct in Hana-world is not too useful, at least from what I can see so far. In fact, Hana contained a hana::either at some point (which is really just a binary variant), but it was removed precisely for this reason.
That being said, a constexpr variant probably makes a lot of sense in the context of a constexpr-enabled standard library, such as Sprout.
And in fact they already seem to have a constexpr variant, but I don’t quite understand the implementation (it seems to be based on tuple, not union, which is strange).
Klemens Morgenstern
@klemens-morgenstern
Yeah, I guessed that. Actually the only application for a constexpr variant I could think of, was to limit the types you could use with a particular functions. Since Concepts will come eventually, this would be a misguided attempt.
Louis Dionne
@ldionne
Well, I sure think it could be useful if you need to use the variant in a generic algorithm that you want to make constexpr.
And there are probably many other use cases.
Klemens Morgenstern
@klemens-morgenstern
Ok, wenn then it could maybe be a successor to boost.variant. I'll annoy the boost mailing lists then
Louis Dionne
@ldionne
Then again, boost::variant aims to be a more general purpose variant from what I understand, and I don’t know whether it’s possible to make its implementation constexpr. Are there significant differences between your variant and e.g. std::variant besides constexpr-friendliness?
If not, then I’m sure the wider C++ community would actually jump on this implementation.
Klemens Morgenstern
@klemens-morgenstern
Not really, it might implement more conversions etc.
i.e. an implicit conversion like that:
variant<int, char> v = 42;
variant<int, char, double> v2 = v;
But the whole constexpr stuff changes the implementation of the storage rather intensively, so I am not sure if that actually makes that much sense.
Klemens Morgenstern
@klemens-morgenstern
I.e. I might want to implement a version of std::variant and push what it can do - starting with constexpr :smile:
Louis Dionne
@ldionne
Alright. In any case, feel free to keep us here updated on how that goes. @mpark Haven’t you also implemented a constexpr variant at some point?
hia3
@hia3
Hello guys! hana::apply == std::invoke, std::apply == hana::?
hia3
@hia3
it is hana::unpack probably
hia3
@hia3
Do you guys know your hana::unique example does not work with clang 4.0.0? http://melpon.org/wandbox/permlink/iMBBa9vrZWZbns2N
3.8 is fine though
hia3
@hia3
Oh, it is only broken in -std=c++1z mode. Does hana support C++17?
Jason Rice
@ricejasonf
@hia3 boostorg/hana#292
hia3
@hia3
@ricejasonf Thanks. Luckily boost::hana::to_set works :-)
hia3
@hia3
hana::set is not Iterable? I can get the size of the set and compare it with zero, but is_empty(my_set) does not work. Wut?
Louis Dionne
@ldionne
It does not make sense for set to be Iterable, because there’s no specified order for the elements.
I do agree that it would make a lot of sense for is_empty(set) to work; see boostorg/hana#196.
hia3
@hia3
Can an exception be made for a single-element set?
Jason Rice
@ricejasonf
@hia3 to do what? set is Foldable btw.. maybe that is what you need?
hana::compose(hana::size, hana::equal.to(hana::size_c<0>))
Louis Dionne
@ldionne
@hia3 No, an exception can’t be made. It would be equivalent to saying that a std::set<T> with a single element is a SequenceContainer, because it happens to have a single element.
The fact that a std::set has a single element is a runtime property, while the concepts that it model is a property of the type system, which allows you to reason about your code.
Hana’s type system is its tag dispatching system, and the contents of a container is not part of that.
Even though we could technically do it because all of it is known at compile-time, it is very important that we enforce this phase distinction so that we can stay sane when writing code with Hana.
So, as always, the question is: what are you trying to achieve?
hia3
@hia3
@ricejasonf @ldionne Here is what I'm trying to do - http://melpon.org/wandbox/permlink/ENjifTuFiXkAFB6j I don't like that to_tuple call.
Jason Rice
@ricejasonf

The items contained in a set have no specified order so you can't technically rely on any one item being in "front". That being said you could use unpack since set is Foldable. Something like:

hana::unpack(my_set, hana::arg<1>);

This would fail just like hana::front would if the set was empty.

Jason Rice
@ricejasonf
It doesn't sound like a job for set though.
Are you just trying to get unique types?
hia3
@hia3
@ricejasonf Thanks. Yes, I'm trying to get unique types, but hana::unique does not work on clang :smile:
Jason Rice
@ricejasonf
I have a fork that works around the clang bug for c++1z, but folding with hana::insert is better because (I think) unique requires sorted or already grouped values.
Using insert is what I did in the above link.
hia3
@hia3
Hello guys! Serious question this time - http://melpon.org/wandbox/permlink/bzHJ1SzTI9L3cAlL
It does not compile if operators & and *are defined (see that #if 1). Do you think it is a hana bug or gcc bug? Because cang does compile this. :-)
*clang
hia3
@hia3
I'm iterating over hana::types, how and why it finds what's inside?
Louis Dionne
@ldionne
I would say it’s a GCC bug. Hana uses &f on the function, but it appears that GCC incorrectly uses the operator& and operator* that you’ve defined.
Basically it’s substituting your lambda with the result of calling your operators, and obviously that’s not callable.
That’s my understanding. So I would say this is both a bug in GCC and a very bad usage of operator* with a fully unconstrained template parameter.
hia3
@hia3
But why it does not use std::addressof or std::forward? detail::on_each<decltype(std::addressof(f))>{std::addressof(f)})