+1. Avoid adding `return` keyword for preprocessor directives converted to functions (in PreprocessorVisitor).
+2. Decide how do we handle multi-expression functions.
Update: added the following comment:
+3. Revise ExtractStaticVariableInitializer()
Update: since we are using returnkeyword with an explicit variable name, omitting returnkeyword won’t add any benefits like readability or clarity - no changes made here: http://swiftify.me/5gn1tm
+4. Revise VisitGccStatementExpression()
Update: similarly to preprocessor directives, the insertion of return keyword is very tricky and unreliable here.
Removing returnkeyword here, and will rely on the compiler output: http://swiftify.me/mpjc61
GCC “statement expressions” are typically converted to multi-expression functions, so we can’t use the “implicit returns“ feature in this case (need to keep the return keyword).
+5. Research using Swift 5.1 opaque return types when we cannot reliably detect a return type in PreprocessorVisitor.
Update: opaque return types seem to be relevant for functions returning a protocol type only, so I can’t see any universal use of this feature for the conversion of directives.
-6. Omit the `return` keyword from single-expression functions.
Update: since this is a new change and time is required for people to adopt this change, let’s leave the return keyword for both methods and functions, for consistency between single- and multi-expression functions.
-7. Omit the `return` keyword from single-expression closures.
Update: removing the return keyword for single-expression closures only seems as tricky as adding the return keyword only for single-expression preprocessor macros (converted to functions). Let’s keep the return keyword in Swift if the Objective-C keyword had it.
-8. Think about making (5), (6) configurable.
Update: I see no much value in this. Let’s revisit if needed.
A related report (from David K.):