Cleaned up, documented, wrote tests for std::bool

[Kimundi]

Additionally:

• Sorted the prelude reexports
• Removed unused import warning in std::mem and cleaned it up too

(I was bored 👻 )

[thestinger]

I think the value of duplicating the standard operator traits is questionable but I've never been sure enough to go ahead and remove these functions.

[alexcrichton]

I think that this may show up with a lot of slashes on the documentation of FromStr for bool, could you check to make sure that this doesn't show up?

[alexcrichton]

Looks good to me! So long as the rustdoc documentation looks OK, r+

[huonw]

This function seems extremely removable, as does is_false and the various operator wrappers.

[huonw]

Especially now that we have a trait & they are methods.

[Kimundi]

The rustdocs look fine, those kinds of comment decorators get filtered out. :)

[Kimundi]

A general note to the 'useless' functions and methods and, or, xor, is_false, is_true etc:

I completely agree that they serve no practical purpose for anyone who has used a C-like language for more than half an hour. But I think their existence can still be justified:

• They serve as an excellent example for newcomers of how you can add methods to even build-in primitive types
• They can be useful for function compositions
• They are very low maintenance
• They are good for example and toy code
• Sometimes an foo().is_true() reads better, even if it is not necessary.

Ideally we could just implement the freestanding functions as methods on bool directly once, and call them like freestanding ones using unified function call syntax, but we're not there yet. The lack of unified call syntax is also the reason why I kept both sets of functions and methods for now; otherwise they would become even less useful than they already are.

If those are weak reasons, I might also just remove them, but I don't see any harm in keeping them.

---

Related, I added the BitAnd, BitOr and BitXor impls so that bools can be used in generic code that uses them. I though that was in general how we handle the situation with types that implement an operator natively?

[huonw]

They serve as an excellent example for newcomers of how you can add methods to even build-in primitive types

They are good for example and toy code

Probably better served by examples written expressly for these purposes (e.g. in a trait tutorial).

They can be useful for function compositions

You mean like foo().and(bar().or(baz()) rather than foo() & (bar() | baz())?

They are very low maintenance

But it's non-zero: e.g. keeping the doc examples up-to-date.

Sometimes an foo().is_true() reads better, even if it is not necessary.

This is a little like people doing if blah() == True: in Python... I think this is an ugly & pointless antipattern. (... this would also leave us with

if (blah().is_true() == is_true(true)) == is_false(true.is_true()) { ... }

being legal.)

I don't see any harm in keeping them

They make this file 600 lines with a plethora of weird and wonderful and useless functions & methods, rather than keeping it simple, and the bool API really doesn't need to be huge and complicated like this.

I though that was in general how we handle the situation with types that implement an operator natively?

This is correct.

---

I'm not too fussed about keeping the .and, .xor and .or methods, since they make the eagerness properties clearer, but I definitely think the freestanding functions and the is_ functions need to go.

[Kimundi]

Okay then, removed the unnecessary functions and methods.

Nothing else used them anyway, and we'll probably get unified function call syntax before someone wants to.

[adrientetar]

@Kimundi Can you squash your changes in one commit?
If we were to merge this in its current state we'd have a commit that adds stuff that gets removed by the commit that follows, in other words, ghost changes. This is dirty and should be avoided.

[Kimundi]

@adridu59: Done.