Generalizing the equivalence of auto and template type deduction

[Andy Prowl]

Paragraph 7.1.6.4/7 [dcl.type.elab] specifies that a variable declaration using "auto" behaves pretty much (concerning type deduction) like a function template call with a fictitious argument, so the problem of determining the type of "i" below:

const auto &i = expr;

Is mechanically translated into the problem of determining the type of "u" below when calling "f(expr)":

template <class U> void f(const U& u);

Currently, the following declaration is not legal:

std::unique_ptr<auto> p = foo();

As far as I can tell, this is just one particular instance of the same problem. The type of "p" above would be the same as the type of the parameter "u" below when calling "f(foo())":

template <class U> void f(std::unique_ptr<U> u);

 
Do you think it makes sense to generalize the rule and allow initializations like the one above?

Of course this would then apply to generic lambdas as well, and to terse syntax for function templates introduced by Concepts Lite:

auto l = [] (std::unique_ptr<auto> p) { ... };

void foo(std::vector<auto> const& v) { ... }

Kind regards,

Andy

[Ville Voutilainen]

On 1 October 2014 21:43, Andy Prowl <andy....@gmail.com> wrote:
> Currently, the following declaration is not legal:
>
> std::unique_ptr<auto> p = foo();
>
> As far as I can tell, this is just one particular instance of the same
> problem. The type of "p" above would be the same as the type of the
> parameter "u" below when calling "f(foo())":
>
> template <class U> void f(std::unique_ptr<U> u);
>
> Do you think it makes sense to generalize the rule and allow initializations
> like the one above?

Yes, I think it would. Do remember, though, that if we allow, say

pair<auto, auto> x = foo();

it's somewhat likely that someone somewhere will ask "how do I express a pair
where the types must not be the same?"

[Andy Prowl]

Good point, I don't have an answer to that. Do you think it's a blocking problem?

Andy

[Andy Prowl]

Actually, wouldn't it be enough to add a static_assert after the declaration?

pair<auto, auto> x = foo();

static_assert(decltype(x.first) != decltype(x.second), "Error");

Andy

[Andy Prowl]

Err, pardon:

static_assert(!std::is_same<decltype(x.first), decltype(x.second)>(), "Error");

Andy

[George Makrydakis]

To do that, you should expand 'auto' semantics to allow parameter type identifiers to be explicitly specified, instead of being implicit (plain auto). Which just leads you to using template parameters as an already existing syntax. Also remember that identifiers declared with 'auto' refer to values. So you can't do what Ville said without messing auto, seriously.

[George Makrydakis]

You are then unable to provide a match for your proposed std::pair<auto,auto> in a function type signature, function template overload, class template partial specialization for where different types are required, without making this a 'catch-all' pattern in a deducible context of a template parameter list. Therefore, because of this implicit assumption, you are continuously forced to use sfinae (and expand the rules for it) every time you'd use such syntax.

Consider also interaction with concepts and variadics. Not a pretty or unambiguous sight.

[Andy Prowl]

George,

I'm not sure what your point is. Why doesn't the static_assert() solve Ville's puzzle? Why is it necessary to refer to parameter type identifiers explicitly? Also, what do you mean by "identifiers declared with 'auto' refers to values"?

Kind regards,

Andrea

[Bengt Gustafsson]

I think Ville's point is that in keeping with:

auto a = 3, b = 4.5;  // error or b is an int...

auto in both positions must "evaluate" to the same type. I think this definition was a mistake in a variable declaration and also in this case. In the variable declaration case we're stuck where we are but in this new

pair<auto, auto> case  I don't see why we would have to force both instances of the word 'auto' to evaluate to the same type. The simple and understandable rule would be "each time you type the word auto it means

some type". Thus in a multi-variable declaration their base type must be the same, while in this case (with two type ins of auto) they can be different.

Looking back at the initial example I need reassuring:

I was assuming the intention was that foo() returns a U* which is to be captured in a unique_ptr<U>. If so, can the fictitous function really deduce U from that declaration if u is a U*? If the intention is that foo() already returns a unique_ptr<U> in the first place I don't see the advantage over

just writing:

auto p = foo();

in this case p is deduced to be a unique_ptr<U> anyway, doesn't it? In none of the cases you can easily access the type U from p using decltype, if that was the ultimate goal.

[Andy Prowl]

Hi Bengt,

I think you misunderstood Ville's point. His puzzle was: is there a way to specify that the two "auto"s in "pair<auto, auto>" *must* resolve to *different* types? My answer to that was the static_assert().

Concerning foo(), it cannot return a raw pointer: the constructor of unique_ptr<T> taking a T* is explicit, wouldn't work for copy-initialization. The intention indeed was to have foo() return a unique_ptr<T>. Whether or not it makes sense to write "unique_ptr<auto> p = foo()" instead of "auto p = foo()" is perhaps a matter of style or guidelines, and it depends on how much you want to commit to a type or how much is it OK for you to deduce anything at tall.

Other, more meaningful examples than the one with unique_ptr may exist (consider also with generic lambdas or terse function template syntax a la Concepts Lite). But at a language level, since the parallel between auto and template type deduction was drawn, I do not see it should only go half way.

Kind regards,

Andy

[George Makrydakis]

On 10/01/2014 10:48 PM, Andy Prowl wrote:

George,

I'm not sure what your point is. Why doesn't the static_assert() solve Ville's puzzle? Why is it necessary to refer to parameter type identifiers explicitly? Also, what do you mean by "identifiers declared with 'auto' refers to values"?

