Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?

Boost - Dev mailing list
I've been working on https://github.com/foonathan/type_safe for the past
20 months or so. What started as an experimenting ground for type safe
programming facilities quickly turned into a general mix bag of utilities.

However, it became my most popular project, so there is something in
there people find really useful. And with that multiple approached me
wanting to have it added to Boost, so here I am.

I do realize that not all of it is suited for Boost: some of it has
overlap with existing libraries (e.g. optional/variant), some of it has
better implementations elsewhere (e.g. improved integer types) and some
of it is to novel/experimental (e.g. stuff like constrained_type).

But there are some things that could be useful for Boost. I'm mainly
thinking of the strong typedef facility.

I plan on splitting the library up into multiple parts anyway (see also
https://github.com/foonathan/type_safe/issues/82), so please let me know
whether there is anything you'd like to see being prepared for Boost.

Thanks,
Jonathan

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?

Boost - Dev mailing list
Dear Jonathan,

> On 9. Jun 2018, at 20:51, Jonathan Müller via Boost <[hidden email]> wrote:
>
> I've been working on https://github.com/foonathan/type_safe for the past 20 months or so. What started as an experimenting ground for type safe programming facilities quickly turned into a general mix bag of utilities.
>
> However, it became my most popular project, so there is something in there people find really useful. And with that multiple approached me wanting to have it added to Boost, so here I am.

I read your blog post with interest. I like the idea of strong typedefs and am conceptually with you 100 %. It is sad that there is no support planned for strong typedefs in the core language.

So, this is great work and I think it would fit nicely into boost, but that's just my opinion.

> I do realize that not all of it is suited for Boost: some of it has overlap with existing libraries (e.g. optional/variant), some of it has better implementations elsewhere (e.g. improved integer types) and some of it is to novel/experimental (e.g. stuff like constrained_type).

> But there are some things that could be useful for Boost. I'm mainly thinking of the strong typedef facility.

Some quick remarks.

In addition to what you already mentioned, I think the scope of your project, more precisely that of type_safe::integer, touches that of Robert Ramey's safe_numerics. Maybe you want to check it out and/or get in touch with him.
https://github.com/robertramey/safe_numerics <https://github.com/robertramey/safe_numerics>

Boost has boost.operators for adding operators to custom types. It seems to be similar to what you implemented. The current maintainer of boost.operators, Daniel Frey, also has an new version of that library in the works, see
https://github.com/taocpp/operators <https://github.com/taocpp/operators>

> I plan on splitting the library up into multiple parts anyway (see also https://github.com/foonathan/type_safe/issues/82), so please let me know whether there is anything you'd like to see being prepared for Boost.

I hope the core devs will chime in and give you feedback.

I can say that there is a formal procedure to get new libraries added to boost, which is documented on the Boost webpage. It is a multi-step process and requires some reading. For starters, people here should express interest in your library. If initial interest is there, you would work on making sure that your library is compliant with Boost standards, e.g. compiles with boost.build, has documentation, is advertised on the Boost Incubator http://blincubator.com/, etc. Then you need to request a formal review, which will decide whether the lib will be accepted.

Best regards,
Hans


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9 June 2018 at 20:51, Jonathan Müller via Boost
<[hidden email]> wrote:
> I've been working on https://github.com/foonathan/type_safe for the past 20
> months or so. What started as an experimenting ground for type safe
> programming facilities quickly turned into a general mix bag of utilities.
>
> However, it became my most popular project, so there is something in there
> people find really useful. And with that multiple approached me wanting to
> have it added to Boost, so here I am.
>

I would be interested if it was available in boost, I definitely have
usage of several of the provided tools.

> I do realize that not all of it is suited for Boost: some of it has overlap
> with existing libraries (e.g. optional/variant), some of it has better
> implementations elsewhere (e.g. improved integer types) and some of it is to
> novel/experimental (e.g. stuff like constrained_type).
>
> But there are some things that could be useful for Boost. I'm mainly
> thinking of the strong typedef facility.
>

It wouldn't shock me to add alternatives into boost.
However I'm not totally sure where (in which library) they should be located.
Maybe just proposing first the whole package and seeing how others
suggest to relocate some parts is good enough.


> I plan on splitting the library up into multiple parts anyway (see also
> https://github.com/foonathan/type_safe/issues/82), so please let me know
> whether there is anything you'd like to see being prepared for Boost.
>

I'm very interested in the strong typedef facility in particular yes.
But from what I read on this library, it's easier to use if you also
have the other types relating to the native or vocabulary types.
So in my opinion it would be better to not separate them.

> Thanks,
> Jonathan
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost