Skip to content

Revert "RFC to require impl MyStruct to be nearby the definition of MyStruct" #735

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Feb 20, 2015

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Jan 26, 2015

The "Revised UFCS proposal", PR #132, makes the restriction imposed by PR #155 unnecessary:

Whenever a path like ...::a::... resolves to a type (but not a trait), it is rewritten (internally) to <...::a>::....

This applies to all non-trait impls, and because <T>::item has to be handled during type-checking, that removes any need to handle impls (or treat them as modules, for that matter) in resolution, eliminating
all the issues #155 was trying to solve by being overly conservative.

@eddyb
Copy link
Member Author

eddyb commented Jan 26, 2015

See also this comment about some of the consequences of UFCS.

@Kimundi
Copy link
Member

Kimundi commented Jan 26, 2015

Sounds good!

@nikomatsakis
Copy link
Contributor

I agree with the sentiment, however there remains some amount of impl work to be done before the arguments in the original RFC no longer apply, no?

@eddyb
Copy link
Member Author

eddyb commented Jan 27, 2015

Yes, hopefully I'll get to it in the next couple of weeks (I already figured out the details).

@netvl
Copy link

netvl commented Jan 27, 2015

Does this mean that it will be possible to write something like

pub struct SomeType { ... }

mod some_functionality {
    use super::SomeType;

    impl SomeType {
        fn do_something(&self) { ... }
    }

    fn free_func() {
        let s: SomeType = ...;
        s.do_something();
    }
}

or maybe even

pub struct SomeType { ... }

mod some_functionality {
    use super::SomeType;

    impl SomeType {
        fn do_something(&self) { ... }
    }
}

fn free_func() {
    let s: SomeType = ...;
    s.do_something();
}

? If so, it is great! It will help structuring programs immensely.

@eddyb
Copy link
Member Author

eddyb commented Jan 27, 2015

@netvl Both work before UFCS if you remove the restriction. I had a PR doing this a while back, it required amending the RFC and I never got back to it.
The difference between those and an impl in the same module is that SomeType::do_something wouldn't work right now (so you only got "extension methods" with that modification of mine).
With UFCS, SomeType::do_something would desugar to <SomeType>::do_something so you couldn't tell them apart.

@brson
Copy link
Contributor

brson commented Jan 29, 2015

👍 but instead of deleting the original RFC, @eddyb can we have a new RFC that reverses the design? It can be pretty short. I'd prefer to leave the RFC for historical purposes.

@eddyb
Copy link
Member Author

eddyb commented Jan 29, 2015

@brson I guess it could be something small explaining how UFCS allows resolution to ignore impls altogether. Will post that once I have an actual implementation.

@brson
Copy link
Contributor

brson commented Feb 20, 2015

Merged.

@eddyb eddyb deleted the revert-155 branch February 20, 2015 06:02
@Centril Centril added the A-typesystem Type system related proposals & ideas label Nov 23, 2018
@Centril Centril added A-impls Implementations related proposals & ideas A-inherent-impl Proposals related to inherent implementations labels Nov 23, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-impls Implementations related proposals & ideas A-inherent-impl Proposals related to inherent implementations A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants