> I'm not sure sugar really matters. It does. `vector<int>::_Iter_type x = ...;` is not valid C++, no matter if it actually compiles on a particular implementation or not. And transforming non-portable code is asking for trouble.
[REV] Why isn't it valid C++? Is it really our responsibility to test for non-portable code? I understand that by replacing this user-specified type with 'auto' will possibly make code that normally wouldn't compile for some implementations into code that does compile but I think portability testing is beyond scope for the migration tool. If a user uses an implementation-specific type that makes the code non-portable, should we assume the user did this to make the code non-portable? If the types match while compiling, I would say we can infer the user's intent and use auto and in the process make their code more portable. > That said, one could foresee an improvement to this transform that tests for unusual sugar and then prompts the user. It can be done easier, I think. We know that all functions that return iterators have a return value type with correct sugar. That is, `vector<T>::begin()` return value is always `vector<T>::iterator`. [REV] This isn't always true. When dealing with for-loops I found from dumping the AST that you don't get vector<T>::iterator but whatever vector<T>::iterator typedefs to which is quite long and complex with libstdc++. It was this realization that prompted the comparison of canonical types. . We should desugar the user-provided type until we hit that correct type (then we are sure that the transformation is safe), or we get a canonical type (and that means that the code is unportable). [REV] I will do some experiments here but given my experience with the aforementioned for-loop issue I expect detecting the 'right type' as we unsugar isn't going to be easy. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