I never implied that your static_assert example would not work, I am saying that it may lead to more elaborate syntax for being able to use the proposed std::pair<auto,auto> (for example), while it could break once more complex scenarios of use are at hand.

When we write:

auto x = 1;

We use auto to magically specify the type of identifier x (which is our variable). In the standard, auto is a specifier, while the terms simple-type-specifier and typename-specifier are used as well. Referring to 14.6.3 for typename in N3690 (C++14 working draft) for use in templates.

Now, let's see how we solve Ville's problem, using a couple of examples (std::enable_if_t is C++14):

template<typename A, typename B>
std::enable_if_t<!std::is_same<A,B>::value, void>
function(std::pair<A,B>)
{}

template<typename T>
void fun(std::pair<T,T>) {}
 
template<typename A, typename B>
void fun (std::pair<A,B>)
{}

I think it is obvious that there is a notational advantage here because the typename specifier is accompanied by identifiers (A,B,T) which allow us to exploit the function template overloads and partial ordering to solve this problem. Now, if I consider your solution, I end up having an interesting problem:

void function(std::pair<auto,auto> x)
{}

It quickly becomes evident that since there is no template parameter list and no identifiers used for the parameters involved after the auto specifier, we cannot perform any sfinae until after x has been declared in the argument list of 'function'. This means that you cannot use sfinae easily on the return type for example. You will also have to resort to auto function -> decltype(...) tricks, provided they are applicable.

So it would be interesting to provide easier type inference through 'auto' within the argument list of 'function', but that cannot happen smoothly, even if you add an identifier after the auto specifier.

void function(std::pair<auto A,auto B> x)
{}

This would also be wrong. If you wanted to sfinae (for example) you would still be forced to use auto function -> decltype(...) or further mess with the type signature, leading to increasing verbosity. Now, sfinae aside, you also cannot use either of (A,B) as return types since there has been no declaration of them prior to the argument list of 'function'. So you are really not helping out the cause towards shorter and crystal clear syntax.

One of course can be inspired by C++14 generic lambdas as well as plain 'auto' or decltype(auto) and attempt this as a proposal:

decltype(auto) function(std::pair<auto A,auto B> x)
{ return x.first; }

Here, auto simply starts doing too many things through implication, to the point of becoming another language within the compiler. And you still can't use (A) as a return type in the seamless way you would do with regular templates.

Overall, I think that this use of auto can be quite problematic within a template parameter list that can have non-type parameters, type parameters and template-type parameters.

Now, imagine variadics and concepts coming together with this 'auto'. You seem to be using auto here as a shorthand for bypassing 'typename' and the declaration of the template parameter list. That is why you are facing these problems.

I therefore think that such an extension of 'auto' would need considerable work to become non-blocking/breaking or at least superior to the template notation we already have, besides "requiring different types". So Ville's problem is just one of the issues you would have to handle, but not the most complicated one of them.

Just a few thoughts,

Regards,

George

[Andy Prowl]

OK, but don't we have the same problem today with generic lambdas? How do we specify that "a" and "b" in the following lambda should have different types, or the same types, or related types etc.?

auto l = [] (auto a, auto b) { };

Unless I'm missing something, the notational problem you are mentioning is present already today, and whether it is necessary to address it or not, it's an orthogonal issue to the one of generalizing the parallel between auto and template type deduction.

Am I missing something?

Kind regards,

Andrea

[George Makrydakis]

In fact, I did mention in my previous email that you can be inspired by generic C++14 lambdas for this; but such constructs by far, are not covering the issues arising when all kinds of parameters are involved,  aka non-type, type, template-type as well as partial ordering matching. Not to mention the combination with variadics.

