boostorg
construct - template cannot be MoveConstructible
It is not clear from the description what would be the result of
auto x = construct<vector>()(1);
I have a make function that can also take a type-constructor so that we can
auto x = make<expected<_, error_code>>(1);
auto x = make<unique_ptr<_, MyDeleter>>()(1);
Of course, we need some kind of customization from the user.
template cannot be MoveConstructible
Well, the template itself cannot, but after the types are placed in the template, it must be MoveConstructible.
It is not clear from the description what would be the result of
It probably needs a better description for "it will deduce the parameters to the template". So this:
auto x = construct<vector>()(1);
Would be the equivalent to this:
auto x = vector<int>(1);
Because it deduces int from 1.
Of course, we need some kind of customization from the user.
Template aliases can be used for this.
Template aliases can be used for this.
Yes, but this mean one template for each E in expected<_,E>.
Yes, but this mean one template for each E in expected<_,E>.
No, template aliases can be defined at class scope.
Please could you show me the definition and the usage of such a nested alias for expected<_,E>, it seems to me that it is not very user friendly.
Something like this:
template<class E>
struct e
{
template<class T>
using apply = expected<T, E>;
};
auto x = make<e<error_code>::apply>(1);
Although it may not be quite as slick as the placeholder expressions, which is a cool idea, but its kind of beyond the scope of the library. Fit is a function library not a metaprogramming library. Do you agree?
I don't like this kind of e<error_code>::apply.
I prefer
template <class E>
struct expected<_, E>
{
template<class T>
using apply = expected<T, E>;
};
Now we can use expected<_, E> as a type constructor.
About function versus meta-programming library. I believe that we should use the paradigms that a more appropriated to a specific context to make the user code as friendly as possible.
What I proposing to you don't includes too much meta-programming.
An alternative solution is to define the make function only on type constructors and use lift/reverse_lift to move from a template to a type constructor.
auto x = make<reverse_lift<expected, E>>(1);
What I proposing to you don't includes too much meta-programming.
It is a quite bit of metaprogramming, not just internally, but the interface would need to provide these meta placeholders. That is beyond the scope of the Fit library.
I could provide instead a construct_meta that would construct the type from a metafunction class. Then the user could construct the type using placeholder expressions from their favorite metaprogramming library.
I don't believe construct_meta is the solution. IMHO, we need just a function that do whatever is needed.
BTW
auto x = construct<vector>()(1);
should not work as there is a vector<T> constructor
explicit vector (size_type n);
I don't believe construct_meta is the solution. IMHO, we need just a function that do whatever is needed.
I don't know what you mean. What should the solution be?
should not work as there is a vector<T> constructor
Nope construct<vector>() does not work. I don't see that as a problem. The template version should be used when you want to deduce the types of the template. The constructors of vector were not written that way. Instead, construct<vector<T>>() should be used.