Skip to content

Explain in FromStrs docs that you can't use a lifetime #47757

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

Closed
steveklabnik opened this issue Jan 25, 2018 · 9 comments
Closed

Explain in FromStrs docs that you can't use a lifetime #47757

steveklabnik opened this issue Jan 25, 2018 · 9 comments
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. P-medium Medium priority

Comments

@steveklabnik
Copy link
Member

Inspired by https://www.reddit.com/r/rust/comments/7syu6z/where_do_you_declare_a_lifetime_for_fromstrerr/, but i've seen it crop up a few times. We should put something in the docs.

@steveklabnik steveklabnik added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Jan 25, 2018
@steveklabnik
Copy link
Member Author

@GuillaumeGomez is there any particular reason you nominated this issue?

@jkordish jkordish added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 23, 2018
@RReverser
Copy link
Contributor

I really wish this would be fixed by introducing a lifetime in FromStr trait instead. This would still allow to implement it for structures that don't borrow data, but would also enable it for structures that do.

This would be a breaking change though, so maybe in a new Rust edition?

@steveklabnik
Copy link
Member Author

steveklabnik commented Jun 28, 2018 via email

@RReverser
Copy link
Contributor

So there is no escape hatch for stdlib to fix already existing API issues like Rust editions fix syntactic ones?

@oli-obk
Copy link
Contributor

oli-obk commented Jun 29, 2018

Would it still be a breaking change if the lifetime "defaulted" to 'static? Generics can already default to specific types (thus allowing libstd types to add more generic args). Seems like a reasonable extension to allow the same for lifetimes.

Anyway, this is is off topic, it should definitely be documented for now.

@RReverser
Copy link
Contributor

@oli-obk Yeah I was thinking about it too, but didn't suggest because it also requires syntactic change.

@steveklabnik
Copy link
Member Author

Would it still be a breaking change if the lifetime "defaulted" to 'static?

How would this work? That would let you do this for &'static strs, but not other &strs, no?

@oli-obk
Copy link
Contributor

oli-obk commented Jun 29, 2018

How would this work? That would let you do this for &'static strs, but not other &strs, no?

Note quite, i'm not talking about the input:

trait FromStr<'a = 'static> {
    fn from_str<'b>(s: &'b str) -> Self where 'a: 'b;
}

struct Foo<'b>(&'b str);
struct Bar(String);

impl FromStr for Bar {
    fn from_str(s: &str) -> Self {
        Bar(s.to_owned())
    }
}

impl<'c> FromStr<'c> for Foo<'c> {
    fn from_str(s: &'c) -> Self {
        Foo(s)
    }
}

Changing fn from_str(s: &str) -> Self to essentially fn from_str<'b>(s: &'b str) -> Self where 'static: 'b; should be backwards compatible

@steveklabnik
Copy link
Member Author

steveklabnik commented Jun 29, 2018

trait FromStr<'a = 'static> {

This isn't a language feature yet, I guess that's why I'm confused; I see now. Thanks :)

@steveklabnik steveklabnik added the P-medium Medium priority label Dec 27, 2018
steveklabnik added a commit to steveklabnik/rust that referenced this issue Jan 10, 2019
Centril added a commit to Centril/rust that referenced this issue Jan 12, 2019
…crum

note that FromStr does not work for borrowed types

Fixes rust-lang#47757
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. P-medium Medium priority
Projects
None yet
Development

No branches or pull requests

5 participants