>
>
> Move Semantics. Compile Time evaluation. Concepts (which make life
> absurdly easier for people that have to otherwise SFINAE stuff). Class-Type
> Template parameters. std::launder. Examples of stuff we couldn’t do until
> the language introduced them.
>

Move semantics is probably within that one percent that was impossible to
achieve (to some extent it is a replacement for swap()). Compile time
evaluation has been possible with "enum { value = sizeof(...) ==
sizeof(true_type) ? 4 : 6" and so on..., Concepts are sfinae/enable_if,
class type template parameters - just make them flat.
But I suppose this discussion has little to do with the proposal :)



> The issue is not that it can be done already. Its that to make use of this
> proposal, you aren’t saving a lot of time or effort over what is already
> being done. There is also a lot more control that can be had over manually
> doing this with using declarations.
>

Well, I am starting to understand you less and less. All language
constructions and invariants that are kept and enforced by a language, are
not about having ultimate control. They are rather about opposite - about
making common things easy, about handing some things over to a compiler. If
we want control we should eradicate C and C++ and start programming in
assembler - what if optimiser in a compiler will do your its job poorly,
after all, how can you trust it, where is our control?

About time: "you aren’t saving a lot of time or effort over what is already
being done".
What do you mean by "a lot of time"? If it saves 0.01% I think it is a huge
win. Just multiply it by the amount of time of all developers.
Moreover, as I have already said, time is not the only thing to consider.
Another thing to consider is whether the proposal allows to express your
intent more clearly.

Namely, for class non-type template parameters, whether it copies or just
> references.
>

Sure, but do you think there is a point in having a copy of const lvalue?


> Additional point, what about partial specializations. What about full
> specializations. How does the proposal deal with specializations? Are the
> old, unspecialized names visible, or are only the names of the
> specializations template parameters visible? What if the specialization
> wants to suppress one or more of the names.
>

Those are indeed good questions.
First of all, there are

   - opt-in approach: a (partial) specialisation is to explicitly say that
   it wants to propagate it's template arguments (as primary template does)
   - and opt-out approach: a (partial) specialisation is to explicitly say
   that it wants to suppress propagation.

The opt-in approach could look like:

template <public class value_type>

class Foo {

// value_type is implicitly generated

};

template <class T>

class Foo<*public *T*> {

public:

// value_type is implicitly generated

// using value_type = T*;

// without public above, it would not

};

The opt-out approach also looks reasonable, imagine, for example
vector<bool> - this partial specialisation wants to declare value_type =
bool, exactly as in the primary template.
Now, if we chose this opt-out approach, there are a couple of ways of how
(partial) specialisations can supress/changed propagated template
parameters:

   - Allow declaration of the same name without generating error (or revert
   the plan to generate errors on name clashes altogether).

template <public class value_type>

class Foo {

// value_type is implicitly generated

};

template <class T>

class Foo<T*> {

public:

// Can be redeclared with the same name

   using value_type = T;

};



   - Use delete keyword

template <public class value_type>

class Foo {

// value_type is implicitly generated

};

template <class T>

class Foo<T* = delete> {

 // there is no value_type

};
The advantage of this option, is that it might be possible to remove the
using/typedef completely.

>