forbidden by?

it doesn't compile in that way: Visitor && - cannot deduct following arguments. I spent much time to workaround it and just put in as is. Maybe it MVS specific bug, because GCC version compiled fine

But, i' ve popped about some fix since i read your comment: it is possible to eliminate VisitorArgs such Lambda can capture it and Class can capture it as member and it doesn't require to pass it as additional args. Moreover std::visit doesn't receive any additional args

What do you think about it? After elimination VisitorArgs it will became possible to pass Visitor by universal reference and unblock passing instant lambda here

What's the purpose of this one?

Oh I seem to get it - it just does nothing if a particular variant's type has been visited already?
If it is, then why should we have such an overload? We may possibly terminate the traversal on the match (haven't looked into the below code yet).

May be this implementation is not pretty accurate - we can terminate recursion in another way... But in this PR I mostly focused on usability & applicability of visit instead of it's inner implementation

I hope we can use std variant soon or later :) and i doesn't concentrate on pretty templates implementation here...
But maybe i wrong and turning on c++14 & c++17 is very very far enough

hmm I see, its sort of prints type not the value -- actually, visitor is not required here at all? It is just out << cv::detail::meta_to_string<MetaT>() (except the case for monostate but that's workarountable)

cv::detail::meta_to_string()

Do you mean the second visitor? it's required cause out is variant too and we need expand it to print-out actual type we have (which actually in controversy with expected type), just for troubleshooting info in exception (user just read and change it)

Amount of code removed here and added atop of that gives some hint... :)

That's the controversial point of having a visitor as some class/etc. -> while previously we could use plain switch (well, not very automated but integrated perfectly into its environment), with a distinct class the handling logic is torn away from the context - we don't have scope closures for such objects like we could have with lambdas, for example.

Would it be possible to construct an ad-hoc visitor with typed lambdas right in place? It would be a game changer then.

I believe the limitation I've got into was that the visit return type was determined by the visitor lambda called - and it could vary; but I believe we could relax such requirement here and now.

That's the controversial point of having a visitor as some class/etc. -> while previously we could use plain switch

in current piece of code we need two stacked switchs similar with

  switch(expected)
  {
     case A:
            ...
            switch (got)
            {
                case AA:
                     PRINT "A and AA mismatch"
                case BB:
                     PRINT "A and BB mismatch"
            }
     case B:
        
          switch (got)
              case AA:
                      PRINT "B and AA mismatch"
  }

In current implementation it solved by using two simple classes

I believe the limitation I've got into was that the visit return type was determined

exactly! it is the problem i faced ( without writting a lot of code for cast Lambda to std::fuction<> and extract return type
a) static_visitor as base is 'boost'-like way
b) lamba is std

But in case if we fix visitor for lambda usage, we cannot use lambda here, because lambda with auto params is beginning with C++14, so code like that

auto l = []( const auto &v)  {}      //<---auto ?

It' won't work in c++11

So looks like class-style is only way for C++11

P.S.
it is possible to use overloading in lambda like that

auto overloaded_lamda = make_overloaded_lambda([] (const GMatDescr& m) {},[] (const GOpaqDesc& o)  {});
visit(overloaded_lambda, variant);

but it looks more ugly

it doesn't compile in that way: Visitor && - cannot deduct following arguments. I spent much time to workaround it and just put in as is. Maybe it MVS specific bug, because GCC version compiled fine

But, i' ve popped about some fix since i read your comment: it is possible to eliminate VisitorArgs such Lambda can capture it and Class can capture it as member and it doesn't require to pass it as additional args. Moreover std::visit doesn't receive any additional args

What do you think about it? After elimination VisitorArgs it will became possible to pass Visitor by universal reference and unblock passing instant lambda here

May be this implementation is not pretty accurate - we can terminate recursion in another way... But in this PR I mostly focused on usability & applicability of visit instead of it's inner implementation

I hope we can use std variant soon or later :) and i doesn't concentrate on pretty templates implementation here...
But maybe i wrong and turning on c++14 & c++17 is very very far enough

cv::detail::meta_to_string()

Do you mean the second visitor? it's required cause out is variant too and we need expand it to print-out actual type we have (which actually in controversy with expected type), just for troubleshooting info in exception (user just read and change it)

That's the controversial point of having a visitor as some class/etc. -> while previously we could use plain switch

