Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, _hum_, Вы писали:

__>>p.s. а что в таких случаях будет с перегружаемыми функциями, наподобие auto f(); auto f(int i); ?

_NN>А проблема то в чём ?
_NN>Будут разные типы.

_NN>

_NN>#include <iostream>
_NN>#include <type_traits>

_NN>using namespace std;

_NN>auto f()
_NN>{
_NN>  enum class A { X, Y };
  
_NN>  return A::X;
_NN>}

_NN>auto f(int)
_NN>{
_NN>  enum class A { X, Y };
  
_NN>  return A::X;
_NN>}

_NN>int main()
_NN>{
_NN>  auto fvoid = f();
  
_NN>  auto fint = f(1);
  
_NN>  cout << is_same<decltype(fvoid), decltype(fint)>::value; // 0
_NN>}
_NN>

Вы немного не так поняли. Я-то думал, что речь о том, чтобы задействовать использование идентификатора функции для идентификации типа возвращаемых ею значений (тем самым экономились бы идентификаторы и в то же время обеспечивалась привязка типа к конкретной функции) — эдакой своеобразной инкапсуляции типа в функцию с возможностью явного экспортирования, то есть некоего аналога

struct f
{  
    enum class Res{ok, failed}; 

    Res operator()(){return Res::ok;}
};

для которого можно

void main()
{
    list<f::Res> ResLog;

    for(int i = 0; i < 100; ++i)
    {
         f::Res res = f()();// а хотелось бы f()

         ResLog.push_back(res);
    };    
}

Однако, как в дальнейшем выяснилось, мой вариант невозможен, ибо идентификация области видимости функции по ее имени не уникальна. А изначальный вариант (и ваш его повторяющий) плох тем, что за пределами функции приходится работать с анонимным типом. Соответственно, например, нельзя просто заранее организовать контейнеры для хранения результатов вычислений функции, не говоря уже о том, что читабельность такого варианта плохая.