in_place signatures seems wrong

[viboes]

The signatures of this class and functions seems wrong.

struct in_place_t {};
template <std::size_t I>
in_place_t in_place(unspecified<I>);
template <class T>
in_place_t in_place(unspecified<T>);

There is a parameter to in_place, but elsewhere there is no argument passed.

How in_place_t can remember the Ior the T?

BTW, where in_place_tis used?

[K-ballo]

The signatures are fine. Here are their definitions, with unspecified replaced by the real ugly types: https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/in_place.hpp#L22

The intended use is in_place<0>, not in_place<0>(). An in-place tag expression like in_place<0> has a type of in_place_t (&)(unspecified<0>), which decays to a function pointer in_place_t (*)(unspecified<0>). That is how the discriminator gets carried over to variant constructors.

The in_place_t tag is used to identify in-place tag expressions. It could just as well be a detail by sprinkling some more unspecifieds. I'll have to think about that possibility, but I am not entirely convinced yet. The whole in-place tag mechanism is in need of a thorough revision, beyond variant's use case.

[viboes]

I missed the nuance. It is however troubling that the unspecified<I>in in_place and the one in the variant members is not the same.

Why do you prefer to use functions instead of types and values?

[K-ballo]

It is however troubling that the unspecified in in_place and the one in the variant members is not the same.

Well, those are different kinds of unspecified :) The ones in the constructor, however, are not at all clear in that they are doing in-place construction. I will have to think of a way to improve that, without exposing the user to the ugly details.

Why do you prefer to use functions instead of types and values?

I don't, those are types and values. I prefer using that kind of types and values for these tags because it is the only kind that can be overloaded, and can support both type and non-type template arguments. It gives me an edge (in C++98) that not even variable templates (C++14) have.

Consider:

variant<int, ...> v1{in_place<int>, 42};
variant<int, ...> v2{in_place<0>, 42};
optional<int> o1{in_place<>, 42};
yourtype<...> yt1{in_place<forever, 21, true>, 42};

versus:

variant<int, ...> v1{emplaced_type<int>, 42};
variant<int, ...> v2{emplaced_index<0>, 42}; // reads like its constructing an index
optional<int> o1{in_place, 42};
yourtype<...> yt1{emplaced_your_own_tag<forever, 21, true>, 42};

It's just a hack to workaround a deficiency of the language, but it comes with its own deficiencies too (e.g., possibility of clashes, constructors forced to be templates as otherwise implicit conversions happen and you'd happily take a nullptr for it, etc). I have to make a thorough review on the mechanism itself, as its own thing, and decide where to go with it. But time is lacking, and it is not a priority at the moment.

[viboes]

Thanks for the explanations. Wondering if you believe these kind of tags would be more appropriated for the standard and if you will propose them.

[K-ballo]

Wondering if you believe these kind of tags would be more appropriated for the standard and if you will propose them.

That would be the point of a thorough review of the mechanism. However, I don't have high hopes. We'd be better off if the language just had support for arbitrary template parameters.

[viboes]

Giovanni Pietro has commented to me that the function interface could accept 0, which is not desirable:(

[K-ballo]

Giovanni Pietro has commented to me that the function interface could accept 0, which is not desirable:(

I don't think it can, how would it deduce I or T from 0 or any other null pointer? That problem does indeed exist for a signature without deduction though, which is the reason we didn't push this forward for optional.

[viboes]

Oh, I see where is the problem now:(

Muchas gracias

[K-ballo]

We can take one from optional's book and fake constrain the constructor to avoid implicit conversions:

struct bar {
  template <typename T, typename = std::enable_if_t<std::is_same<T, in_place_t>{}>>
  bar(in_place_t(*)(T)){}
};

See live here

[K-ballo]

Actually, it would be much simpler to just use a function reference instead...

[viboes]

Thanks for looking for a solution. To be sure I understood. Would the following then be an acceptable proposal

struct in_place_t {};
constexpr in_place_t in_place(unspecified);
template <class ...T>;
constexpr in_place_t in_place(unspecified<T...>);
template <size N>;
constexpr in_place_t in_place(unspecified<N>);

and

    template <class T, class ...Args>
      optional::optional(in_place_t (&)(unspecified), Args&& ...);

    template <class T, class ...Args>
      any::any(in_place_t (&)(unspecified<T>), Args&& ...);

As the parameter of the function is unspecified, the user would be unable to define a function that matches the parameter (except by a hacker of course).

[K-ballo]

Would the following then be an acceptable proposal

Yes, that sounds fine to me. And let me add that I'm glad that you are pursuing this (so I won't have to :)). Let's continue the conversation over at viboes/std-make.