diseraluca wrote:

> @diseraluca, thanks for the thorough description. The point of these routines 
> is to produce code that compiles. I am not sure if we change `Foo<int>::Bar` 
> with `Foo<T>::Bar` it will compile.
> > Due to the way the current codebase is set up, the chosen specialization is 
> > `QFuture<void>` so that, for example, `QFuture::constBegin()` would be 
> > shown to the user as returning a `QFuture<void>::const_iterator`. 
> > Nonetheless, `QFuture<void>` is the only specialization that cannot have a 
> > `const_iterator` and, as a consequence, doesn't have a `constBegin` method 
> > in the first place.
> I suspect that `QFuture<void>` is an explicit specialization. The intent of 
> the code was to pick up an implicit specialization which follows much more 
> closely the template pattern. Would selecting the first non-explicit 
> instantiation fix your usecase?

Thank you for your answer @vgvassilev.

I gave it a quick try, and we would still end up with the same result in our 
codebase. But, generally, this would not probably be feasible for us as a 

Since that is the case, and we have somewhat conflicting requirements, I think 
the best path would be for me to indefinitely maintain a custom implementation 
of `getFullyQualified*`, leaving upstream as is.

I would thus suggest to close this without merging.

cfe-commits mailing list

Reply via email to