Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it more consistent if mp_for_each invokes functor with mp_identity<T>()? #23

Open
oliora opened this issue Jul 2, 2018 · 4 comments

Comments

@oliora
Copy link

oliora commented Jul 2, 2018

Currently, mp_for_each invokes f with T(). This adds a default-constructible requirement for type T which is not always feasible and also not very consistent with other parts of mp11 that never instantiate user-provided types. Should not mp_for_each invoke passed functor with mp_identity<T>() instead?

@oliora oliora changed the title Is not it more consistent if mp_for_each invokes functor with mp_identity<T>()? Is it more consistent if mp_for_each invokes functor with mp_identity<T>()? Jul 2, 2018
@pdimov
Copy link
Member

pdimov commented Jul 2, 2018

mp_identity is often what you want, but not always; when the list contains integral constants, you don't want them wrapped. I went back and forth on adding the mp_identity a few times and at the end decided not to. We could add mp_for_each_id<L> that does mp_for_each<mp_transform<mp_identity, L>> even though I don't mind spelling that out.

@oliora
Copy link
Author

oliora commented Jul 3, 2018

mp_for_each_identity<L> or .._id sounds good as well.

@HDembinski
Copy link

Just passing by with a comment: I slightly lean against adding mp_for_each_id because it is trivial to write, but I am in favour of explicitly pointing out the construction mp_for_each<mp_transform<mp_identity, L>> in an example in the documentation of mp_for_each.

@oliora
Copy link
Author

oliora commented May 13, 2019

I think, extending the documentation but no code changes is a good trade-off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants