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
Klemens Morgenstern
@klemens-morgenstern
So I could imagine to do something like this
using str = BOOST_HANA_STRING_TYPE("string"); //no idea how to do that.
BOOST_HANA_STRING_TYPE(str, "string"); //that would work.
Does anyone has an idea how to do the first? And: would you think that would be a good thing for hana?
Jason Rice
@ricejasonf
I don't think it is possible without using a lambda.
Although outside of a class hmm...
Jason Rice
@ricejasonf
Yeah, I can't see how it could be done.
the first part that is
@ldionne said that he was going to propose the use of lambdas in unevaluated contexts for C++17, but I don't know if it was even proposed or considered.
Louis Dionne
@ldionne
The paper proposing lambdas in unevaluated contexts was rejected for C++17 because the wording was wrong.
I rewrote the wording and will be proposing it for C++20.
But regardless, the far better alternative is to standardize the literal operator template for string literals, for which I have also written a paper.
(For C++20)
Klemens Morgenstern
@klemens-morgenstern

The first part does work already. But you can't write

using type = typename   struct {...}::type; 
//I.e.:
#define STR(Str) typename  struct {...}::type;

which is why I'd need something like that

#define STR(Id, Str) \
struct __##Id##__impl {}; \
using Id = typename  __##Id##__impl::type ;
You could then put this in a namespace or a class, but not a function.
@ldionne I sincerly hope that it becomes standard. Wasn't the literal operator also proposed for C++17? I actually don't get why a string-literal cannot be used as a template parameter.
Louis Dionne
@ldionne
The literal operator was proposed in C++14 but rejected.
On what I argue is wrong basis
I’m not sure, but I think there were issues with acepting string literals as template parameters.
Since each literal has a unique address. I’m not sure anymore, you should do some archeology. I’m sure this has been discussed before.
And if there’s no reason not to support it, I encourage you to write a paper
Jason Rice
@ricejasonf
It would be awesome to be able to do that.
Klemens Morgenstern
@klemens-morgenstern
Ok, so would you think if the macro defines an additional type, but let's you define static string in an unevaluated context, that would fit into hana?
@ldionne Well, I think this is the issue: you would have to pass the string as a reference, making two equal declarations different. So you would need to use an alias here, analyze the string and than pass a back something like hana::string. Also you can pass a reference as a template parameter, if it has extern linkage; but that wouldn't allow you to analyze the value at compile-time. So the more I think about it, the more I guess there are good reasons.
Working with the literal operator is the much better approach here, I think. You wouldn't get the confusion.
Louis Dionne
@ldionne
right
Klemens Morgenstern
@klemens-morgenstern
Ok, next question: do you think a constexpr variant would be useful for boost.hana? I've built one here
It currently allows constructing and getting values, but nothing else yet, like visiting.
Jason Rice
@ricejasonf
Would it just fail to compile if you did 'get<2>'?
Klemens Morgenstern
@klemens-morgenstern
In constexpr? Yes it gets into the branch with a throw so the comstexpr is invalid.
Klemens Morgenstern
@klemens-morgenstern

So if you write this:

constexpr variant<int, char> v = 'C';
constexpr int i = get<0>(v);
constexpr int j = get<int>(v);

It will give a compile-error at compile time; but it will throw an exception at runtime.

Louis Dionne
@ldionne
A constexpr variant is a nice utility, but I don’t think it makes much sense for Hana. Here’s why: If a variant was to be included in Hana, it would have to know what type it contains (out of the N possible variants) at compile-time, just like hana::optional knows whether it is empty or not at compile-time. And by compile-time, I really mean that the information is encoded in the type of the variant, not only that the variant can be used inside a constant expression.
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