In essence, such proposed of auto for completely substituting the concept of a template parameter list, is problematic for doing any sort of bounded polymorphism (one of these cases is Ville's problem), while for that purpose concepts could be combined to offer a better solution.

But then again, concepts are tied to template parameter and argument lists. Which means that in this context, that way of handling parametric polymorphism in c++ with ’auto’ everywhere needs to be magically shoehorned into concepts (somehow) so that you can avoid seeing 'template'.

Of course, you could make a proposal for turning 'auto'-ness into something that works like Hindley–Milner type inference for C++, getting rid of every kind of type "cue",  but that is neither the direction c++ is going towards right now nor would it be a small change otherwise.

For the record, the incompleteness of 'auto' in C++11 led to problems with expression templates. Automatic type inference within the rules that we have can be very, very tricky to expand without breaking code using such rules.

Again, just some thoughts; in conclusion, such use of 'auto' can be problematic unless it is very constrained by context to serve a shorthand for type parameters over cases where bounded polymorphism is not actually required. Generic C++14 lambdas were such a case, but they do not have the complexities of template parameter and argument lists.

Regards,

George

[Tomasz]

I think that the syntax proposed in N3878 resovles the problem:
 pair<auto{T}, T> x = foo();

[Tomasz]

I assuming that the every instance of auto placeholder is treated as separate type parameter for equivalent function template, so it will consitient with the way we thread auto in parameters of generic lambda. And to have same type we use placholder{T} syntax. This may also be extented to Concepts, like pair<Iterator{I}, I> p = std::equal_range(...).

[George Makrydakis]

In your formulation, the type is in the end the same in both the first and the second type in std::pair, T, therefore it does not give you a guarantee that these two are different unless you use additional syntax for constraining the second.

In your example there is no such constraint or implication of it; and even if placed there, it still does not have a real notational advantage over regular templates. Not an easy path when you already have partial ordering and overloads doing the job for you in this particular case. What if more than two are involved?

Also proves that additional syntax is required to disambiguate for uses of auto within parameter lists for being a typename substitute or even a template-type parameter one.

Regards,

George

[George Makrydakis]

Under this assumption, as stated in previous emails, you would still have no way to explicitly specify (or sfinae) an instantiated class template type related to T given that no T identifier exists yet. See auto -> decltype syntax; decltype(auto) is also unconstrained as to T. So it is a very limiting shorthand respect to the canonical way of doing things.

[Ville Voutilainen]

Yes.

Also note that what you suggest is already in Concepts, it supports things
like
Pair<auto, auto> p = make_pair(0, 'a'); // Ok

What it doesn't yet support is using Concepts in variable declarations:
"Unlike auto, a constrained-type-specifier cannot be used in the type of
a variable declaration or the return type of a function.", but I'm sure that
extension will be considered in due course.

[George Makrydakis]

It is not just variable declarations though that suffer.

Of course, we already analyzed this solution, but do show how we can use std::pair<auto,auto> in an argument list for specifying the two types must be different:

void fun(std::pair<auto, auto>) {}

Without resorting to multiple sfinae hacks like Andy is proposing; newer constructs should not lead to more complex code over the canonical solution with templates and partial ordering.

Also, return type sfinae manipulation is impaired to having to use auto -> decltype(...) constructs. In essence, verbosity.

As you said, it will be done in due course I guess. Perhaps Andy should consider this case though.

[Ville Voutilainen]

On 2 October 2014 10:30, George Makrydakis <irreq...@gmail.com> wrote:
> It is not just variable declarations though that suffer.
>
> Of course, we already analyzed this solution, but do show how we can use
> std::pair<auto,auto> in an argument list for specifying the two types must
> be different:
>
> void fun(std::pair<auto, auto>) {}

I don't see the point. If you care about the types and want to constrain them
to be different, and a constrained template does that easier than auto, use
a constrained template.

[George Makrydakis]

In essence then, we are in agreement; you do not gain any notational advantage for when types are different with the proposed 'auto' syntax extension. I am saying that the canonical way already covers all corners. Nothing more.

[Tomasz]

My proposal is that every use of placholder (today we have only auto, but concept name would be a possible extension) would introduce separate typename, so:
std::pair<auto, auto> p = f();

Would use equivalent deduction as:
template<typename T1, typename T2>
void foo(std::pair<T1, T2>);

And two different types can be deduced. To achieve the pair of the same types I would use syntax proposed in http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf, that allow us to introduce indentyfier for a type deduced from placeholder. So if we want to have pair of same types we would write:
std::pair<auto{T}, T> p = f();
Which will use deduction as:
template<typename T>
void foo(std::pair<T,T>);

We will benefit from being able to refer to type T without use of std::decay_t<decltype(p)>::first_type and have same treatment of multiple placeholders in every context.

This syntaxt can be extended to use concept names as placeholders:
std::pair<Iterator, Iterator> f = ...;
Will allow pair of two interator with unrelated types that fullfills iterator concept. To have pair of iterator with same type only, we could write
std::pair<Iterator{I}, I> f = ...;

[George Makrydakis]

Again, this has already been discussed. See previous emails on this thread on why you would have problems with that as it is. You do not even gain total equivalence over canonical template syntax, if that is your goal.

[Ville Voutilainen]

On 2 October 2014 11:43, Tomasz <toma...@gmail.com> wrote:
> My proposal is that every use of placholder (today we have only auto, but
> concept name would be a possible extension) would introduce separate
> typename, so:
> std::pair<auto, auto> p = f();
>
> Would use equivalent deduction as:
> template<typename T1, typename T2>
> void foo(std::pair<T1, T2>);

That's already how it works.

[Ville Voutilainen]

On 2 October 2014 10:59, George Makrydakis <irreq...@gmail.com> wrote:
> In essence then, we are in agreement; you do not gain any notational
> advantage for when types are different with the proposed 'auto' syntax
> extension. I am saying that the canonical way already covers all corners.
> Nothing more.

It's not about whether the types are different, it's about whether I
care that the
types are different. If I don't care, or the differences are between
whether something
is or is not a reference or a pointer, auto gives me notational convenience over
the "canonical way".

At any rate, what the original message asks for is already part of the
Concepts TS
proposal.

[Tomasz]

Sorry, I misunderstood your point.

I think with use of concepts as placeholders we can still require different type. Let assume that we have concept Different Type<A,B>, could probably write:
std::pair<auto{T}, Different Type<T>> f =..;
but I would say that the programmer should specify types explicitly in that case.

Also for the examples were pair<auto, auto> used in the function: We already have a longer notation that would allow us to a specify constrained case, so there is not need to cover that in shorthand notation.

[Ville Voutilainen]

On 2 October 2014 12:29, Tomasz <toma...@gmail.com> wrote:
> Sorry, I misunderstood your point.
>
> I think with use of concepts as placeholders we can still require different
> type. Let assume that we have concept Different Type<A,B>, could probably
> write:
> std::pair<auto{T}, Different Type<T>> f =..;
> but I would say that the programmer should specify types explicitly in that
> case.

Fully agreed.

> Also for the examples were pair<auto, auto> used in the function: We already
> have a longer notation that would allow us to a specify constrained case, so
> there is not need to cover that in shorthand notation.

Again agreed. And you can specify the constraints by specifying them
on decltype(foo.first)
and decltype(foo.second), if you really really want.

[George Makrydakis]

Never implied that it wasn't in. But any variation requiring bounded polymorphism (one case is caring about different types) fails to do so without resorting to SFINAE once that use of auto kicks in. And even then, trivial return type constraints become impossible without complex SFINAE since the identifiers ate declared in the argument list.

It is interesting to note that Sutton said that should any kind of template meta-programming be necessary for doing what concepts are doing, it would make concepts a failed experiment. I would not be so harsh, but in that use of 'auto' you just end up using tricks like Andy.

In essence, you cannot avoid using a template parameter list through such auto use unless all is unboundedly polymorphic, and concepts with auto are definitely not Hindley-Milner.

[Ville Voutilainen]

On 2 October 2014 12:37, George Makrydakis <irreq...@gmail.com> wrote:
> Never implied that it wasn't in. But any variation requiring bounded
> polymorphism (one case is caring about different types) fails to do so
> without resorting to SFINAE once that use of auto kicks in. And even then,

Well, that's not what the auto syntax is for, so you get what you ask for.
As I said, if you need a constrained template, write a constrained template,
instead of constraining auto (which you can still do if you insist).

> In essence, you cannot avoid using a template parameter list through such
> auto use unless all is unboundedly polymorphic, and concepts with auto are
> definitely not Hindley-Milner.

I don't think they are intended to be. Feel free to discuss that with
the concepts
designers. This presentation might be interesting:
https://www.youtube.com/watch?v=vtUQY2dw0mI&list=PL_AKIMJc4roXG7rOmqsb_wDG1btCzhS8F&index=2

I think we're veering off from the thread, as well.

[George Makrydakis]

Which is what has already been said, but you ignored it. The notation gets longer and weirder with such placeholders, not offering any real no rational advantage. You are only exchanging 'typename' with auto plus decltype for constraining even in the most trivial case.

[Ville Voutilainen]

On 2 October 2014 12:43, George Makrydakis <irreq...@gmail.com> wrote:
> Which is what has already been said, but you ignored it. The notation gets
> longer and weirder with such placeholders, not offering any real no rational
> advantage. You are only exchanging 'typename' with auto plus decltype for
> constraining even in the most trivial case.

No we are not, because we don't write auto when we want to constrain the type.
The notation doesn't get longer and weirder, and it's shorter because we
don't need a template header for the generic function we write.

[George Makrydakis]

I agree that this is not what concepts are designed for, I am only saying that people like Andy are demonstrating a trend in expanding the semantics of type inference that is problematic over already existing practice.

As for the concepts group, whose public work I am aware of, I do not believe that they would consider all outsider opinions on this matter, even if they are right. Anything not taking place in public is not worth it.

[George Makrydakis]

If you do not care about constraints yes, but Andy's decltype use should warn of something.

It gets weirder when you have to use decltype tricks like Andy did. Therefore, such use of auto is very restrictive for only some cases of unbound polymorphism; it does not offer a viable substitution for template parameter lists in the general case. See previous posts on this. It fitted C++14 genetic lambdas because of the constraints lambdas have themselves.

I am not saying it is totally useless, I am saying that it much, much, much less useful once decltype tricks have to enter the scene. Imagine having to read code using such overloads submitting to partial ordering.

In essence, it encourages metaprogrammimg boilerplate where there isn't need for.

[Andy Prowl]

At any rate, what the original message asks for is already part of the Concepts TS proposal.

That would be good news, but are you sure this is the case? Looking at N3929, it seems to me that "auto" is only supported as a simple type specifier. So for example this would be supported:

void foo(auto x) { }

But not this (as far as I can see):

void foo(std::vector<auto> x);

Same thing for variable declarations. Now I hope you will prove me wrong, so we can close this thread :)

