-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate some kinds of doc comments #1371
Comments
I remember seeing a similar issue/RFC somewhere already. While I personally do not ever use block comments/doc-comments and would be fine removing them, I do not see how you would document crate without |
Please don't remove /* */. It's convenient to quickly comment out code while debugging. Multi-line comments a good thing. |
@alfiedotwtf Any decent editor can comment out multiple lines faster than you can type |
@gsingh93 No. I can comment out code thousands of lines apart by bouncing in Vim without leaving my keyboard, which in reality only modifies two lines. Also, why push features to a person's editor rather than the language itself. That's like saying we don't need Rust at all because we have Valgrind and cppcheck. |
I can do the same thing in Emacs without leaving my keyboard, and I'm betting you can do it in Vim as well. |
We are talking about doc comments here! I'm guessing @nrc is referring to the little-used 👍 from me (although I would like to see |
🔥 💀 Death to |
I'm 👍 on removing all block comments. We do have a lot of comments, but It'd be weird to remove one kind of doc comments. The symmetry is nice. |
-100 for removing non-doc block comments. I don't care much about block doc comments. |
👍 to this RfC. Nobody seems to use the block doc comments. We can land a deprecation lint for this syntax, too. However, I feel we should keep the inner doc comments ( IMO we should not remove regular block comments at all. |
I use block doc comments all the time for module/crate level documentation. I think it's a nice convenience. I'm not sure I'd argue strongly to keep them if I'm their sole benefactor though. |
👍 for removing block doc comments |
Discussed previously: rust-lang/rust#6782 which was moved to #287. |
I’ve used |
Block comments vs per-line has always been a hot topic, removing one in favour of the other would be generally unpopular. Maybe dropping either Personally I don't think that the current system is particularly confusing, it's perhaps just overly verbose. |
@AngusP note that this issue is primarily about documentation comments, not regular ones. |
@Manishearth though I'd argue that the same degree of choice should be available in doc comments as regular ones, both for ease of use and to encourage developers to write documentation comments. |
My opposition to block doc comments is primarily that the official style guide says not to use them... which basically makes them worthless? Normal block comments are good because they're tools for "make all this code go away for now", but docs are never temporary. |
For deprecating doc blocks, against deprecating normal blocks, which I use inline while building stuff out all the time. Against removing //! because it makes documenting modules much more pleasant. |
I'm against removing one style (block vs line) of comments in preference to another; I'm also not really bothered by the existence of multiple types of doc comment. |
@nrc Please make OP more clear that this issue is only about documentation comments. People are getting confused. |
I disagree. To me, it seems pretty nice how everything stands. Every comment style has a unique, non-replaceable purpose.
If anything will be dropped, please please keep the symmetry. Either drop all of one kind or don't. Having block comments but not block documentation comments will be pretty odd. RFC-505 has a statement:
Block (documentation) comments are useful as they reduces visual noise in large amounts of text by removing the need for a comment token on every line. While they are recommended against, IMO they are still pretty useful. Single line (documentation) comments are useful as they add information to every line, marking the line explicitly as a comment. They are also more convenient for short pieces of text. Off-Shoot Idea: How about some syntactic sugar for Edit: Am I missing something? Does this idea even make sense? I should sleep. |
@pradyunsg doc comments are the sugar for (Yes, I realize this is a reply over a year later. Just wanted to clarify this.) (Edited to add: wow, this was added seconds before the next comment) |
Despite my 15+ years working in Python and, prior to that QBasic, Visual Basic, and DOS batch files, I've never liked single-line comment syntax for multi-line comments... especially for structured documentation which relies on it for things like preformatted code snippets and Markdown list syntax and. It feels like needless noise which significantly and unnecessarily complicates the logic an editor needs if you want it to support indentation assists. (And I think it was a good decision for Python, despite using At the same time, when I've had to write C, using Both types of comments have their place and I always configure
Could you clarify what you envision "syntactic sugar" to entail? I'm imagining "replacement for |
I believe at this point, with the RFCs being turned down, the status quo is what's going to remain. as such, i don't think we need to track this. |
With the intention of removing them in 2.0.
It is ridiculous how many kinds of comments we have, lets settle on one kind of doc comment and have done. We can make it really easy for people to migrate with tool support. Personally, I would like to keep only
///
, but I don't really care as long as we just have one kind.The text was updated successfully, but these errors were encountered: