These are chat archives for boostorg/hana

14th
Apr 2016
Jason Rice
@ricejasonf
Apr 14 2016 16:38
@ldionne I heard you on cppcast :+1:
Louis Dionne
@ldionne
Apr 14 2016 16:39
Cool, I hope you liked it! Always difficult to explain our heterogeneous hash table in 20 seconds
lol
Barrett Adair
@badair
Apr 14 2016 18:24
I liked it! Regarding MSVC - "well, two-phase lookup would be great" - I laughed out loud.
Louis Dionne
@ldionne
Apr 14 2016 18:24
lol, I had a big smile when I said that
Barrett Adair
@badair
Apr 14 2016 19:28
Out of curiosity, why is types classified as experimental?
Louis Dionne
@ldionne
Apr 14 2016 19:37
Because it’s still just an experiment, in the sense that I don’t know exactly what concepts it should model. I also don’t know how to name it, and haven’t planned on an official path to include it in the library. Since I want to avoid breaking backward compatibility in minor versions, I see no harm in waiting before making it part of the official stable API.
Barrett Adair
@badair
Apr 14 2016 19:58
That makes sense. As far as naming goes, since it's not nailed down yet, my two cents would be to use a container-ish name.
Have you ever experimented with using a function type as a type list, whose parameters are the elements? I seem to recall that touched on that in a blog post or conference talk.
*that you touched on that
Louis Dionne
@ldionne
Apr 14 2016 20:58
No, I don’t think I ever did that. But doesn’t that create problems because some types are not allowed from appearing as function arguments?
Or stuff like an array will decay to a pointer.
Barrett Adair
@badair
Apr 14 2016 21:13

But doesn’t that create problems because some types are not allowed from appearing as function arguments?

Yes, I didn't think of that. I suppose the user could use hana::type or something similar to wrap only those corner cases, but that would still be annoying. Still, I wonder how it would perform against existing type list implementations. Also, it would be an interesting syntax... something like

using f = param_list(char, short, long);

I'm going to add some lightweight tuple-y stuff to CallableTraits, since those operations are the only ones missing to solve the function-type-specialization-spam problem that the project attempts to solve - i.e. there's currently no way to push_args_front on a signature without having to go through the template specialization rigmarole, so I'll throw it in the functionality for now (and maybe take it out later). Since my use case concerns real parameter types, the restrictions you mentioned aren't a problem for me (but would be for a generic type container).

Just wanted to see if you'd been down that road. Thanks!

Louis Dionne
@ldionne
Apr 14 2016 22:11
Regarding the compile-time perf of this list vs another type list, I would expect basically the sam thing. Actually, maybe the template-based type list would be better, because in the case of a function the compiler might have some sanity checks to do on the arguments
Barrett Adair
@badair
Apr 14 2016 22:13
That makes sense, especially if the template based type list doesn't use any dependent names
Louis Dionne
@ldionne
Apr 14 2016 22:39
Straight templates without much in them are usually pretty cheap for the compiler, so yeah.
Barrett Adair
@badair
Apr 14 2016 22:40
By the way, I used metabench the other day to determine whether std::disjunction was faster than std::conditional for a certain large type operation. It was really useful!