New library? CallableTraits
I posted about this a month ago, but I did not receive much response. Since then, I added an extended example use case, and I added a documentation section [1] that compares CallableTraits and Boost.FunctionTypes. I received some positive feedback this week in Aspen, and r/cpp also seemed to respond well [2], so I thought I'd give this another shot. Here are my questions for you: 1. Is there any interest in reviewing a future version of this for inclusion in Boost? 2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar? 3. What you like to see added, removed, renamed, or redesigned? I'd say CallableTraits is about 85% finished. Here's what's left: * Add INVOKE semantics to a couple of things for consistency (arity, etc) * Remove unused/undocumented code * Account for transaction_safe and C++17 noexcept * Finish/test the calling convention features * Finish/update the reference documentation * Write even more tests Cheers, Barrett [1] http://badair.github.io/callable_traits/doc/html/index.html#callable_traits.... [2] https://www.reddit.com/r/cpp/comments/4ffmfs/callabletraits_never_write_anot... GitHub: https://github.com/badair/callable_traits Documentation from the top: http://badair.github.io/callable_traits/doc/html/index.html (reference section under construction)
On 5/13/2016 2:28 AM, Barrett Adair wrote:
I posted about this a month ago, but I did not receive much response. Since then, I added an extended example use case, and I added a documentation section [1] that compares CallableTraits and Boost.FunctionTypes.
I received some positive feedback this week in Aspen, and r/cpp also seemed to respond well [2], so I thought I'd give this another shot.
Here are my questions for you:
1. Is there any interest in reviewing a future version of this for inclusion in Boost? 2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar? 3. What you like to see added, removed, renamed, or redesigned?
I'd say CallableTraits is about 85% finished. Here's what's left: * Add INVOKE semantics to a couple of things for consistency (arity, etc) * Remove unused/undocumented code * Account for transaction_safe and C++17 noexcept * Finish/test the calling convention features * Finish/update the reference documentation * Write even more tests
I will give my usual reaction to documentation that consists mainly of long examples and a reference. Actually create an overview that explains the functionality of your library. This would consist of explaining what your library actually is supposed to do, grouped by areas of general functionality with simple short examples for each area of general functionality you discuss. Your overview doesn't have to be perfect, none are, but at least it's an attempt to tell others what the practical uses of your library may be. BTW, what is MSVC19 supposed to represent ? I assume this is a misprint.
Cheers, Barrett
[1] http://badair.github.io/callable_traits/doc/html/index.html#callable_traits....
[2] https://www.reddit.com/r/cpp/comments/4ffmfs/callabletraits_never_write_anot...
GitHub: https://github.com/badair/callable_traits Documentation from the top: http://badair.github.io/callable_traits/doc/html/index.html (reference section under construction)
On Fri, May 13, 2016 at 10:22 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
I will give my usual reaction to documentation that consists mainly of
long examples and a reference. Actually create an overview that explains the functionality of your library. This would consist of explaining what your library actually is supposed to do, grouped by areas of general functionality with simple short examples for each area of general functionality you discuss. Your overview doesn't have to be perfect, none are, but at least it's an attempt to tell others what the practical uses of your library may be.
Did you see the "Overview" example [1]? I received a similar criticism previously, and this example was my response to that. It's a bunch of simple, short examples grouped by functionality -- they all just happen to reside in the same example program. Maybe I need to flesh this out better.
BTW, what is MSVC19 supposed to represent ? I assume this is a misprint.
I use Visual Studio 2015, but the actual C++ compiler, MSVC, has the version number 19.0.23918.0. That's my understanding, anyway. [1] http://badair.github.io/callable_traits/doc/html/callable_traits/quick_examp...
Barrett Adair <barrettellisadair <at> gmail.com> writes:
I posted about this a month ago, but I did not receive much response. Since then, I added an extended example use case, and I added a documentation section [1] that compares CallableTraits and Boost.FunctionTypes.
I received some positive feedback this week in Aspen, and r/cpp also seemed to respond well [2], so I thought I'd give this another shot.
Here are my questions for you:
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed similar functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
3. What you like to see added, removed, renamed, or redesigned?
Here are a few comments on the documentation and the library itself: - IMO, the overview should include explanations in running text rather than just comments in the code. Or if you want to keep code only, which might be a good idea, I would make it a bit shorter. Do not try to show all the features and details of the library; this is just an overview. - The Java-style interface example is _huge_, and IMO it doesn't fit into an example at the beginning of the documentation. It might be better to include it as an appendix. - The library documents many concepts, but it seems to me that they are not really concepts as we usually mean in C++. To me, most of them are just vocabulary terms (that could e.g. appear in a glossary). When I introduce concepts in a library, I usually design my concepts as some kind of hierarchy with semantic properties that allow me to describe a few key types of objects. Instead, I see some "concepts" in CallableTraits as just glossary terms without semantics. For example, instead of the "FunctionPtr" concept, you could have a "Function pointer" entry in a glossary. - Suggestion: use `replace_at` instead of `overwrite_at`? - A few metafunctions have the `_at` suffix; is this necessary? - Instead of `can_invoke`, something like `is_invokable` might be better? Querying traits often start with `is_`.
I'd say CallableTraits is about 85% finished. Here's what's left: * Add INVOKE semantics to a couple of things for consistency (arity, etc) * Remove unused/undocumented code * Account for transaction_safe and C++17 noexcept * Finish/test the calling convention features * Finish/update the reference documentation
Finishing the reference documentation is, IMO, the #1 priority if others express interest towards the library and you want to make it part of Boost. I don't think a formal review can take place before the documentation is done, but you might want to wait to see if there's interest before investing a lot of time in the documentation. Regards, Louis
On Sun, May 15, 2016 at 8:13 AM, Louis Dionne <ldionne.2@gmail.com> wrote:
Barrett Adair <barrettellisadair <at> gmail.com> writes:
(snip)
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed
similar
functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
This is great to hear.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
Also great!
3. What you like to see added, removed, renamed, or redesigned?
Here are a few comments on the documentation and the library itself:
- IMO, the overview should include explanations in running text rather
than
just comments in the code. Or if you want to keep code only, which might be a good idea, I would make it a bit shorter. Do not try to show all the features and details of the library; this is just an overview.
I've updated the introduction so that it begins with a simple, terse overview [1]. Is this a step in the right direction?
- The Java-style interface example is _huge_, and IMO it doesn't fit into an example at the beginning of the documentation. It might be better to include it as an appendix.
That's a good point. I've moved it to the end of the documentation for now.
- The library documents many concepts, but it seems to me that they are not really concepts as we usually mean in C++. To me, most of them are just vocabulary terms (that could e.g. appear in a glossary). When I introduce concepts in a library, I usually design my concepts as some kind of hierarchy with semantic properties that allow me to describe a few key types of objects. Instead, I see some "concepts" in CallableTraits as just glossary terms without semantics. For example, instead of the "FunctionPtr" concept, you could have a "Function pointer" entry in a glossary.
Hmm, that's another good point. I will think about this suggestion, and I'll change the name of the section at the very least. I came up with the concept "members" idea while writing the reference documentation - I think it will make the reference section easier to write and comprehend. However, I may be completely off-base about this.
- Suggestion: use `replace_at` instead of `overwrite_at`?
- A few metafunctions have the `_at` suffix; is this necessary?
I renamed `overwrite_at` to `replace_args`. I did the same for the other `_at` metafunctions.
- Instead of `can_invoke`, something like `is_invokable` might be better? Querying traits often start with `is_`.
It seems that this offers similar functionality to C++17's `is_callable`, but it might be worth keeping around for those who are stuck with older compilers/std libraries. I may actually rename this to `is_callable` and then remove CallableTraits' existing `is_callable` trait.
I'd say CallableTraits is about 85% finished. Here's what's left: * Add INVOKE semantics to a couple of things for consistency (arity,
etc)
* Remove unused/undocumented code * Account for transaction_safe and C++17 noexcept * Finish/test the calling convention features * Finish/update the reference documentation
Finishing the reference documentation is, IMO, the #1 priority if others express interest towards the library and you want to make it part of Boost. I don't think a formal review can take place before the documentation is done, but you might want to wait to see if there's interest before investing a lot of time in the documentation.
Yes, definitely. Part of my reasoning for bringing this to the mailing list at this stage is that I'll be much more motivated to finish the reference docs in a timely manner if people are interested in adding this to Boost. Yesterday I committed the code changes for INVOKE consistency, and removed a lot of unused code. Thanks for your detailed response. Barrett [1] http://badair.github.io/callable_traits/doc/html/index.html#callable_traits....
Barrett Adair <barrettellisadair <at> gmail.com> writes:
On Sun, May 15, 2016 at 8:13 AM, Louis Dionne <ldionne.2 <at> gmail.com> wrote:
Barrett Adair <barrettellisadair <at> gmail.com> writes: [...]
3. What you like to see added, removed, renamed, or redesigned?
Here are a few comments on the documentation and the library itself:
- IMO, the overview should include explanations in running text rather than just comments in the code. Or if you want to keep code only, which might be a good idea, I would make it a bit shorter. Do not try to show all the features and details of the library; this is just an overview.
I've updated the introduction so that it begins with a simple, terse overview [1]. Is this a step in the right direction?
This is a step in the right direction, although I still find it a bit hard to follow. I mean, I know what CallableTraits can be useful for, but for someone that doesn't already know it, it might be better to write a tutorial-style introduction. I'm thinking about something similar to Hana's quickstart section [1]. Regards, Louis [1]: http://boostorg.github.io/hana/index.html#tutorial-quickstart
On Sun, May 15, 2016 at 6:13 AM, Louis Dionne <ldionne.2@gmail.com> wrote: Hi,
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed similar functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
Throwing in my two bits here, I absolutely agree that ultimately the type_traits header should provide something allowing this sort of introspection.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
I guess not a /strong/ opinion, but I would like to see it just be part of Boost Type Traits. It feels like something that we should be able to do in a single library? -Jesse
On Mon, May 16, 2016 at 3:34 PM, Jesse Williamson <jesse@mind.net> wrote:
On Sun, May 15, 2016 at 6:13 AM, Louis Dionne <ldionne.2@gmail.com> wrote:
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed
similar
functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
Throwing in my two bits here, I absolutely agree that ultimately the type_traits header should provide something allowing this sort of introspection.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
I guess not a /strong/ opinion, but I would like to see it just be part of Boost Type Traits. It feels like something that we should be able to do in a single library?
The reference documentation is now available [1]. It's a first draft, but it should clarify much of the uncertainty surrounding the CallableTraits feature set. I agree that Boost.TypeTraits is the best place for these features. Would a formal review be in order if CallableTraits is not going to be submitted as a standalone library? I removed several scope-creepy features from CallableTraits, which brought the source line count down from 4200 to around 2500. I also rewrote the interface to follow the `<type_traits>` conventions (e.g. `_t` and `_v` suffixes). I still need to write more test cases, especially for the substitution failure claims about template constraint violations -- I'm pretty sure the reference documentation is ahead of the code in this regard. I also need to supply better use-case examples. Thanks, Barrett Adair [1] http://badair.github.io/callable_traits/doc/html/callable_traits/reference.h...
On Mon, Jun 20, 2016 at 9:52 PM, Barrett Adair <barrettellisadair@gmail.com> wrote:
On Mon, May 16, 2016 at 3:34 PM, Jesse Williamson <jesse@mind.net> wrote:
On Sun, May 15, 2016 at 6:13 AM, Louis Dionne <ldionne.2@gmail.com>
wrote:
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed
similar
functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
Throwing in my two bits here, I absolutely agree that ultimately the type_traits header should provide something allowing this sort of introspection.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
I guess not a /strong/ opinion, but I would like to see it just be part of Boost Type Traits. It feels like something that we should be able to do in a single library?
(snip)
I agree that Boost.TypeTraits is the best place for these features. Would a formal review be in order if CallableTraits is not going to be submitted as a standalone library?
(snip)
Since I haven't received a response to my last post, I decided to go ahead and start moving the CallableTraits code into a Boost.TypeTraits fork today [1]. First, I'll get my most important questions out of the way (feel free to respond to only this paragraph). Before I reformat my reference documentation to match that of TypeTraits, I would like to know whether this would be a fruitful endeavor. Are any of the features added in this fork worth keeping in Boost.TypeTraits? If so, which features (if any) need to be removed, renamed, or re-designed? All of the features documented in my non-Boost reference documentation [2] are present in this fork, albeit in a Boost-ified form (e.g. `std::integral_constant` is now `boost::integral_constant`). I'm using `std::tuple` for a couple of things, where the MPL would have better backwards compatibility. The same is true for my (sometimes polyfilled) usage of `std::disjunction` and friends, which could be replaced by `or_`, etc. However, TypeTraits currently has a "no MPL dependencies" promise. Thoughts? I'm certain that my headers will need additional configuration to be included on the older compilers that Boost.TypeTraits still supports to varying degrees. For this reason, I haven't yet put any of my features into the top-level `type_traits.hpp` header. I've done a pretty good job of configuring my headers for C++11-compliant(ish) compilers, but I've completely ignored GCC < 4.8, Clang < 3.5, and Visual Studio < 2015. Other compiler vendors are ignored. Suggestions for easing this transition? I greatly increased the number of example programs. Boost.TypeTraits already has a few, but I don't see a Jamfile. Is there any CI on these? On a side note, is there any interest in having CMake/Travis/Appveyor support added to the TypeTraits tests/examples, particularly for the GitHub mirror? If these new features are added to `type_traits.hpp`, clients are going to experience a dip in compile-time performance. Is this an argument in favor of submitting CallableTraits as a standalone library? Cheers, Barrett Adair [1] https://github.com/badair/type_traits/tree/feature/callable_traits [2] http://badair.github.io/callable_traits/doc/html/callable_traits/reference.h...
On Wed, Jun 29, 2016 at 10:12 PM, Barrett Adair <barrettellisadair@gmail.com> wrote:
(snip)
Since I haven't received a response to my last post, I decided to go
ahead and start moving the CallableTraits code into a Boost.TypeTraits fork today [1].
First, I'll get my most important questions out of the way (feel free to
respond to only this paragraph). Before I reformat my reference documentation to match that of TypeTraits, I would like to know whether this would be a fruitful endeavor. Are any of the features added in this fork worth keeping in Boost.TypeTraits? If so, which features (if any) need to be removed, renamed, or re-designed? All of the features documented in my non-Boost reference documentation [2] are present in this fork, albeit in a Boost-ified form (e.g. `std::integral_constant` is now `boost::integral_constant`).
(snip)
[1] https://github.com/badair/type_traits/tree/feature/callable_traits [2]
http://badair.github.io/callable_traits/doc/html/callable_traits/reference.h... For clarification, I would like to emphasize the fact that my code IS actually integrated into the TypeTraits fork -- my previous message seems to suggest otherwise. All my test cases pass with GCC 6.1, and Visual Studio 2015 passes all test cases that don't rely on the constexpr-ness `boost::integral_constant::operator bool`. The 9 that fail will need to be updated. I have not built the fork's test suite on other compilers yet. Barrett
On 6/29/2016 11:12 PM, Barrett Adair wrote:
On Mon, Jun 20, 2016 at 9:52 PM, Barrett Adair <barrettellisadair@gmail.com> wrote:
On Mon, May 16, 2016 at 3:34 PM, Jesse Williamson <jesse@mind.net> wrote:
On Sun, May 15, 2016 at 6:13 AM, Louis Dionne <ldionne.2@gmail.com>
wrote:
1. Is there any interest in reviewing a future version of this for inclusion in Boost?
I think so. I've also heard a couple of people say that they needed
similar
functionality this week in Aspen, so I imagine this would be a useful addition to Boost. In the long term, I think we need something similar (perhaps a subset of CallableTraits) in the standard.
Throwing in my two bits here, I absolutely agree that ultimately the type_traits header should provide something allowing this sort of introspection.
2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar?
No strong opinion here, though it might be a bit large for an addition to Boost.TypeTraits? In all cases, if there's a review of the library, you can count on me to submit one.
I guess not a /strong/ opinion, but I would like to see it just be part of Boost Type Traits. It feels like something that we should be able to do in a single library?
(snip)
I agree that Boost.TypeTraits is the best place for these features. Would a formal review be in order if CallableTraits is not going to be submitted as a standalone library?
(snip)
Since I haven't received a response to my last post, I decided to go ahead and start moving the CallableTraits code into a Boost.TypeTraits fork today [1].
I think you should create Callable Traits as its own library rather than try to integrate it with Type Traits. It will be easier that way to submit your library for review. If it is reviewed and accepted it is possible then to integrate it with Type Traits if that is the direction you or reviewers feel you should go. It is much easier to get a library reviewed and accepted on its own than to have it be part of something else from the beginning. It should also be easier for you to design your library separately rather than be part of something else. I also feel that you should be as specific as possible as to what level of C++ callabole traits supports. It is possible to design a library where certain features are only available for a certain level of C++ support while other features require a different level of C++ support. But if you specify that your library on the whole needs C++14 on up in one place and C++11 on up in another place, it is just going to confuse the end-user. That's why it is important to be specific. It is perfectly acceptable to have a Boost library support only specific levels of C++ and/or specific compilers that support those levels. But it is very important to tell people what compiler and/or level of C++ support they will need to use your library. snipped...
On June 30, 2016 4:01:25 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:
On 6/29/2016 11:12 PM, Barrett Adair wrote:
2. If so, does this belong in its own library, or should it be
incorporated
into Boost.TypeTraits or something similar?
I agree that Boost.TypeTraits is the best place for these features. Would a formal review be in order if CallableTraits is not going to be submitted as a standalone library?
(snip)
Since I haven't received a response to my last post, I decided to go ahead and start moving the CallableTraits code into a Boost.TypeTraits fork today [1].
I think you should create Callable Traits as its own library rather than try to integrate it with Type Traits. It will be easier that way to submit your library for review. If it is reviewed and accepted it is possible then to integrate it with Type Traits if that is the direction you or reviewers feel you should go. It is much easier to get a library reviewed and accepted on its own than to have it be part of something else from the beginning. It should also be easier for you to design your library separately rather than be part of something else.
How do you come to that conclusion? An addition to an existing library only requires the maintainer's approval, ideally with a mini-review in a case like this.
But if you specify that your library on the whole needs C++14 on up in one place and C++11 on up in another place, it is just going to confuse the end-user. That's why it is important to be specific. It is perfectly acceptable to have a Boost library support only specific levels of C++ and/or specific compilers that support those levels. But it is very important to tell people what compiler and/or level of C++ support they will need to use your library.
+1 -- Rob (Sent from my portable computation device.)
participants (5)
-
Barrett Adair -
Edward Diener -
Jesse Williamson -
Louis Dionne -
Rob Stewart