Skip to content
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

Remove remark about poor code style #37503

Merged
merged 2 commits into from
Nov 12, 2016
Merged

Remove remark about poor code style #37503

merged 2 commits into from
Nov 12, 2016

Conversation

nwin
Copy link
Contributor

@nwin nwin commented Oct 31, 2016

The current wording seems to be confusing. As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.

The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.
@rust-highfive
Copy link
Collaborator

r? @Manishearth

(rust_highfive has picked a reviewer for you, use r? to override)


It is considered poor style to implement methods on such primitive types, even
though it is possible.
implement a trait for any type such as `i32`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leave the example in I guess?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. Then I would suggest to change the implementation to

impl HasArea for i32 {
    fn area(&self) -> f64 {
        println!("this is silly");

        0.0
    }
}

to depict the silliness of calculating the area of a scalar.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about .squared()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would actually be bad style (imho). One cannot implement a meaningful area for i32, only for the newtype struct Square(i32). This is why I wanted to remove the example altogether because that possibly lengthy discussion is out of scope of that particular paragraph.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nwin Can you suggest an alternative non-silly example that we could put here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could make up a trait like Complex and output the real and imaginary part in two methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just come up with a better idea.

trait ApproxEqual {
    fn approx_equal(&self, other: &Self);
}
impl ApproxEqual for f64 {
    fn approx_equal(&self, other: &Self) {
        // Impementation to be improved for the actual example
        // Only valid for numbers close to 1.0
        (self - other).abs() < ::std::f64::EPSILON 
}

@Manishearth
Copy link
Member

r? @steveklabnik who wrote this I think

@steveklabnik
Copy link
Member

I did write this, but I really think it's still unclear if this kind of
thing is okay or not, overall. So part of me feels like that is a "remove
it" but another part of me feels like doing nothing is the right choice.

@rust-lang/docs thoughts here? Also maybe @rust-lang/libs.

On Mon, Oct 31, 2016 at 3:01 PM, Manish Goregaokar <notifications@github.com

wrote:

@Manishearth commented on this pull request.

In src/doc/book/traits.md #37503:

-}

-impl HasArea for i32 {

  • fn area(&self) -> f64 {

- println!("this is silly");

  •    *self as f64
    
  • }
    -}

-5.area();
-```

-It is considered poor style to implement methods on such primitive types, even
-though it is possible.
+implement a trait for any type such asi32.

How about .squared()?


You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#37503, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABsivx9-NZSbpRaVW9AfDSlR1tskO_pks5q5jscgaJpZM4KlXJr
.

@Manishearth
Copy link
Member

Also cc @llogiq @mcarton @oli-obk because acceptable code style is also a clippy thing.

@GuillaumeGomez
Copy link
Member

That's a subject which comes often lately. So, I'm for a rewriting, not a removal.

@nwin
Copy link
Contributor Author

nwin commented Nov 4, 2016

I’ve updated the example.

let diff = (self - other).abs();
let (a, b) = (self.abs(), other.abs());
let largest = if a > b { a } else { b };
if diff <= largest * ::std::f32::EPSILON {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove the if and { true } else { false } and get the same result.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. 🙈

@alexcrichton
Copy link
Member

@steveklabnik I may be missing the context here, but I wouldn't consider it poor style to implement traits for primitive types. Rather, implementing traits for primitive types is great as you can enhance what they can do.

Is this referring to something specific, though? Such as implementing inappropriate traits for integers? (e.g. what does it mean for an i32 to have an area?)

In any case looks like there aren't many other opinions, so thoughts about approving/closing @steveklabnik?

@alexcrichton alexcrichton added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Nov 10, 2016
@sfackler
Copy link
Member

I think the poor style comment may source from Rust's general avoidance of Ruby-style things like 5.times(|i| foo) or 10.minutes().

@steveklabnik
Copy link
Member

@alexcrichton as I said on reddit:


Hey there! I wrote this, so figure I should chime in.

So, the first thing I'll say is this: what's 'good style' and not can evolve over time. I wrote this text in December of 2014, almost two years ago. When I wrote it, I remembered writing stuff like Rust is surprisingly expressive, which got a really, really bad reception. People really don't like putting DSL-like methods on primitive types. That said, sometimes, some traits make sense. It just depends, this isn't a super hard-and-fast rule.

The points people make in this thread pretty much cover the debate.


impl ApproxEqual for f32 {
fn approx_equal(&self, other: &Self) -> bool {
// Approximately correct implementation. See also:
// https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

linking to external URLs like this is generally discouraged; we try not to even link to wikipedia.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we might not even really need to implement a body here, given that it's really not about how this is done.

@steveklabnik
Copy link
Member

I feel 50/50 about it. The original text may be a bit too strongly worded, and have a bad example, but this example is fine. so i guess i'm leaning towards merge

@alexcrichton
Copy link
Member

@steveklabnik ah ok thanks for clarifying! Sounds good to me!

@steveklabnik
Copy link
Member

@rust-lang/docs what do you think about my two review comments here?

@GuillaumeGomez
Copy link
Member

I'll said about external urls might sound a bit sad but:

  1. Never (external resources might be changed/moved/removed).
  2. If you have something to explain, write it down.

I don't have much opinion on @steveklabnik's second point except maybe that the example sounds more complicated that it should.

@nwin
Copy link
Contributor Author

nwin commented Nov 11, 2016

Ok, points taken, I simplified the example such that the describing comment can be kept simple.

@steveklabnik
Copy link
Member

@bors: r+ rollup

thank you so much!

@bors
Copy link
Contributor

bors commented Nov 11, 2016

📌 Commit 5cf07f1 has been approved by steveklabnik

eddyb added a commit to eddyb/rust that referenced this pull request Nov 11, 2016
Remove remark about poor code style

The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.
eddyb added a commit to eddyb/rust that referenced this pull request Nov 12, 2016
Remove remark about poor code style

The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.
bors added a commit that referenced this pull request Nov 12, 2016
@bors bors merged commit 5cf07f1 into rust-lang:master Nov 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants