Future of type_safe

[foonathan]

Thank you all for making this my most popular project with tons of daily clones!

However, I never intended that this would be such a widely used library. It started out as an experimentation ground for type safe programming techniques and then turned into my general utility library: I need an optional -> let's put it in type safe. I need a flag set -> let's put it in type safe. etc

But now it has become this huge project, so I'm not sure how to go from here.

As shown in the readme this library consists of basically three things:

• improved integer types
• type safe building blocks like strong typedefs or constrained type
• vocabulary types and optional/variant

If you just want improved integer types there are better and more advanced libraries. I don't think many people actually use the type safe building blocks other than the strong typedefs facility. And the vocabulary types are there because it has become my utility library. They're useful but don't really fit the label "type safe".

So I think people come and use this library for mainly two reasons:

1. The strong typedefs facility
2. The vocabulary types

Please correct me if I'm wrong in that assessment. (I could be completely off the tracks there)

I'm thus proposing the following plan:

1. Extract two other libraries out of type_safe: A strong typedefs library and a vocabulary type library.

   The strong typedefs library will be fully compatible, it is just the strong_typedefs.hpp header split into multiple files and with some more operations.

   The vocabulary type library will have some breaking changes, around optional and variant. I've learned a lot while doing them and like to revise some of my design decisions.

2. Maybe submit the strong typedef library to Boost. It would still be usable stand alone, but it might make it easier to use in some corporations.

3. Sometime in 2019 probably: Deprecate the stuff that has been extracted into other libraries.

This plan allows me to do three things:

1. Keep type_safe as a library for type safe programming (only)
2. Put part of it into Boost.
3. Do some breaking changes to allow better vocabulary types.

Please let me know what you think of this plan.

[rollbear]

I think it's a good idea to split the type safe stuff from the vocabulary types. I also think it's a good idea to use the opportunity to make breaking changes, since you'll effectively introduce two new libraries that no one depends on.

I don't really have an opinion about boost.

[robertramey]

"Thank you all for making this my most popular project with tons of daily clones!"

Where do you get this statistic?

[neithernut]

Where do you get this statistic?

@robertramey the "Insights" tab of a repo contains a section "Traffic" which is only visible to the owner and maintainers.

[b-schoen]

+1 for Boost! In larger projects it’s much easier to argue for strong types if there’s a small, convenient boost library for that purpose. IME the alternatives of writing + maintaining your own (or wrapping Boost Units + Boost Operators) are a much harder sell.

I think that given how many projects made use of @robertramey’s BOOST_STRONG_TYPEDEF, it seems like there’s probably a number of projects that would appreciate / use a small “strong typedef” library in boost.

@robertramey Has your thinking on the use for a “strong typedef” library in Boost changed since the conversation here?

[tavi-cacina]

I don't think many people actually use the type safe building blocks other than the strong typedefs facility.

I wanted a std::variant to hold a mix of bool, const char*, intXX_t, float, double etc. enforcing the right type straight ahead. The default primitive types are bad for this because they convert too easy and you get the wrong type where you do not expect. Your type_safe variants for bool and numbers are quite handy to use instead.

If you just want improved integer types there are better and more advanced libraries.

Yeah, there you have a point, I just watched the presentation of safe_numerics from Robert Ramey(https://youtu.be/93Cjg42bGEw?t=2435). I'll have to check it out.

[rolandschulz]

1. The strong typedefs library will be fully compatible, it is just the strong_typedefs.hpp header split into multiple files and with some more operations.

For integration a single header is nice. Would be nice to keep this at as an option.

[robertramey]

Has your thinking on the use for a “strong typedef” library in Boost changed since the conversation here?

No. I've had a lot of interest in the best way to use the C++ type system to enforce program correctness. I spent a fair amount of time on this and my efforts resulted in a talk for CPPCon on the subject (https://www.youtube.com/watch?v=632a-DMM5J0&t=1s). But I as not able to develop the facility that I originally hoped for - maybe some day. In the mean time I got enthralled in a related project - Safe Numerics (https://github.com/boostorg/safe_numerics) . This started out as simple idea but morphed into something much more elaborate and ambitious. It's been accepted into boost, I think it's very useful, but I'm still making some final enhancements.

I think there is some overlap with foonathan's library here. But I see them as quite different in scale, breadth and approach and can easily see where one would prefer on but not the other depending on the use case. I think this library would be a great addition to boost. I encourage you to fill out a page in the boost library incubator (www.blincubator.com) - my other quixotic quest - and post RFQ on the Boost Developer's mailing list. Also I think your library would be a good candidate for a conference (C++Now?) talk - if you haven't made one already.

[sgf]

how about let it became a BCL(basic class library)
for example: integer
add type_safe::integer<int>::MinValue and type_safe::integer<int>::MaxValue to the type,
add |,&,<<,>>,^ operators