Some thoughts, inline
2017/01/14 18:18、Amir Michail via swift-evolution <email@example.com> のメッセージ:
The code in a “code comment" must compile (not just be syntactically correct) yet must not have any effect on the resulting executable.
What is the definition of "compile"? It truly matters because certain definitions you give will have serious security threats associated with them.
There's also a certain style of linter tool that is built for running code in documentation to check its correctness (Scala has a famous one in the form of Tut (https://github.com/tpolecat/tut). Tut spins up individual REPL sessions per comment so is built to be run as a commit hook or as part of CI builds, not something live (a bit like a miniature playground) running inside the IDE. On the other hand, for the majority of code comments it probably suffices to just get it through typechecking. You won't have the benefit of checking its execution, but at least you'll know you have some well-formed code in the comment.
For example, commented entries in an array would be checked for compilability but would not be included in the executable.
We suddenly have to demarcate which parts of the language are "safe" versus "unsafe" is what you mean? This sounds incredibly brittle and borderline unenforceable.
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.
There is a way to go about doing this in a safe and productive manner, but it may not quite be the way you see it in your minds' eye. If you want code execution you have to trade in security. If you want live/quick results you have to give up execution. Lord knows we don't need malicious comments to be the source of the next Xcode Ghost nor do we need to slow the IDE to a crawl checking a thousand comment sheds in a thousand REPL sessions.
swift-evolution mailing list