Re: [rust-dev] Some work on Rust coding standards
On 04/10/2013 05:25 PM, Erick Tryzelaar wrote:
Great! We've needed something like this. I worry a little bit about
the function declaration style though. I could see it being difficult
to implement this format in the pretty printer, which would make it
hard to write something like gofix. Here's the longest function
declaration I could find in our codebase, this one in
src/librustc/middle/typeck/infer/unify.rs http://unify.rs:
fn simple_varsT:Copy + Eq + InferStr + SimplyUnifiable, V:Copy +
Eq + Vid + ToStr + UnifyVidOptionT(mut self, +a_is_expected:
bool, +a_id: V, +b_id: V) - ures {
Assuming we extended the rule to the typarams, we'd have:
fn simple_varsT:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr +
UnifyVidOptionT(mut self,
+a_is_expected: bool,
+a_id: V,
+b_id: V)
- ures {
This indentation looks pretty crazy here because I see a non-monospace
font, but your point about type parameters is well-taken. We were not
considering them.
Which in my opinion is hard to read. Then there's the question of what
happens if even after wrapping the line pushes us past the 100
character limit?
For my bikeshed, I have started using the basic rule that if I can't
fit a statement on one line, I wrap and indent 4 spaces after a '',
'(', or '{':
fn simple_vars
T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVidOptionT
(
mut self,
+a_is_expected: bool,
+a_id: V,
+b_id: V
) - ures {
I like this style as well. It wasn't so popular in a straw vote.
Another option is to do what Go does, and say there's no limit in the
line length, but if the user wants to wrap, just add a tab to the
start of the next line. So it could look something like this
fn simple_vars
T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVidOptionT(mut self,
+a_is_expected: bool, +a_id: V, +b_id: V)
- ures {
It's a little ugly, but it's consistent, and really easy to implement
with a pretty printer. Here are the Go rules:
http://golang.org/doc/effective_go.html#formatting
I personally don't care what style we use, I just want to make sure we
choose a style that's easy to automate so we can move on with our lives.
On Wed, Apr 10, 2013 at 3:57 PM, Brian Anderson bander...@mozilla.com
mailto:bander...@mozilla.com wrote:
There have been a few mentions recently about writing up the Rust
coding standards. Several of us sat in a room and tried to
identify and agree on some that we thought were important. I've
pasted the resulting notes into the wiki:
https://github.com/mozilla/rust/wiki/Note-style-guide
These are very, very rough but cover a number of topics. Comments
and suggestions are welcome. These need to be cleaned up into
readable prose, with decent examples, and moved from the 'Notes'
section of the wiki to the 'Docs' section where users will find
them. Help is definitely appreciated.
-Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some work on Rust coding standards
On 04/10/2013 05:37 PM, Niko Matsakis
wrote:
Hi guys,
I guess it is time to adopt some consistent standards.
Since I wasn't in the room, here are my two cents.
# Function docs
I prefer putting the function comment *inside* the fn rather
than in front. However, I am probably alone on this point, so
I'm prepared to lose this fight. Anyhow, if we are
going to place comments in front of the function, I think we
should encourage `///` comments in favor of the `/**..*/`. That
is, prefer this:
/// Function comment
/// More function
comment
fn foo() { ... }
To this:
/**
* Function comment
* More function comment
*/
fn foo() { ... }
My reasons:
1. No wasted lines (unlike /** ... */ which wastes two lines).
2. If you include a code example inside the `///` comment, you can
use `/* ... */` within the comment without triggering errors.
3. It just looks better to my eyes ;)
I too like the idea of using inner doc comments on functions, though
I haven't seen any code that uses them to good effect. We did say to
always use line-comments instead of block comments.
# Module docs
I like to make long comments on modules sometimes. I've decided
these "book chapter"-like comments ought to be put into a `doc.rs`
module, since it's a pain to scroll down through them.
# Long function signatures and the opening brace
Also, we should give more guidance in the event of long function
signatures. Personally, if the first parameter will not fit on
the same line as the function names, I favor moving the opening
brace to its own line, like this:
fn
some_really_long_name(
a: T1,
b: T2)
- RT
{
...
}
The idea is to use the brace at the start of a line to separate
code and signature when they have the same indentation.
Another relevant example would be what to do if you have a lot of
type parameters and traits. I typically do this:
fn
some_really_long_nameK: Some+Set+Of+Traits,
V: Another+Set+Of+Traits(
a: T1,
b: T2)
- RT
{
...
}
It sounds like this requires further discussion since the
recommended format on the wiki doesn't work well with type
parameters as erickt pointed out and you don't like it.
I think similar rules apply to if statements and so forth:
# Pattern syntax
I don't like the `|` in front of the patterns. Things don't
line up. When using `|` to combine patterns together, and
things don't fit on one line, my own personal inclination is to
follow a style like this:
match foo {
pat1 |
pat2 = {
...
}
pat3 |
pat4 = {
...
}
}
Here the indentation separates the
patterns from everything else. In cases like this, I never
use the non-brace form, since otherwise the indentation
doesn't work.
I also find I prefer using `{...}` form in cases where the
body does not produce a value, such as:
match
foo {
Some(v) = {
return v; }
None = {}
}
not
match foo {
Some(v) =
return v,
None = {}
};
Somehow, the
`,` strongly suggests a value is being
produced to me.
I agree that match arms without braces should only be used with
expressiony forms, not statementy.
# "Ternary operator" If else expressions
For cases where you would use the ternary operator in C, such as
`(foo ? bar : zed)` I tend to nestle the braces up with the
expressions, like so `if foo {bar} else {zed}`. I find this reads
better than `if foo { bar } else { zed }`. If others disagree,
let me know so I can stop doing it.
I'm not a fan of the inconsistency.
Niko
Brian Anderson
April
10, 2013 3:57 PM
There have been a few
mentions recently about writing up the Rust coding standards.
Several of us sat in a room and tried to identify and agree on
Re: [rust-dev] Some work on Rust coding standards
On 04/10/2013 07:22 PM, Kang Seonghoon wrote:
I mostly agree to Niko's comments, but I'd like to point out one issue
with function docs. Given the following code:
/// This is a doc comment with two paragraphs.
///
/// Not actually.
pub fn a() {
}
/**
* This is a doc comment with two paragraphs.
*
* Really.
*/
pub fn b() {
}
...rustdoc produces two paragraphs for `b` but one paragraph for `a`
(behaves as if there are no empty lines). I was assumed that it was by
design until now, but it now feels like a bug. (I'll open an issue if
it is indeed considered a bug.)
I consider this a bug.
Niko Matsakis n...@alum.mit.edu wrote:
# Function docs
I prefer putting the function comment *inside* the fn rather than in
front. However, I am probably alone on this point, so I'm prepared to
lose this fight. Anyhow, if we are going to place comments in front of
the function, I think we should encourage `///` comments in favor of the
`/**..*/`. That is, prefer this:
/// Function comment
/// More function comment
fn foo() { ... }
To this:
/**
* Function comment
* More function comment
*/
fn foo() { ... }
My reasons:
1. No wasted lines (unlike /** ... */ which wastes two lines).
2. If you include a code example inside the `///` comment, you can use
`/* ... */` within the comment without triggering errors.
3. It just looks better to my eyes ;)
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some work on Rust coding standards
On Wed, Apr 10, 2013 at 11:20 PM, Brian Anderson bander...@mozilla.comwrote:
On 04/10/2013 05:25 PM, Erick Tryzelaar wrote:
Which in my opinion is hard to read. Then there's the question of what
happens if even after wrapping the line pushes us past the 100 character
limit?
For my bikeshed, I have started using the basic rule that if I can't fit
a statement on one line, I wrap and indent 4 spaces after a '', '(', or
'{':
fn simple_vars
T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVidOptionT
(
mut self,
+a_is_expected: bool,
+a_id: V,
+b_id: V
) - ures {
I like this style as well. It wasn't so popular in a straw vote.
Java style in these situations (function parameters, if/while conditions,
etc.) is to indent 8 spaces. I think it actually works pretty well in that
it makes it clear that it's a continuation of the previous line while also
setting it apart from the lines inside the block.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] String encode/decode
So, I take it no-one is working on codecs, is anyone interested in codecs? I've started prototyping a solution patterned on Python (i.e. a tool to generate specific codec modules from the specs). /fredrik 2013/4/9 Fredrik Håård fred...@haard.se Hi all, is anyone working on generic (i.e. iso-*, cp*) string encoding/decoding? I googled and looked through the wiki, but apart from the from/to_bytes and from_to utf-16 I came up with nothing. Are there plans for what it should look like? Also, how come utf-16 has special treatment? -- /fredrik I reject your reality and substitute my own. http://courteous.ly/yp3Zgd -- /f I reject your reality and substitute my own. http://courteous.ly/yp3Zgd ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] String encode/decode
I do. See also the issue #4837 for my initial ad-hoc attempt.
The inevitable problem here is, of course, whether we should reuse the
existing iconv library or make our own. This is also deeply connected
to the assumption that `str` only contains a valid UTF-8 string (which
some standard modules break, `ReaderUtil::each_line` for instance).
Maybe we should start making an wiki page for entire character
encoding issues?
Note: If you copy Python's design (which is actually quite good
compared to many others but not without caveats), try not to copy
`Stream{Reader,Writer}` at least. These are mostly replaced by newer
`Incremental{Reader,Writer}` which doesn't require streams at all.
2013/4/11 Fredrik Håård fred...@haard.se:
So, I take it no-one is working on codecs, is anyone interested in codecs?
I've started prototyping a solution patterned on Python (i.e. a tool to
generate specific codec modules from the specs).
/fredrik
2013/4/9 Fredrik Håård fred...@haard.se
Hi all,
is anyone working on generic (i.e. iso-*, cp*) string encoding/decoding?
I googled and looked through the wiki, but apart from the from/to_bytes
and from_to utf-16 I came up with nothing. Are there plans for what it
should look like?
Also, how come utf-16 has special treatment?
--
/fredrik
I reject your reality and substitute my own.
http://courteous.ly/yp3Zgd
--
/f
I reject your reality and substitute my own.
http://courteous.ly/yp3Zgd
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] String encode/decode
Le 11/04/2013 16:30, Fredrik Håård a écrit : So, I take it no-one is working on codecs, is anyone interested in codecs? Hi, A while ago I started implementing in Rust the WHATWG Encoding specification: http://encoding.spec.whatwg.org/ In addition to the actual algorithms (and precise error handling), the spec defines a set of labels that should be used for legacy web content. For example, when getting 'Content-Type: text/html;charset=ISO-8859-1', it’s the Windows-1252 encoding that should actually be used. It’s also important that labels *not* on the list are not supported. UTF-7 for example has known security issues. Servo will need this eventually. A general-purpose library might want to support encodings that are not supported on the web, such as UTF-32. One should be careful to provide a separate API, so as not to expose these encodings to the web. My implementation is very much incomplete and kind of abandoned at the moment. I expect to start working on it again in the next few months. If someone wants to take it up in the meantime, feel free to do so. Or start from scratch, there really isn’t much there. https://github.com/SimonSapin/rust-webencodings I've started prototyping a solution patterned on Python (i.e. a tool to generate specific codec modules from the specs). What does patterned on Python mean? -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Crossplatform compatibility
Hi! I'm going to create Rust installation package for Mac OS X. Right now you can find the installer there: http://www.sysdev.me/public/RustInstaller.pkg.zip But... I've build the installer on 10.8 and when I'm running it on 10.7 result is: Segmentation fault: 11 Is it possible to build Rust on 10.8 and run it on other 10.x systems? Regards, Alexander ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] String encode/decode
2013/4/11 Kang Seonghoon some...@mearie.org
I do. See also the issue #4837 for my initial ad-hoc attempt.
The inevitable problem here is, of course, whether we should reuse the
existing iconv library or make our own.
iconv is dependent on locales on Unix / mingw on Windows I believe?
This is also deeply connected
to the assumption that `str` only contains a valid UTF-8 string (which
some standard modules break, `ReaderUtil::each_line` for instance).
That str only contains valid UTF-8 is good assumption (and rule) I believe;
to me it seems Python 3 got that right and Rust could use the same pattern
of str vs [u8].
I'm not sure that I see the problem here.
Maybe we should start making an wiki page for entire character
encoding issues?
+1
Note: If you copy Python's design (which is actually quite good
compared to many others but not without caveats), try not to copy
`Stream{Reader,Writer}` at least. These are mostly replaced by newer
`Incremental{Reader,Writer}` which doesn't require streams at all.
Right now my goal is just to create a charmap from the specification, and
start with creating a codec that can handle u8-char. I need to get a much
better feel for Rust/stdlib before I have a solid opinion on high-level
design choices.
/fredrik
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] String encode/decode
2013/4/11 Simon Sapin simon.sa...@exyr.org Le 11/04/2013 16:30, Fredrik Håård a écrit : So, I take it no-one is working on codecs, is anyone interested in codecs? Hi, A while ago I started implementing in Rust the WHATWG Encoding specification: http://encoding.spec.whatwg.**org/ http://encoding.spec.whatwg.org/ Sorry if I was unclear; I meant a general-purpose codec for handling ftp://ftp.unicode.org/Public/MAPPINGS/** more or less. Web stuff is out of scope for what I intend here (Although my 'penultimate' goal is to be able to implement MIME so that email handling can be implemented). I've started prototyping a solution patterned on Python (i.e. a tool to generate specific codec modules from the specs). What does patterned on Python mean? I meant 'following the same pattern as Python'. Might mean something else or nothing at all though, I'm not a native English speaker =) /fredrik ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Scheduling for blocking foreign calls
Hi, I am considering Rust for a particular use case in which I would be doing lots of concurrent requests that would spend most of their time blocked on network I/O in foreign C calls. I may be mistaken but I think a task that blocks like this would block any other tasks on the same scheduler - is that correct? What would perhaps be a good solution would be something like a task pool in which each task runs in a separate OS thread - is there a straightforward way to achieve this? Thanks, Jeremy ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Scheduling for blocking foreign calls
On 4/11/13 2:36 PM, Jeremy Huffman wrote: Hi, I am considering Rust for a particular use case in which I would be doing lots of concurrent requests that would spend most of their time blocked on network I/O in foreign C calls. I may be mistaken but I think a task that blocks like this would block any other tasks on the same scheduler - is that correct? What would perhaps be a good solution would be something like a task pool in which each task runs in a separate OS thread - is there a straightforward way to achieve this? There is `std::task_pool` for this purpose. There is an example of this use case in the test case in that file. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Crossplatform compatibility
On Thu, Apr 11, 2013 at 2:58 PM, Alexander Stavonin a.stavo...@gmail.comwrote: Hi! I'm going to create Rust installation package for Mac OS X. Right now you can find the installer there: http://www.sysdev.me/public/RustInstaller.pkg.zip But... I've build the installer on 10.8 and when I'm running it on 10.7 result is: Segmentation fault: 11 Is it possible to build Rust on 10.8 and run it on other 10.x systems? That's a fair question. A Mach-O binary has a load command that specifies the minimum version of OS X it supports, and is settable by Apple's gcc/clang front end by passing the flag -mmacosx-version-min. I don't know what level of control we are given by rustc for such things, so I'm interested in the answer to this as well. Regards, Alexander ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
