Improve diagnostics regarding how static_in_const doesn't work for associated constants

[clarfonthey]

Example code:

#![feature(associated_consts, static_in_const)]
struct Test;
impl Test {
    const CONST: &str = "Hello, world!";
}

Would default CONST to &'static str if this actually worked for associated constants. The original RFC decided to not do this, so, it makes sense to document the behaviour.

EDIT: the error message should be better, not the docs.

[petrochenkov]

This is intentional, but it seems like the RFC text wasn't updated to accommodate this detail.

[clarfonthey]

@petrochenkov I feel that if that's the case, then the error message should be improved and the RFC text should be updated.

[steveklabnik]

Doc team triage: tagging as p-low because this is for an unstable feature

[frewsxcv]

Would extending static_in_const to work with associated constants be a controversial move? Is there any reason it shouldn't be done other than not explicitly being spelled out in the RFC?

[clarfonthey]

I personally would be careful to only default to 'static if the impl doesn't have any lifetime parameters. But otherwise it'd make sense imho.

[clarfonthey]

Should this still be P-low considering how this feature got stabilised? @steveklabnik

[steveklabnik]

@clarcharr you're right! We should change the prioritization. I'm going to nominate this to be discussed at the docs meeting today.

[steveklabnik]

Doc team triage: the RFC issue in the reference repo rust-lang/reference#9 should be tracking adding this to the reference, so that takes care of the doc requirement.

As such, leaving this to diagnostics now. Removing the p-tag because that's for @rust-lang/compiler to decide.

[nikomatsakis]

@frewsxcv

Would extending static_in_const to work with associated constants be a controversial move? Is there any reason it shouldn't be done other than not explicitly being spelled out in the RFC?

We decided against it because, in that case, there might be other lifetimes you would want. For example:

trait Foo<'a> {
    const T: &'a str;
}

that said, revisiting this explanation, it feel a bit weak, since the value of an associated constant would still have to be all consisting of static data. So it seems like 'static is a pretty good default if you don't say otherwise.

[shepmaster]

So it seems like 'static is a pretty good default if you don't say otherwise.

Yes, please!

[clarfonthey]

Going through old issues on GitHub, I think we can close this. The latest diagnostics for this seem good to me:

error[[E0106]](https://doc.rust-lang.org/stable/error-index.html#E0106): missing lifetime specifier
 [--> src/lib.rs:3:18
](https://play.rust-lang.org/#)  |
3 |     const CONST: &str = "Hello, world!";
  |                  ^ expected named lifetime parameter
  |
help: consider using the `'static` lifetime
  |
3 |     const CONST: &'static str = "Hello, world!";
  |                   +++++++
help: consider introducing a named lifetime parameter
  |
2 ~ impl<'a> Test {
3 ~     const CONST: &'a str = "Hello, world!";
  |