Kind regards,

Andy

[Ville Voutilainen]

On 2 October 2014 13:04, George Makrydakis <irreq...@gmail.com> wrote:
> I am not saying it is totally useless, I am saying that it much, much, much
> less useful once decltype tricks have to enter the scene. Imagine having to
> read code using such overloads submitting to partial ordering.
> In essence, it encourages metaprogrammimg boilerplate where there isn't need
> for.

I don't see how it encourages such boilerplate when there are
solutions available
which don't require that boilerplate. If I use auto, I don't care
about the constraints.
If I care about the constraints, I don't use auto. None of this makes
the auto itself
less useful, since it's a notational shorthand for the unconstrained case.

[Ville Voutilainen]

On 2 October 2014 13:11, Andy Prowl <andy....@gmail.com> wrote:
>> At any rate, what the original message asks for is already part of the
>> Concepts TS proposal.
> That would be good news, but are you sure this is the case? Looking at

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft.

> Same thing for variable declarations. Now I hope you will prove me wrong, so
> we can close this thread :)

I think we should close this thread. :)

[Andy Prowl]

George,

I'm not sure about what trend "people like me" are demonstrating, but honestly I have troubles understanding most of the concerns you are expressing. In particular, it seems to me that they are pretty much orthogonal to my proposal.

For example, already today there are situations where using trailing return type syntax is necessary, depending on what we want to do. And even with regular template syntax, you won't be able to avoid SFINAE for e.g. expressing the fact that two template type arguments must be different.

Regarding your concerns on the original example of std::pair<auto, auto>, my proposal doesn't really change anything: if you wanted to express the constraint that the types must be different *today*, you would still have to resort to static assertions and decltype, so I believe what I'm after doesn't make the situation worse. 

Kind regards,

Andrea

[Andy Prowl]

On Thursday, October 2, 2014 12:13:41 PM UTC+2, Ville Voutilainen wrote:

On 2 October 2014 13:11, Andy Prowl <andy....@gmail.com> wrote:
>> At any rate, what the original message asks for is already part of the
>> Concepts TS proposal.
> That would be good news, but are you sure this is the case? Looking at

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft.

