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

Rename extensions to methods in libs #2371

Closed
brson opened this issue May 9, 2012 · 3 comments
Closed

Rename extensions to methods in libs #2371

brson opened this issue May 9, 2012 · 3 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone

Comments

@brson
Copy link
Contributor

brson commented May 9, 2012

methods is shorter, maybe more descriptive

@graydon
Copy link
Contributor

graydon commented May 9, 2012

Agreed

@nikomatsakis
Copy link
Contributor

Actually I'm wondering if both names aren't wrong. One problem I'm finding in practice is that if all impls have the same name, it's hard to sort out what you want to use and what you want to export.

Here is the scenario I'm talking about:

import result::{result, methods}; // something I use

export foo, methods;

type foo = ...;
impl methods for foo { ... }

I am wondering if it wouldn't be better to name the impl after the type in question. Then you could (easily) export just the methods for your type and not others, and you can use a type and its methods by doing:

import some_type::some_type;

All that said, I suppose that #1893 addresses this too:

import result::{result, methods}; // something I use

pub type foo = ...;
pub impl methods for foo { ... }

That's another benefit of #1893 I hadn't considered.

So I don't know, maybe methods is best after all---anyhow, just tossing this out there.

@graydon
Copy link
Contributor

graydon commented Aug 9, 2012

Closing this since separately-named impls are going away. Reopen if you think I misunderstood.

@graydon graydon closed this as completed Aug 9, 2012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 8, 2024
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 8, 2024
…71, r=blyxyas

Add regression ui test for rust-lang#2371

Fixes rust-lang#2371.

rust-lang#2371 seems to already be handled correctly in the lint. This PR adds a ui regression test so we can close it.

r? `@blyxyas`

changelog: Add regression ui test for rust-lang#2371
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants