<p>When a string in a multi-line comment contains a */, it is interpreted as the comment end marker. </p>
<pre><code>/*
var s = "abc */ def"
*/
</code></pre>
<p>The compiler reports an error. Using back ticks yields the same result.</p>
<p>See <a href="https://play.golang.org/p/oN3HVW-Asv" rel="nofollow">https://play.golang.org/p/oN3HVW-Asv</a></p>
<p>This feature was a problem when trying to comment out regex expressions. They frequently contain */. </p>
<p>There is no such problem with the // comment. See <a href="https://play.golang.org/p/O2pyNHoXMd" rel="nofollow">https://play.golang.org/p/O2pyNHoXMd</a></p>
<pre><code>var s = "abc // def"
</code></pre>
<p>This compiles without error. This is the behavior I would expect.</p>
<p>I don't see a use case for a multi-line comment ending in the middle of a string. These comments are usually used at instruction boundary. </p>
<p>What is your opinion about it ?</p>
<hr/>**评论：**<br/><br/>0xjnml: <pre><blockquote>
<p>What is your opinion about it ?</p>
</blockquote>
<p>Working as intended and in accordance with the specs.</p>
<blockquote>
<p>This is the behavior I would expect.</p>
</blockquote>
<p>Me not. I prefer a tokenizer that never attempts to interpret the comment content in any way. </p></pre>EdiX: <pre><p>The contents of a comment are just text.</p></pre>chmikes: <pre><p>The problem is when I want to comment out a sequence of instructions, and there is a string in these instructions that contains */. It is a problem if the compiler interpret the */ in the strings as comment end.
I don't have a C compiler to check how it handles */ in strings. I have never seen this problem before. </p></pre>nevyn: <pre><p>For what you suggest to be true the stuff inside a comment section would need to be parsed, thus. would need to be parsable.</p>
<p>This is well known in C/C++, the usual workaround is to use #if 0 instead. For other languages use an editor that supports adding "//" comments markers easily to every line in a selection.</p></pre>chmikes: <pre><p>Ok. This nails it. Thank you. I never bother to use this feature until now and relied only on the /* ... */ comments. </p></pre>EdiX: <pre><p>This is how almost all programming languages behave. A scant few support nested comments. Even fewer have code comments. </p></pre>TheMerovius: <pre><blockquote>
<p>The problem is when I want to comment out a sequence of instructions</p>
</blockquote>
<p>But that is not what comments are for. They are for commenting your code. And if you want to use it for that purpose, <code>//</code> is much better suited for this exact reason.</p>
<blockquote>
<p>it is a problem if the compiler interpret the */ in the strings as comment end.</p>
</blockquote>
<p>But that is not what is happening. There is no "string" here, just a comment. Inside the comment, there are no strings or other go concept, because it's just text. And multi-line comments end on <code>*/</code>. You mention that it's not a problem with <code>//</code>, but the situation there is opposite: You have go code, containing a string and the content of that string is ignored by the tokenizer.</p>
<blockquote>
<p>I don't have a C compiler to check how it handles */ in strings.</p>
</blockquote>
<p>You also don't have a go compiler doing that. But also, any old C compiler does exactly the same thing. <a href="http://sprunge.us/dYbB" rel="nofollow">Try compiling this</a>.</p></pre>chmikes: <pre><p>As I said, I don't have a C or C++ compiler now to test it.
But I now fully agree with you. It all make sense.
Using /* ... */ to comment out code is an anti pattern.
Thank you for taking the time to help me understand this. </p></pre>sin2pifx: <pre><p>The onus is on your regexp to check that. A parser can never guess your intentions.</p>
<p>If you want to avoid this problem, prefix all lines with //</p></pre>Redundancy_: <pre><p>I don't see why you would expect content aware parsing for a multi-line comment. The contents are whatever you happen to want to put in there, so the "string" has no meaning.</p></pre>epiris: <pre><p>When I comment out code with multi line comments it's because I don't want to think at all about what is inside while I focus on something else. These are never permanently applied. I use // from r permanent comments almost exclusively and the two main methods I use to write Go (vim and atom) both support easy multi line comments. </p>
<p>Best solution for you would be getting accustomed to relying on your editor to do this, it's a menial task not worth thinking about much while writing software.</p></pre>Sythe2o0: <pre><p>Comment parsing can definitely take into account string literals and ignore the contents of the string literal. Without regex I'd say that it probably shouldn't do that, but you offer a good use case. I think it makes sense for the parser to ignore the string contents while parsing the comment.</p></pre>chmikes: <pre><p>You are right, it would be tricky to write a single regex rule to parse multi-line comments by skipping */ inside double or back ticked strings.</p></pre>Sythe2o0: <pre><p>Well, the way you'd probably do it is by having a parser state which was "String in Comment". The problem would be ignoring parse errors in the string (i.e. unterminated strings).</p></pre>bru7us: <pre><p>Unterminated strings is the "feature killer" here actually -<br/>
What if I want a multi line comment about string delimiters that deliberately includes unterminated strings (or single quote/backtick markers - will my comment never be "closed"?</p></pre>Sythe2o0: <pre><p>You are correct</p>
<p>For some reason I thought I had written a parser that had this logic before, but I went back and it does not, for this reason</p></pre>