Awesome, thanks for sharing that.
 

> Same thing for variable declarations. Now I hope you will prove me wrong, so
> we can close this thread :)

I think we should close this thread. :)

Agreed. 

Kind regards,

Andy

[George Makrydakis]

I consider the thread closed, but given that Andy tries to make a point, I will just show the flaws in that reasoning for posterity.

On 10/02/2014 01:17 PM, Andy Prowl wrote:

George,

I'm not sure about what trend "people like me" are demonstrating, but honestly I have troubles understanding most of the concerns you are expressing. In particular, it seems to me that they are pretty much orthogonal to my proposal.

Andy,

The double quoted extract in context is implicitly refering to people who enjoy automatic type inference and is not intended as a discrediting subterfuge, which is quite usual by some members of this list. I consider myself part of the people who enjoy automatic type inference, to some limited extent.

For example, already today there are situations where using trailing return type syntax is necessary, depending on what we want to do. And even with regular template syntax, you won't be able to avoid SFINAE for e.g. expressing the fact that two template type arguments must be different.

Incorrect. The following snippet, works even with C++98/03 and I am pretty much avoiding everything fancy, I just follow simple rules the language has since time immemorial with regular function template overload syntax and ordering tricks:

#include <cstdio>
#include <utility>

template<typename A, typename B>
void function(std::pair<A,B>) { printf("different\n"); }

template<typename A>
void function(std::pair<A,A>) { printf("same\n"); }

int main() {
    function(std::pair<int,long>());
    function(std::pair<int,int>());
    return 0;
}

So, I can express the notion of two different types substituting two different type parameter identifiers in the argument list because the declarative template parameter list is disjoint from it. Now if I want to write less using C++14 and limit to just one function (you seem to have missed the previous email on this, so I have to repeat it) then yes, I do have to use SFINAE through a <type_traits> library feature:

template<typename A, typename B>
std::enable_if_t<!std::is_same<A,B>::value,void>
function(std::pair<A,B>) { printf("different\n"); }

Of course, you are aware that std::enable_if and std::enable_if_t are nothing but embelishments of techniques that are valid in C++98/03 and have simply been granted library implementation status in C++11. The introduction of template aliases is extremely important in shortening the code we require for such constructs, but I digress. Let's try this with C++11's static_assert and avoid such SFINAE use:

template<typename A, typename B>
void function(std::pair<A,B>) {
    static_assert(!std::is_same<A,B>::value, "they cannot be the same!");
    printf("different\n");
}

That is more like you do in the std::pair<auto,auto> static warning. You of course cannot do "trailing type sfinae" with std::pair<auto,auto>, you still need to use auto -> decltype(...) and the amount of trickery you'd have to put into that second decltype() in order to do anything meaningful is what is leading to increased boilerplate. You do not deny that of course, as per your examples. Take note that in your examples, you did not use N3878 (still a work in progress by the C++ sages I presume), neither did Tomasz who mentioned the paper, but let's take a go at it with 'auto{X}' there (page 4 of 6, inspired by 2.3):

void function(std::pair<auto{A}, auto{B}>) {
    static_assert(!std::is_same<A,B>::value, "they cannot be the same!");
    printf("different\n");
}

This validates what I said in a previous email on this thread, that without additional identifiers, std::pair<auto,auto> is rather pointless for bounded polymorphism. In order to disambiguate with the use of auto elsewhere, the authors are forced to use curly braces as additional syntax.

Essentially, that is what all of you are trying to say if we take N3878 in consideration. Not a problem, but... still no trailing sfinae and no easy way to do some real work within that argument list without complicating it to "template-header" level. Worse, it can mess the type signature. The merit of a separate template parameter and argument list is that we have a separation of concerns between what is our declarative intent and what we would like to do based on varying input of parameter types.

I am still saying that such tendency to promote auto's use is not going to override the actual merit of having a declarating template parameter list (some people call this template header, I won't). It also does not cover / address issues with non-type and template-type parameters coherently yet. It is an unsolved problem until the C++ committee sages think of a way they can do it themselves, despite a solution can already be provided. Pretty much like why it took decades to get to 'concepts' in the form of predicates. All in due course as Ville says. Only that it is not the 80s anymore.

Regarding your concerns on the original example of std::pair<auto, auto>, my proposal doesn't really change anything: if you wanted to express the constraint that the types must be different *today*, you would still have to resort to static assertions and decltype, so I believe what I'm after doesn't make the situation worse.

I know that your proposal does not change anything - because per Ville's reference it does not add anything. Also the examples I have laid out show quite eloquently that you could express that types must be different yesterday. Ville rhetorically asked, in the context of your OP of how he would express the notion of two different types in that construct. Despite some people may take this personally, it is technically obvious that with 'auto' used that way we only have a pointless shorthand favoring latent typing (again...); canonical template notation is still superior in covering all cases, even when no SFINAE tricks are involved.

That does not mean we should not aim for better over the 'hated' template keyword, but we should not also hail something as an important improvement when it is evidently clear that it is not. Not your case, but I think most of the arguments in the list are kind of staged and rehearsed for supporting X over Y over non-really-technical reasons, demanding passive compliance.

Yes, we can now close this thread.

Regards,

George

[Вадим]

Ville, if this is accepted (as a part of Concepts or separately), will it facilitate the full prohibition of the auto deduction from initializer lists?

With `std::initializer_list<auto> a = {1, 2, 3, 4, 5};` there would be one less reason to keep copy initialization `auto a = {1, 2, 3, 4, 5};` deducing initializer list.

[Ville Voutilainen]