in current piece of code we need two stacked switchs similar with

  switch(expected)
  {
     case A:
            ...
            switch (got)
            {
                case AA:
                     PRINT "A and AA mismatch"
                case BB:
                     PRINT "A and BB mismatch"
            }
     case B:
        
          switch (got)
              case AA:
                      PRINT "B and AA mismatch"
  }

In current implementation it solved by using two simple classes

I believe the limitation I've got into was that the visit return type was determined

exactly! it is the problem i faced ( without writting a lot of code for cast Lambda to std::fuction<> and extract return type
a) static_visitor as base is 'boost'-like way
b) lamba is std

But in case if we fix visitor for lambda usage, we cannot use lambda here, because lambda with auto params is beginning with C++14, so code like that

auto l = []( const auto &v)  {}      //<---auto ?

It' won't work in c++11

So looks like class-style is only way for C++11

P.S.
it is possible to use overloading in lambda like that

auto overloaded_lamda = make_overloaded_lambda([] (const GMatDescr& m) {},[] (const GOpaqDesc& o)  {});
visit(overloaded_lambda, variant);

but it looks more ugly

is outside of test scope because c++ told me local classes with templates are forbidden
for special (non-templated) methods it should compile fine

Is this bool mandatory? can't it be inferred via CRTP?

since the static_indexed_visitor is already using CRTP

1. From my perspective it breaks erroneous-prone criteria:

It is possible writing by mistake

class MyClass : public static_visitor<MyClass> {
bool operator()(int)
{/*1000 lines of code*/}
void operator()(float)
{/*1000 lines of code*/}
int operator() (char)
}

but with explicit type it less possible

AND the more strongest reason

2. to deduct return_type in CRTP you must use the same construction as in visit() decltype(visit_impl(get<0>(var))) where visit_impl is upper-level hierarchy wrapper class. But

decltype(visit(get<0>(var))) <---- where can i get var variable here?

Look

somewhere in CRTP...
template<class T>
auto operator() (size_t index, const T& val)  -> decltype(Impl::visit(declval(T))) <---!

declval(T) - is useless here, because it's declaration and doesn't define nothing because nothing to instantiate

I believe ADD_FAILURE() or FAIL is the right thing in this case.

Also, should this list cover all Types.. range? What if we want to handle only this or that case? (e.g. T1 and T3 only)? Can a "default" lambda (with no value passed in, or with variant itself passed in) be introduced here?

NO, it's limitation for C++11 lambda. In C++14 generic lambda can helps to reduce amount of code
That's because I insist to keep ClassVariant implementation too

Can a "default" lambda

It is possible to implement Bypass struct here

namespace opencv {
namespace utils {
template<class T>
class Bypass {
operator(T val) {}    <---nothing to do
};
}
}
temlplate<class T...> overload_lambdas_set<Bypass<T>...> make_bypass() {...}

Then

cv::util::visit(cv::overload_lambdas([] (int) {}, make_bypass<double,... ???,...>(), ...);

But I'm not sure about usefulness of this case. maybe as theoretic exploration pros-cons

My comment was not about the template lambdas but about not specifying some overloads

It won't compile, i believe

Also i believe that it is not extendable, error proneous and dangerous: Because after planned extension of variant types list ( adding new type for example) you will not receive any error and newly added type would not be processed silently

Also, what's the difference between Static and Dynamic visitors here?

This class implements visit(Type val), but Dynamic implements visit(std::size_t index, Type val

I agree that class name is confused, i will rename it

What's the difference between those and should user care about that?

the second version visit(std::size_t index, Type val) for indexed_visitor returns not only value from variant but also its position index and provide additional flexibility in processing the value ( for example logging, printing, or more compilex use case in serialization maybe)

What's the idea behind that?

for getting return type in common case: Lambda + Class Visitor - and keep one interface invocation point: visit() only - it requires to unify return_type deduction mechanism. For Lambda it is possible to take type of decltype(visitor(get<0>(var))) but for Class Visitor there is no operator() in base case, because it provides operator() (std::size_t index, ...)

So operator() uses only for Class Visitor only for deduction return type in visit()

Got it, but a comment in the code would help here a lot.

sure, i'll add it

I don't quite get what it does - why do we need a construct like this? Does it have any side effects? I believe no?

just stack allocation of several booleans in the end of recursion.

Used cause several compilers notifies it as unused variable

So this whole construct is solely about the unused warning?

I believe we can drop names from the method signature then and that's it :)

good idea, thanks. i'll try it

Got it, but a comment in the code would help here a lot.