New FAQ entries

We have several new FAQs filled out:

Please give them a read and see what makes sense or doesn't. If you see anything you'd like changed please file a PR against the website.

These were created by @alilleybrinker, maintainer of all things FAQ. Thanks @alilleybrinker.

3 Likes

Reading the "How can I write a function that accepts both &str and String?" What I have been doing when I just need a slice is just declaring the method with &str:

fn foo(s : &str) {
println!("{}", s);
}

And then just pass the reference to the string:

fn main() {
   foo(&String::from("abc"));
}

How does that compare with the AsRef method?

I'm also not quite clear on when exactly I should use Into and Cow. Is there some performance overhead I avoid with the Cow version?

The answers to "Why do Rust programs use more memory than C?" are mostly answers to "Why are Rust programs larger than C?" The only answer that mentions "memory" is in the standard library....all the rest refer to binary size. So maybe the question should be changed?

3 Likes

Preincrement and postincrement (and the decrement equivalents), while
convenient, are also fairly complex. They require knowledge of
evaluation order, and often lead to subtle bugs and undefined behavior
in C and C++. x = x + 1 or x += 1 is only slightly longer, but unambiguous.<

In my opinion the ++ and -- operators are OK if they are used only postfix and they return void or (). See the Go language FAQ ( Frequently Asked Questions (FAQ) - The Go Programming Language ):

Why are ++ and -- statements and not expressions? And why postfix, not prefix?

Without pointer arithmetic, the convenience value of pre- and postfix
increment operators drops. By removing them from the expression
hierarchy altogether, expression syntax is simplified and the messy
issues around order of evaluation of ++ and --
(consider f(i++) and p[i] = q[++i])
are eliminated as well. The simplification is
significant. As for postfix vs. prefix, either would work fine but
the postfix version is more traditional; insistence on prefix arose
with the STL, a library for a language whose name contains, ironically, a
postfix increment.

@pixel:

AsRef<str> is considered better style, I believe. A user could define a new type, implement AsRef<str> for that type, and then pass the type to any function with an AsRef<str> bound.

An alternative is to implement Deref<target=str> for the type, which would then allow the compiler to coerce a reference to the type into a reference to str (which is the behavior you're using in the example provided). With this, you can pass a reference to your type to a function expecting a &str, and things will work as expected.

Also, you're probably right about the question wording. I'll put up a PR to fix it.

@leonardo:

If you feel strongly about it, open an RFC (unless there's already been an RFC. I just did a cursory look and didn't find one)!

@brson:

Well, that title makes me sound all fancy. As always, working on the FAQ is great.

I think Go-style ++ and -- are a bit useful when you translate C/C++/Java/C#/D code to Rust, to modify less lines of code. It could also be handy to advance enumerated values, as in Ada language.

But I don't actually need ++ and --, so no need for a RFC. The features I'd (perhaps!) like in Rust are few and more important :slight_smile:

I'm not sure it's this clear-cut: it's more complex, for a bit more extensibility.

1 Like

Good point yeah. Do you want to open a PR?

But if you do that you loose most of the interest of the syntax. The only purpose of this syntax would be to save 2 key strokes. I don't think it worth having two syntaxes.

It is the same problem than the ternary operator.

I have comments for four of these questions/answers:

  • On feature gates: it's unclear to me whether this question covers the generic cargo feature capability, or the specific rustc feature feature, and/or how there's a difference. Might be worth covering either here or near?

  • On the string types to use, the table order and the explanation order are different (exchanging OS strings and C strings). I suggest that it might be better to keep the same order, to prevent confusion in sloppy/busy readers.

  • On what string types to use, this is really great! I wonder if this information is linked clearly enough from the book/reference/by example documentation.

  • On using more memory, I'll echo the answer from pixel about memory use/binary size. Also, in the section on Monomorphization, I think it might be valuable to reference C++ templates as a similar mechanism. The section titles seem to use Capitals For Every Word for no particularly good reason, and IMO "jemalloc" should be all-lowercase even in the section title.

Sorry for all the nits, hope there's something useful here! On balance, all of these seem really useful additions.