On 2 October 2014 17:26, Вадим <vadim.pet...@gmail.com> wrote:
> Ville, if this is accepted (as a part of Concepts or separately), will it
> facilitate the full prohibition of the auto deduction from initializer
> lists?
>
> With `std::initializer_list<auto> a = {1, 2, 3, 4, 5};` there would be one
> less reason to keep copy initialization `auto a = {1, 2, 3, 4, 5};` deducing
> initializer list.

I don't expect it will have that effect, since a majority of EWG voted
for keeping
the initializer_list deduction for auto = {...};
See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html

[Andy Prowl]

On Thursday, October 2, 2014 3:54:25 PM UTC+2, George Makrydakis wrote:

I consider the thread closed, but given that Andy tries to make a point, I will just show the flaws in that reasoning for posterity.

On 10/02/2014 01:17 PM, Andy Prowl wrote:

George,

I'm not sure about what trend "people like me" are demonstrating, but honestly I have troubles understanding most of the concerns you are expressing. In particular, it seems to me that they are pretty much orthogonal to my proposal.

Andy,

The double quoted extract in context is implicitly refering to people who enjoy automatic type inference and is not intended as a discrediting subterfuge, which is quite usual by some members of this list. I consider myself part of the people who enjoy automatic type inference, to some limited extent.

For example, already today there are situations where using trailing return type syntax is necessary, depending on what we want to do. And even with regular template syntax, you won't be able to avoid SFINAE for e.g. expressing the fact that two template type arguments must be different.

Incorrect. The following snippet, works even with C++98/03 and I am pretty much avoiding everything fancy, I just follow simple rules the language has since time immemorial with regular function template overload syntax and ordering tricks:

#include <cstdio>
#include <utility>

template<typename A, typename B>
void function(std::pair<A,B>) { printf("different\n"); }

template<typename A>
void function(std::pair<A,A>) { printf("same\n"); }

int main() {
    function(std::pair<int,long>());
    function(std::pair<int,int>());
    return 0;
}

OK, but why wouldn't the same technique work with auto?

void function(std::pair<auto, auto>) { printf("different\n"); }

template<typename A>
void function(std::pair<A, A>) { printf("same\n"); }

Regarding your concerns on the original example of std::pair<auto, auto>, my proposal doesn't really change anything: if you wanted to express the constraint that the types must be different *today*, you would still have to resort to static assertions and decltype, so I believe what I'm after doesn't make the situation worse.

I know that your proposal does not change anything - because per Ville's reference it does not add anything. Also the examples I have laid out show quite eloquently that you could express that types must be different yesterday. Ville rhetorically asked, in the context of your OP of how he would express the notion of two different types in that construct. Despite some people may take this personally, it is technically obvious that with 'auto' used that way we only have a pointless shorthand favoring latent typing (again...); canonical template notation is still superior in covering all cases, even when no SFINAE tricks are involved.

I don't understand why you say it doesn't add anything. It allows you writing "auto" where it was not previously allowed, without making the situation worse. If it didn't add anything, the Concepts TS would probably not bother allowing it. On a language level, it simply completes a parallel between auto type deduction and template type deduction which only went half-way before.

Yes, we can now close this thread.

Cool, we all agree :)

Thank you for your comments anyway,

Andy
 

[George Makrydakis]

On 10/02/2014 07:46 PM, Andy Prowl wrote:

OK, but why wouldn't the same technique work with auto?

void function(std::pair<auto, auto>) { printf("different\n"); }

template<typename A>
void function(std::pair<A, A>) { printf("same\n"); }

You'd have to introduce another, pretty weird rule for partially ordering the two syntaxes as well and you are resorting to using that 'hideous' template keyword everybody is scared of (kidding)! Ordering needs to be covered. Also, consider variadics please. I think that what they have as syntax in N3878 can be used for this, it is seamless despite its shortcommings in other areas (note, they don't have such an example, yet, only the auto{} syntax), as I said in a previous email:

void function(std::pair<auto{A}, auto

{B}>) {
    static_assert(!std::is_same<A,B>::value, "they cannot be the same!");
    printf("different\n");
}

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/yRhO-qeikZwJ

I don't understand why you say it doesn't add anything. It allows you writing "auto" where it was not previously allowed, without making the situation worse. If it didn't add anything, the Concepts TS would probably not bother allowing it. On a language level, it simply completes a parallel between auto type deduction and template type deduction which only went half-way before.

In a seriously friendly manner, I am just pointing out some details if you want to give notation that is superior to template parameter lists, because as it is, it is not a 1:1 correspondence for every scenario. Take it only as that. Also, do consider what Ville wrote about 'concepts' authors working on extending auto, you wouldn't like to waste your time for something they are doing secretly since they have more leverage, regardless of any actual worth of any argument they put through... Which is where "adds anything" really goes ;)

Yes, we can now close this thread.

Cool, we all agree :)

Thank you for your comments anyway,

Andy
 

Thank you for yours as well, it is a given! Good luck for your virtual concepts proposal as well.

Good luck,

George

[Ville Voutilainen]

On 2 October 2014 20:38, George Makrydakis <irreq...@gmail.com> wrote:
> OK, but why wouldn't the same technique work with auto?
>
> void function(std::pair<auto, auto>) { printf("different\n"); }
>
> template<typename A>
> void function(std::pair<A, A>) { printf("same\n"); }
>
>
>
> You'd have to introduce another, pretty weird rule for partially ordering

You don't have to introduce anything. The concepts proposal's working version
already includes a specification how such an abbreviated function translates
to a function template, and the partial ordering suggested by Andy
already works.

