[GSoC, MPL11] Community probe

older
[thread] shared_spinlock_t idea...

Louis Dionne

22 Apr 2014 22 Apr '14

2:09 p.m.

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

Show replies by date

Robert Jones

22 Apr 22 Apr

2:30 p.m.

On 22 April 2014 15:09, Louis Dionne wrote:

...

Dear Boost,

As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).

Apologies if I'm a little late to the discussion, but could you summarize in few sentences to objective of the TMP library, particularly with respect to extending/enhancing/correcting the MPL? Thx. Rob.

Robert Jones

3 p.m.

On 22 April 2014 15:30, Robert Jones wrote:

...

Apologies if I'm a little late to the discussion, but could you summarize in few sentences to objective of the TMP library, particularly with respect to extending/enhancing/correcting the MPL?

Thx. Rob.

Ok, I've found the other post now, sorry for the noise.

Edward Diener

7:55 p.m.

On 4/22/2014 10:09 AM, Louis Dionne wrote:

...

Dear Boost,

As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).

I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.

COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:

(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.

I do not think you must strive for perfect backward compatibility. But if you can provide an easy interoperation in as many places as possible that would be helpful. In particular, however, do not change a better design, when you have one, just to provide a means of backward compatibility.

...

(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.

If one understands the MPL ( no easy initial task ) it should be fairly easy to understand whatever your library's different idioms might be. So I do not think you should worry about the learning curve but rather just document your library as thoroughly as possible. At the level of the MPL, and template metaprogramming in general, a C++ programmer has to be good enough technically that he will understand your library if it is documented well. Whatever is not understood will be asked about when your library is reviewed, and that feedback will enable you to improve any documentation which may be found wanting.

Vicente J. Botet Escriba

9:33 p.m.

Le 22/04/14 16:09, Louis Dionne a écrit :

...

Dear Boost,

As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).

I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.

COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:

(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.

(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.

Please get involved by posting constructive material.

Hi, I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it. Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal. What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard. Best, Vicente

Roland Bock

23 Apr 23 Apr

7:17 a.m.

...

Le 22/04/14 16:09, Louis Dionne a écrit :

...
Dear Boost,

As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).

I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.

COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:

(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.

(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.

Please get involved by posting constructive material.

Hi,

I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it.

Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal.

What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard. I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become

On 2014-04-22 23:33, Vicente J. Botet Escriba wrote: the standard). That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past. Best regards, Roland

Louis Dionne

29 Apr 29 Apr

9:42 p.m.

Roland Bock writes:

...

I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become the standard).

By any chance, would the type set implementation happen to be public? I know of a couple different ways to implement those, but it's always good to see what others have done.

...

That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past.

As I currently view things, C++14 won't be such a game changer wrt TMP, but I must look into Concepts Lite more seriously before that's definitive. See my answer to Gonzalo for more on that. TYVM for your input, Louis

Gonzalo Brito Gadeschi

30 Apr 30 Apr

8:19 a.m.

...

Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations?

It has been mostly about manipulating values of a literal type and tuples. I'm still new to these kind of situations but I can see myself in the future preferring to use a std::tuple as a type vector (ignoring the values) and performing transformations inside a constexpr function using a Boost.Fusion-like library and then just decltype the result to get the type. Relaxed constexpr and automatic type deduction for normal functions makes this approach straightforward. To get the point across, this is how the machinery and the usage _could_ look like: /// Quote: template