I think I'm opposed to this; I believe we have enough options for this already, no need to have code comments as well.
Options include: 1. Putting code in conditionals that use final/constant values (i.e- compiled away when value evaluates as false) 2. Unused closures/methods/functions 3. Assertions (and the code they call), since these compile away in production code. 4. Polymorphism/generics, useful for swapping in stub or otherwise dummy types when you want to test others in isolation. Or even just to keep around an older version of an implementation, handy if you reimplement something for performance, but thing you might have a subtle bug an older version didn't have. I'd argue that leaving code in comments is bad practice with better alternatives, so supporting it more could be counterproductive. The only places I use code comments are when I replace a complex line of code, but want to leave it in position as a reminder of what the original code did (in case the new code is different somehow), but even then I leave it as a FIXME to remind me to remove it once I'm happy with my tests. I dunno, I just feel like we've got better tools for handling old/conditional code already. > On 14 Jan 2017, at 23:18, Amir Michail via swift-evolution > <[email protected]> wrote: > > The code in a “code comment" must compile (not just be syntactically correct) > yet must not have any effect on the resulting executable. > > For example, commented entries in an array would be checked for compilability > but would not be included in the executable. > > Such “code comments" would allow you to have code/data that is currently > unused but is constantly checked to be valid just in case you want to use it > in the future. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