> as it is, it is not a 1:1 correspondence for every scenario. Take it only as
> that. Also, do consider what Ville wrote about 'concepts' authors working on
> extending auto, you wouldn't like to waste your time for something they are
> doing secretly since they have more leverage, regardless of any actual worth

"Secretly"? Does
https://github.com/cplusplus/concepts-ts/
perhaps not work for you?

[George Makrydakis]

On 10/02/2014 09:04 PM, Ville Voutilainen wrote:

On 2 October 2014 20:38, George Makrydakis <irreq...@gmail.com> wrote:

OK, but why wouldn't the same technique work with auto?

void function(std::pair<auto, auto>) { printf("different\n"); }

template<typename A>
void function(std::pair<A, A>) { printf("same\n"); }



You'd have to introduce another, pretty weird rule for partially ordering

You don't have to introduce anything. The concepts proposal's working version
already includes a specification how such an abbreviated function translates
to a function template, and the partial ordering suggested by Andy
already works.

The fact that they introduced it means that they took care of it. Also notice the example I made with their own syntax. Does your compiler also not requiring any changes for implementing that when ordering has to be taken care of? Seriously? Heh. As you wish. Let's see how it will work with template-type parameters and variadics; and reaching 1:1 correspondence with all that templates do.

as it is, it is not a 1:1 correspondence for every scenario. Take it only as
that. Also, do consider what Ville wrote about 'concepts' authors working on
extending auto, you wouldn't like to waste your time for something they are
doing secretly since they have more leverage, regardless of any actual worth

"Secretly"? Does
https://github.com/cplusplus/concepts-ts/
perhaps not work for you?

For informing you of your "not published yet" policy for things you guys limit access, this comes from your message Ville:

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft

Seriously, you cannot say that you put your private EWG mailing list archives there in github. And, I like you too Ville, but your EWG is a major stinker in some respects in the way it behaves. Perhaps they are good in others, but before calling out that thing "public" I suggest you get a good look on your private mailing lists and how you guys organize meetings. Let's not derail into offtopicness again.

What part of "Secretly" you did not get? Anyway, enjoy the upcoming meeting. It is a nice stage.

George

[Ville Voutilainen]

On 2 October 2014 21:43, George Makrydakis <irreq...@gmail.com> wrote:
> "Secretly"? Does
> https://github.com/cplusplus/concepts-ts/
> perhaps not work for you?
>
>
> For informing you of your "not published yet" policy for things you guys
> limit access, this comes from your message Ville:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J
>
> On 10/02/2014 01:13 PM, Ville Voutilainen wrote:
>
> Based on a very new working draft that is not yet published, yes, I am sure.
> I took the example I pasted from that draft

It so happens that that draft is apparently public, since the version
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.

Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.

You seem to be the last person to lecture about "derailing into
off-topicness", as far as I can see.

[George Makrydakis]

On 10/02/2014 09:58 PM, Ville Voutilainen wrote:

On 2 October 2014 21:43, George Makrydakis <irreq...@gmail.com> wrote:

"Secretly"? Does
https://github.com/cplusplus/concepts-ts/
perhaps not work for you?


For informing you of your "not published yet" policy for things you guys
limit access, this comes from your message Ville:

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft

It so happens that that draft is apparently public, since the version
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.

Exactly where I want you. You seem to be assuming that there is no "secret" work happening as the default, which is quite the opposite. That is the end-pit of concepts. Not the fountain. This is not the thread for starting a real hellfire of certain quite galant and generous EWG practices of which I do have first hand experience. You also are aware of how things are "delegated" aren't you. So let's leave it there as it is of little concern to "outsiders".

Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.

Here we go. Thanks for providing citable feedback on the fact that these public lists are only considered a gimmick and that things are decided in your private EWG quarters. As long as these lists provide you marketing pool to sell your "open" character, they serve their purpose. You do not really need the ideas presented by true outsiders here. You guys don't really have respect for all volunteers, just for your "volunteers" - and that is my first-hand experience.

You seem to be the last person to lecture about "derailing into
off-topicness", as far as I can see.

Everytime you will be defensive of current EWG practices with me, "you" will be getting your disarming reply, on-topic or off-topic given that "you" did not respect "your" rules when you had to. This has nothing to do with you as a person (you are an ok guy), but as an EWGer, you won't be able to defend those practices. Since all of you EWGers will be more careful from now on and follow your own rules, I think that something is gained for any contributors that may come. I gain zero out of this.

Other than that, again you are a valid technical commenter I respect on the things you really do know about. I will gladly accept to be proven wrong by you on a really technical subject. No point in continuing to go offtopic dear Ville. Let's close all of it here. The technical aspects in C++ are interesting, only that they are deeply poisoned by social manure and pomposity.

George

[Nevin Liber]

On 2 October 2014 15:55, George Makrydakis <irreq...@gmail.com> wrote:

On 10/02/2014 09:58 PM, Ville Voutilainen wrote:

On 2 October 2014 21:43, George Makrydakis <irreq...@gmail.com> wrote:

"Secretly"? Does
https://github.com/cplusplus/concepts-ts/
perhaps not work for you?


For informing you of your "not published yet" policy for things you guys
limit access, this comes from your message Ville:

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft

It so happens that that draft is apparently public, since the version
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.

Exactly where I want you. You seem to be assuming that there is no "secret" work happening as the default, which is quite the opposite.

Huh?

People work on papers.  They may or may not have a web cam pointed at their keyboards so you can watch them type.  They may or may not put them on public repos while they are working on them.  They may or may not send drafts to their friends.  They may or may not send drafts to the internal committee mailing lists.  They may or may not send drafts to this list.  At some point, if they wish to present it, they will get an N-number and it will be published as part of a mailing.

