I often find when writing code that I want to introduce sections
into my file. Typically I do this like:
// Node construction
//
// Methods for constructing new nodes.
I find this helpful when browsing through the code. I
I'm voicing my support for the nice docstring comments :).
I'd be all for only having // comments and /// docstrings though, but
I have a feeling a lot of people would strongly disagree.
___
Use /// to start a doc-string and / to continue one.
On Thu, May 2, 2013 at 1:50 PM, Erik S sw...@earthling.net wrote:
John,
I would suggest requiring *exactly* three slashes for a doc comment (or
*exactly* two stars for a /** -- */ style doc comment). This matches
with Doxygen's parsing (I think), and makes both the examples below
parse
Are explicit `mod`s too heavyweight for this?
On Thu, May 2, 2013 at 6:18 AM, Niko Matsakis n...@alum.mit.edu wrote:
I often find when writing code that I want to introduce sections
into my file. Typically I do this like:
//
FWIW, I am very much in favor of having 'proper' docstrings instead of
comment docstrings. I don't really see any upside to comment
docstrings at all...
2013/5/2 Lucian Branescu lucian.brane...@gmail.com:
Not necessarily:
#[doc=
Actual docs, free to contain almost any characters, without the
On May 1, 2013, at 6:50 PM, Erik S wrote:
John,
I would suggest requiring *exactly* three slashes for a doc comment (or
*exactly* two stars for a /** -- */ style doc comment). This matches
with Doxygen's parsing (I think), and makes both the examples below
parse correctly.
Both of these
Since there are no encoding support in Rust beyond utf-8/16, I've been
toying around with str-[u8] codec generation using the
specifications from unicode.org (inspired by the cpython
implementation) as my first learning-Rust project.
I'm now at the point where I can successfully generate a
On 05/02/2013 03:18 AM, Niko Matsakis wrote:
I often find when writing code that I want to introduce sections
into my file. Typically I do this like:
// Node construction
//
// Methods for constructing new nodes.
I
Anyone object to changing the parser in this way? To be clear,
these two restrictions are (in my view) orthogonal to other possible
changes. I'd still be delighted to get rid of some of the doc-string
forms.
Makes sense to me.
Niko
___
Rust-dev
Hi everyone,
There's consensus that `@` (imported from Haskell) is a bad binding
operator for patterns, because it leads to the confusing-looking `@@`
in, for example:
struct Foo {
field: int
}
...
match foo {
foo@@Foo { field: x } = ...
}
However,
I don't particularly like any of the options here, but as seems like
the least bad one. Matching on a casted constant seems like a pretty
rare case, and you can always use if instead of match. I agree that
the existing @ syntax is ugly, and I think using '=' for pattern
binding muddies the waters
Maybe we can find a way to incorporate some sort of section
to use when grouping items, methods, fields, etc. I imagine
we could draw on Markdown's `#`, `##`, `###` notation to
define sections, subsections, and so forth, but I'm just
not sure how we would let rustdoc know about it, since
I'm not sure what I think about this, but we could do away with the `as`
cast operator and replace it with `.to_f32()`. I was already planning on
adding a ToInt/FromInt for casting to and from enums, so we'll probably
grow `.to_f32()` and etc anyway. I doubt we could use `.to_f32()` in a
pattern.
13 matches
Mail list logo
