[dcl.fct.def.delete] Cluase doesn't differentiate when and where designation of deleted function should be accepted like ellipsis vs auto

[ranaanoop]

Full name of submitter: Anoop S. Rana

Reference (section label): dcl.fct.def.delete

Link to reflector thread (if any): https://stackoverflow.com/questions/79976406/why-ellipsis-can-use-deleted-move-ctor-but-auto-cant#79976406

Issue description: Consider the following program where the declaration of type compiles but type2 is rejected by all compilers. My current understanding from dcl.fct.def.delete is that both should be rejected.

#include <type_traits>
#include <utility>

template <class>
struct Vector {};

struct DerVector : Vector<int> {};

struct NoMove {
    NoMove(NoMove&&) = delete;
    NoMove() = default;
};


int f(...) ; 
int g(auto);      
int main()
{
    using type = decltype(f(std::move(NoMove())));     //#1:this compiles 
    using type2 = decltype(g(std::move(NoMove())));    //#2: this doesn't compile
}

As we can see, the type version with ... compiles but type2 with auto doesn't compile. From dcl.fct.def.delete:

A construct that designates a deleted function implicitly or explicitly, other than to declare it or to appear as the operand of a reflect-expression ([expr.reflect]), is ill-formed.

This seems to make both type and type2 invalid but to my surprise type compiles with all compilers. I expected both to fail.

Suggested resolution: Note there is already an issue related to this. Change "designates" to "is used/called" or "is selected" to in dcl.fct.def.delete. I think resolution of either of these would solve the other.

[safocl]

Can you specify what specifically in the wording of the provisions of the standard you consider to be erroneous, imprecise, or insufficiently clear, which, if changed, could eliminate the behavior that you consider invalid?

[t3nsor]

To me, this just seems like a bug in the implementations. Do we have any reason to believe that this is a reasonable way for implementations to behave?