<div dir="ltr">On Mon, Jan 16, 2017 at 8:38 AM Amir Michail <<a href="mailto:a.michail@me.com">a.michail@me.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Jan 16, 2017, at 10:55 AM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="gmail_msg" target="_blank">tony.allevato@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> As a general rule of thumb, changes to the language should not require the use of an IDE in order to return them back to the level of usability that was had before the change. Swift is not a Mac/Xcode-only language, and even on that platform, there are a number of times where I personally find myself working in Sublime Text instead of Xcode, for various reasons.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
One could argue that those using a simple editor that can't hide comments would benefit more from this proposal.<br class="gmail_msg"></blockquote><div><br></div><div>By removing the context that those comments can provide? It seems like you're trying to argue both sides of an argument at the same time: this feature is OK because IDEs can still show you the comments and you don't have to scroll to the end of the file, but users without IDEs who will be forced to scroll to the end of the file will still benefit because...?</div><div><br></div><div>It feels like your argument is just that comments can become out of date, or they take up too much space/you want to see more of the code. For the first, that's a problem that your proposal won't solve—it just moves the outdated content to the end of the file where it can be ignored more easily. That's not an improvement. For the second, I think most software developers would *love* to have the problem of too much documentation in their code vs. too little. :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> Regarding this idea specifically, I think it would simply discourage users from writing comments at all, without necessarily any improvement in code quality. The developers who already write self-explanatory code will continue to do so, and those who write bad code and don't comment will also continue to do so. Do you have any evidence that making commenting harder would improve code quality?<br class="gmail_msg">
><br class="gmail_msg">
> On Mon, Jan 16, 2017 at 7:28 AM Amir Michail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
> Why not replace all Swift comments by end notes at the end of each source file so as to minimize the impact of misleading/outdated comments on code comprehension?<br class="gmail_msg">
><br class="gmail_msg">
> You don’t necessarily need to scroll to the end of the source file to read a referenced end note in the code since the IDE could show a popup whenever the mouse pointer lingers over an end note reference (e.g., a number/label).<br class="gmail_msg">
><br class="gmail_msg">
> Maybe this would encourage programmers to write more self-explanatory code while keeping (end note) comments to a minimum?<br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-evolution mailing list<br class="gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>