I don't see how any of that is secret.  That is just how people work, and different people work differently.

If you wanted to see the Concepts draft, all you had to do was ask how.  Instead, you chose to fan the flames by saying:

Also, do consider what Ville wrote about 'concepts' authors working on extending auto, you wouldn't like to waste your time for something they are doing secretly since they have more leverage, regardless of any actual worth of any argument they put through...

Was that really called for? 

 

That is the end-pit of concepts. Not the fountain. This is not the thread for starting a real hellfire of certain quite galant and generous EWG practices of which I do have first hand experience. You also are aware of how things are "delegated" aren't you. So let's leave it there as it is of little concern to "outsiders".

Then why do you keep bringing it up??

Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.

Here we go. Thanks for providing citable feedback on the fact that these public lists are only considered a gimmick and that things are decided in your private EWG quarters.

They aren't a gimmick.  In some sense, they are an experiment.  IMO, the signal to noise ratio is far lower here than on the internal committee lists.  For me, it isn't yet down to zero, which is why I still occasionally read it, rarely post to it, but am willing to put any drafts of papers I'm writing on it because I have gotten useful feedback in the past.  I have noticed that posting by committee members is way down from two years ago when this list was created.

 

As long as these lists provide you marketing pool to sell your "open" character, they serve their purpose. You do not really need the ideas presented by true outsiders here. You guys don't really have respect for all volunteers, just for your "volunteers" - and that is my first-hand experience.

Yes, you had a bad experience.  Life sucks sometimes.  As you keep telling us and everybody else, allowing you to present a paper that was not published in the mailing was a mistake.

Some of us who supported creating these lists in the first place did so because we thought that making it easier for people to have access to Committee members was a good thing.  Were we wrong?

If people on this mailing list are going to continually belittle us Committee members and our efforts, I for one have far better, more positive things to do with my time.

You seem to be the last person to lecture about "derailing into
off-topicness", as far as I can see.

Everytime you will be defensive of current EWG practices with me, "you" will be getting your disarming reply, on-topic or off-topic given that "you" did not respect "your" rules when you had to.

You, not Ville, are the person who keeps bringing up your EWG experience.  How is that at all relevant to "Generalizing the equivalence of auto and template type deduction"?

 

This has nothing to do with you as a person (you are an ok guy), but as an EWGer, you won't be able to defend those practices. Since all of you EWGers will be more careful from now on and follow your own rules, I think that something is gained for any contributors that may come. I gain zero out of this.

Other than that, again you are a valid technical commenter I respect on the things you really do know about. I will gladly accept to be proven wrong by you on a really technical subject. No point in continuing to go offtopic dear Ville. Let's close all of it here.

You keep saying that, but it sure looks like you'd rather get the last word in instead of winding it down.  Closing a discussion is easy, and doesn't require any drama whatsoever.  Just stop posting on the topic.  If others keep going, just mute the conversation.

 

The technical aspects in C++ are interesting, only that they are deeply poisoned by social manure and pomposity.

Continually using words like "social manure and pomposity" to describe the Committee poisons this list, at least for me.

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[George Makrydakis]

On 10/03/2014 01:35 AM, Nevin Liber wrote:

People work on papers.  They may or may not have a web cam pointed at their keyboards so you can watch them type.  They may or may not put them on public repos while they are working on them.  They may or may not send drafts to their friends.  They may or may not send drafts to the internal committee mailing lists.  They may or may not send drafts to this list.  At some point, if they wish to present it, they will get an N-number and it will be published as part of a mailing.

I don't see how any of that is secret.  That is just how people work, and different people work differently.

Mr Liber,

First, you seemed to be one of the kindest people in the last meeting. Now, I am very much aware of all the papers in question since I have cited them in the past, if you follow technical discussions here as well as being overly protective of your community (as you should be). The "secret" has to do with what goes behind the scenes, especially when prominent members of your community make convenient procedural "mistakes" because they are favoring particular lobbies instead of evaluating technical arguments that have already been made. My documented disillusionment of the EWG, was important in understanding this - as well as helping me out in becoming aware of who actually does any work there and who comes out as doing it.

Your prominent members cannot be giving a library recommendation based on non-arguments for one thing to its original author in draft stage and start work on a language feature implementation on the same thing the next day without any mention of what already went through. You should be fully aware of how this looks. And everybody loses.

You keep saying that, but it sure looks like you'd rather get the last word in instead of winding it down.  Closing a discussion is easy, and doesn't require any drama whatsoever.  Just stop posting on the topic.  If others keep going, just mute the conversation.

 

The technical aspects in C++ are interesting, only that they are deeply poisoned by social manure and pomposity.

Continually using words like "social manure and pomposity" to describe the Committee poisons this list, at least for me.

My first hand experience is that certain procedures followed in your meetings are problematic, as is questionable the way certain groups within the language operate in respect to newcoming authors. I do not need to remind you of Herb Sutter's remark held during a presentation on why following procedure is important. Deviating from said procedure, is what truly poisons your community. It makes contributions on this mailing list feel rehearsed enough by certain lobbies to be marketing ploys for scavenging the good will and effort of others.

1. https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7_YU/14de0yze2b8J
2. https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7WdwA/sE0lf-aYGGoJ

Given that you love what you do, make sure that the language subgroups you are involved with, stay clean in respect to their dealings with truly external contributors in the future - that are invited to do something. I gain zero out of winning an argument with you, since your own knowledge of the situation is rather incomplete and your good will misguided. As was mine.

Regards,

George