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

Apply coercion rules on return expressions #12755

Closed
arjantop opened this issue Mar 7, 2014 · 8 comments
Closed

Apply coercion rules on return expressions #12755

arjantop opened this issue Mar 7, 2014 · 8 comments
Labels
P-medium Medium priority

Comments

@arjantop
Copy link
Contributor

arjantop commented Mar 7, 2014

Asked on reddit

I have a program where I want to select from two fields (int in this example, io::Writer in practice). It is not possible to return a in a way the program compiles.

Reborrowing was suggested (&mut *self.a) but you can't do that with io::Writer references.

pub struct Foo<'a> {
    priv a: &'a mut int,
    priv b: int,
    priv take_a: bool
}

impl<'a> Foo<'a> {
    fn take(&'a mut self) -> &'a mut int {
        if self.take_a {
            self.a
        } else {
            &mut self.b
        }
    }
}
@alexcrichton
Copy link
Member

cc @nikomatsakis

@nikomatsakis
Copy link
Contributor

At present you need to write:

pub struct Foo<'a> {
    priv a: &'a mut int,
    priv b: int,
    priv take_a: bool
}

impl<'a> Foo<'a> {
    fn take(&'a mut self) -> &'a mut int {
        if self.take_a {
            &mut *self.a
        } else {
            &mut self.b
        }
    }
}

fn main() { }

Note that I returned &mut *self.a and not self.a. These two expressions are equivalent but how the type system thinks about them is not. That said, there is a bug here, because we normally automatically insert these kinds of "reborrow coercions" -- but we don't apply our coercion rules on return. I think we ought to, though. I don't seen an open bug on this, though. I think I'll repurpose this issue.

@nikomatsakis
Copy link
Contributor

Nominated. Adding to meeting agenda as this would be a user-visible change, though I don't expect controversy.

@nikomatsakis
Copy link
Contributor

To be clear: my suggestion is 1.0 but not backwards compat (I think this change would make the language strictly more accepting)

@flaper87
Copy link
Contributor

flaper87 commented Mar 8, 2014

cc @flaper87

@pnkfelix
Copy link
Member

Assigning P-high (but not 1.0; it won't kill us if we don't have it).

@nrc
Copy link
Member

nrc commented Jun 11, 2014

Fixing this as part of the DST work

@nrc nrc mentioned this issue Jun 11, 2014
23 tasks
@nrc
Copy link
Member

nrc commented Sep 23, 2014

This has landed now

@nrc nrc closed this as completed Sep 23, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
fix: Set server binary version when distributing
flip1995 pushed a commit to flip1995/rust that referenced this issue May 17, 2024
…et,GuillaumeGomez

Allow more attributes in `clippy::useless_attribute`

Fixes rust-lang#12753
Fixes rust-lang#4467
Fixes rust-lang#11595
Fixes rust-lang#10878

changelog: [`useless_attribute`]: Attributes allowed on `use` items now include `ambiguous_glob_exports`, `hidden_glob_reexports`, `dead_code`, `unused_braces`, and `clippy::disallowed_types`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-medium Medium priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants