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

Tracking issue for `associated_consts` feature #29646

Closed
aturon opened this Issue Nov 5, 2015 · 103 comments

Comments

@aturon
Member

aturon commented Nov 5, 2015

The feature is currently quite buggy, but this issue tracks its eventual stabilization.

Shortcomings of the current implementation

Associated consts in const expressions must be concrete

Associated consts can only be used in const contexts if their input types are fully concrete. That is, this works:

trait Foo {
     const X: usize;
}

impl Foo for () {
     const X = 0;
}

let y: [i32; <() as Foo>::X];

But this does not work:

fn foo<T: Foo>() {
    let y: [i32; <T as Foo>::X];
}

Associated consts are never object safe

Associated consts make a trait non-object-safe. There is no way to bound the const where Self: Sized, nor to specify the const when creating the object.

trait Foo {
    const FOO: i32;
}

// Not allowed:
Box<Foo<FOO = 0>>

trait Bar {
    // Not allowed
    const BAR: i32 where Self: Sized;
}

Associated consts referencing other associated consts have spurious destructor warnings

This works:

trait Foo {
    const FOO: Option<i32>;
}

trait Bar: Foo + 'static {
    const BAR: Option<i32> = <Self as Foo>::FOO;
}

But this does not, because we (unnecessarily) assume the const could be a variant that runs a destructor:

trait Foo {
    const FOO: Option<String>;
}

trait Bar: Foo + 'static {
    const BAR: Option<String> = <Self as Foo>::FOO;
}

@skade skade referenced this issue Dec 1, 2015

Merged

Move to stable #10

homu added a commit to autumnai/collenchyma that referenced this issue Dec 2, 2015

Auto merge of #10 - skade:move-to-stable, r=hobofan
Move to stable

This PR removes unnecessary use of feature flags that bar using Rust on stable([1])([2]) compilers.

Reasons being:
* associated consts (Tracking issue: rust-lang/rust#29646) are currently buggy and can be replaced by an fn in that case.
* associated_type_defaults can be removed without breakage
* unboxed_closures can be removed without breakage
* StaticMutex has an uncertain future (rust-lang/rust#27717) and can be emulated in that case by using `lazy_static!` (correct me if I'm wrong)

Finally, I must admit that I didn't get the test suite running quickly.

([1]) Outstanding: this doesn't _quite_ work on stable yet, as some APIs in use are currently making their way through beta, so they are not feature gated, but also not available in 1.4.0. 1.5.0 beta works and as 1.5.0 is 2 weeks away, this is probably not worth the effort.
([2]) rblas is not on stable yet, see mikkyang/rust-blas#12 for that. You can use that version of rust-blas by checking it out from my https://github.com/skade/rust-blas/ and dropping the following `.cargo/config` in your repository:

```
paths = ["/path/to/rblas/checkout"]
```
@raindev

This comment has been minimized.

Show comment
Hide comment
@raindev

raindev Feb 13, 2016

Contributor

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose? Given that Rust have default methods it shouldn't be much less ergonomic. And combination of monomorphisation and static lifetimes should converge any difference in terms of performance.

Contributor

raindev commented Feb 13, 2016

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose? Given that Rust have default methods it shouldn't be much less ergonomic. And combination of monomorphisation and static lifetimes should converge any difference in terms of performance.

@ketsuban

This comment has been minimized.

Show comment
Hide comment
@ketsuban

ketsuban Feb 16, 2016

Contributor

One notable case is that of the Zero and One traits, which exist solely to confer their constant value to the types which implement them. With associated constants they would be redundant, as Sum and Mul would include the additive and multiplicative identities.

Contributor

ketsuban commented Feb 16, 2016

One notable case is that of the Zero and One traits, which exist solely to confer their constant value to the types which implement them. With associated constants they would be redundant, as Sum and Mul would include the additive and multiplicative identities.

@raindev

This comment has been minimized.

Show comment
Hide comment
@raindev

raindev Feb 16, 2016

Contributor

@ketsuban how would it be different than including zero and one as functions into Sum and Mul traits?

Contributor

raindev commented Feb 16, 2016

@ketsuban how would it be different than including zero and one as functions into Sum and Mul traits?

@raindev

This comment has been minimized.

Show comment
Hide comment
@raindev

raindev Feb 16, 2016

Contributor

Having skimmed through #27739 it looks like there're opinions about the concepts of "zero" and "one" as functions as it may give additional flexibility.

Contributor

raindev commented Feb 16, 2016

Having skimmed through #27739 it looks like there're opinions about the concepts of "zero" and "one" as functions as it may give additional flexibility.

@mitaa

This comment has been minimized.

Show comment
Hide comment
@mitaa
Contributor

mitaa commented Feb 16, 2016

@raindev

Why aren't ordinary functions good enough for the same purpose?

https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md#user-content-expressiveness

@vberger

This comment has been minimized.

Show comment
Hide comment
@vberger

vberger Feb 16, 2016

Contributor

The use of associated consts could make things like bitflags! more pretty in my opinion, by scoping the consts in the name of the bitflags struct, much like enum variants are scoped in the name of the enum.

Contributor

vberger commented Feb 16, 2016

The use of associated consts could make things like bitflags! more pretty in my opinion, by scoping the consts in the name of the bitflags struct, much like enum variants are scoped in the name of the enum.

@Roxxik

This comment has been minimized.

Show comment
Hide comment
@Roxxik

Roxxik Feb 19, 2016

would love to use associated consts for array sizes for example: http://is.gd/VSee6B

struct Something {
    inner: [u8; Something::LENGTH]
}

but this will leave me at E0250

Roxxik commented Feb 19, 2016

would love to use associated consts for array sizes for example: http://is.gd/VSee6B

struct Something {
    inner: [u8; Something::LENGTH]
}

but this will leave me at E0250

@dhardy dhardy referenced this issue Feb 23, 2016

Open

Element serialisation #25

0 of 1 task complete
@Robbepop

This comment has been minimized.

Show comment
Hide comment
@Robbepop

Robbepop Mar 1, 2016

Contributor

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose?

I am not sure about this but I think that associated constants could allow us compile time execution for things similar to non-type template parameters as in C++ which are quite useful. Using functions wouldn't work in the example below since Rust currently has no mechanism to detect if a function can be evaluated at compile-time (constexpr as in C++ or even templates).

Example:
https://gist.github.com/Robbepop/da73db721c22492616f6

If the example above really works (haven't tested it, yet) things like BitFlag or the shown BigInt could be implemented very efficiently - not using the heap at all!

Contributor

Robbepop commented Mar 1, 2016

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose?

I am not sure about this but I think that associated constants could allow us compile time execution for things similar to non-type template parameters as in C++ which are quite useful. Using functions wouldn't work in the example below since Rust currently has no mechanism to detect if a function can be evaluated at compile-time (constexpr as in C++ or even templates).

Example:
https://gist.github.com/Robbepop/da73db721c22492616f6

If the example above really works (haven't tested it, yet) things like BitFlag or the shown BigInt could be implemented very efficiently - not using the heap at all!

@Boddlnagg

This comment has been minimized.

Show comment
Hide comment
@Boddlnagg

Boddlnagg May 28, 2016

Contributor

Is there any ETA on the stabilization of this feature? It would be really useful for something which I'm currently experimenting with, namely the implementation of Windows COM interop: One could add a trait that exposes each interface's GUID and/or class ID as constants, then e.g. this API could be mapped to Rust in a way that takes the to-be-activated class as a type parameter that implements said trait.

Of course I can work on this using nightly, but it would be nice to have some information whether the feature is going to be stabilized in the near future!

Contributor

Boddlnagg commented May 28, 2016

Is there any ETA on the stabilization of this feature? It would be really useful for something which I'm currently experimenting with, namely the implementation of Windows COM interop: One could add a trait that exposes each interface's GUID and/or class ID as constants, then e.g. this API could be mapped to Rust in a way that takes the to-be-activated class as a type parameter that implements said trait.

Of course I can work on this using nightly, but it would be nice to have some information whether the feature is going to be stabilized in the near future!

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 17, 2016

Member

Should we block on #34344? Are there other known bugs? Are there design questions to resolve here?

Member

nrc commented Aug 17, 2016

Should we block on #34344? Are there other known bugs? Are there design questions to resolve here?

@letheed

This comment has been minimized.

Show comment
Hide comment
@letheed

letheed Sep 9, 2016

Contributor

There was a question on the forum here. Looks like a bug to me.

Contributor

letheed commented Sep 9, 2016

There was a question on the forum here. Looks like a bug to me.

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Nov 7, 2016

Contributor

What is status or what would need to be done to stabilize this feature? It would be really helpful in Octavo as it would allow me to provide HMAC without any heap allocations.

Contributor

hauleth commented Nov 7, 2016

What is status or what would need to be done to stabilize this feature? It would be really helpful in Octavo as it would allow me to provide HMAC without any heap allocations.

@seanmonstar

This comment has been minimized.

Show comment
Hide comment
@seanmonstar

seanmonstar Nov 7, 2016

Contributor

@hauleth take a look at the associated-items issues. That contains many of the bugs that exist with associated constants. I imagine many of them would need to be fixed before anyone could consider this feature "stable".

Contributor

seanmonstar commented Nov 7, 2016

@hauleth take a look at the associated-items issues. That contains many of the bugs that exist with associated constants. I imagine many of them would need to be fixed before anyone could consider this feature "stable".

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 11, 2017

Contributor

How can we accelerate this? This is a major feature and it doesn't appear to be moving or have a champion.

This is used by Rocket.

Contributor

brson commented Jan 11, 2017

How can we accelerate this? This is a major feature and it doesn't appear to be moving or have a champion.

This is used by Rocket.

@brson brson added the I-nominated label Jan 11, 2017

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 11, 2017

Contributor

Just nominating to put it in front of eyeballs again.

Contributor

brson commented Jan 11, 2017

Just nominating to put it in front of eyeballs again.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jan 11, 2017

Member

My understanding is that this is waiting on a re-do of const evaluation in the compiler, since it's so buggy. @eddyb ?

Member

steveklabnik commented Jan 11, 2017

My understanding is that this is waiting on a re-do of const evaluation in the compiler, since it's so buggy. @eddyb ?

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jan 11, 2017

Member

"Buggy" is not the best way to put it IMO, "barely does anything at all" is far closer.
@brson You can consider @solson, @oli-obk (both miri) and me (rustc) as unofficial champions (for the past several months) for const-eval-related areas.

Member

eddyb commented Jan 11, 2017

"Buggy" is not the best way to put it IMO, "barely does anything at all" is far closer.
@brson You can consider @solson, @oli-obk (both miri) and me (rustc) as unofficial champions (for the past several months) for const-eval-related areas.

@eddyb eddyb referenced this issue Jan 11, 2017

Open

const fn tracking issue (RFC 911) #24111

1 of 4 tasks complete
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 11, 2017

Contributor

Noted in the op that this is blocked on const_fn.

Contributor

brson commented Jan 11, 2017

Noted in the op that this is blocked on const_fn.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 26, 2017

Contributor

Should block on this bug #26847

Contributor

brson commented Jan 26, 2017

Should block on this bug #26847

@JoeyAcc

This comment has been minimized.

Show comment
Hide comment
@JoeyAcc

JoeyAcc Feb 2, 2017

Out of curiosity, would something like the snippet below work in a recent Rust version? I'm thinking either the most recent stable, or straight up nightly.

#![feature(associated_consts)]

pub struct Foo(/* elided */);

impl Foo {
    pub const MY_CONST: &'static str = "hurr durr I'm a sheep";

    // Other defs elided
}

JoeyAcc commented Feb 2, 2017

Out of curiosity, would something like the snippet below work in a recent Rust version? I'm thinking either the most recent stable, or straight up nightly.

#![feature(associated_consts)]

pub struct Foo(/* elided */);

impl Foo {
    pub const MY_CONST: &'static str = "hurr durr I'm a sheep";

    // Other defs elided
}
@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Feb 2, 2017

Contributor

@JoeyAcc if you need to use feature then 100% it will not work on anything other than nightly.

Contributor

hauleth commented Feb 2, 2017

@JoeyAcc if you need to use feature then 100% it will not work on anything other than nightly.

@JoeyAcc

This comment has been minimized.

Show comment
Hide comment
@JoeyAcc

JoeyAcc Feb 2, 2017

Yes, I understand that. It wasn't quite what I intended to ask.
Rather, I wanted to know if the code above even works at all, since there are apparently still issues with the feature somewhere (and I have no clue where exactly the breakage is currently).
It's more about the "breakage border" (or some rough approximation of it) than which Rust version I should use.
Sorry about the confusion.

JoeyAcc commented Feb 2, 2017

Yes, I understand that. It wasn't quite what I intended to ask.
Rather, I wanted to know if the code above even works at all, since there are apparently still issues with the feature somewhere (and I have no clue where exactly the breakage is currently).
It's more about the "breakage border" (or some rough approximation of it) than which Rust version I should use.
Sorry about the confusion.

@SimonSapin SimonSapin referenced this issue Feb 19, 2017

Open

Tracking issue for 1.0.0 tracking issues #39954

8 of 28 tasks complete
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 19, 2017

Contributor

@mikeyhew The original message cites let y: [i32; <T as Foo>::X]; explicitly an something that does not work. And even if it did, that still doesn’t give integer generics.

Contributor

SimonSapin commented Jul 19, 2017

@mikeyhew The original message cites let y: [i32; <T as Foo>::X]; explicitly an something that does not work. And even if it did, that still doesn’t give integer generics.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Jul 19, 2017

Contributor

@mikeyhew You can follow the progress on that feature on this rfc: rust-lang/rfcs#2000

Contributor

withoutboats commented Jul 19, 2017

@mikeyhew You can follow the progress on that feature on this rfc: rust-lang/rfcs#2000

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Jul 19, 2017

Contributor

@nikomatsakis I think the list of shortcomings is an accurate summary of what doesn't work. What does work is "everything else," isn't it? What is missing from the tracking issue that isn't covered in the new docs for the feature?

Contributor

withoutboats commented Jul 19, 2017

@nikomatsakis I think the list of shortcomings is an accurate summary of what doesn't work. What does work is "everything else," isn't it? What is missing from the tracking issue that isn't covered in the new docs for the feature?

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jul 19, 2017

Member

@mikeyhew That is a different feature, although it does depend on lifting the limitations of array lengths not being able to depend on generic parameters, that were punted on for the stabilization of associated consts (see earlier discussion).

Member

eddyb commented Jul 19, 2017

@mikeyhew That is a different feature, although it does depend on lifting the limitations of array lengths not being able to depend on generic parameters, that were punted on for the stabilization of associated consts (see earlier discussion).

perfah added a commit to perfah/Rustland that referenced this issue Jul 27, 2017

@Object905

This comment has been minimized.

Show comment
Hide comment
@Object905

Object905 Aug 1, 2017

Today found that lifetime in associated consts doesn't defaults to 'static, as it must as according to stabilized in 1.17.0 rfc. So:
trait Foo { const FOO: &str = "dsad"; } gives expected lifetime parameter error, while trait Foo { const FOO: &'static str = "dsad"; } is valid. Same goes for struct, enum and union impl blocks.

Object905 commented Aug 1, 2017

Today found that lifetime in associated consts doesn't defaults to 'static, as it must as according to stabilized in 1.17.0 rfc. So:
trait Foo { const FOO: &str = "dsad"; } gives expected lifetime parameter error, while trait Foo { const FOO: &'static str = "dsad"; } is valid. Same goes for struct, enum and union impl blocks.

@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv Aug 1, 2017

Member

@Object905 Relevant discussion in #38831

Member

frewsxcv commented Aug 1, 2017

@Object905 Relevant discussion in #38831

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 28, 2017

Member

Should this be closed? All boxes are checked off, and #42809 was merged

Member

steveklabnik commented Aug 28, 2017

Should this be closed? All boxes are checked off, and #42809 was merged

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Aug 28, 2017

Member

And it's available in beta AFAICT

Member

shepmaster commented Aug 28, 2017

And it's available in beta AFAICT

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 28, 2017

Member

Yes, it will be in 1.20.

Member

steveklabnik commented Aug 28, 2017

Yes, it will be in 1.20.

@nwin

This comment has been minimized.

Show comment
Hide comment
@nwin

nwin Aug 29, 2017

Contributor

Maybe I’m not seeing the point but as long as “Associated consts in const expressions must be concrete” is still a restriction I do not see any use of associated constants in traits.

Yet you can add them such that all of the error messaged presented in #32344 are still very there and very misleading.

Shouldn’t one simply forbid associated constants in traits unless that restriction is lifted? I dont’t think that it was a good idea merge #42809 (i.e. remove the feature gate) with a feature in such an incomplete state.

Contributor

nwin commented Aug 29, 2017

Maybe I’m not seeing the point but as long as “Associated consts in const expressions must be concrete” is still a restriction I do not see any use of associated constants in traits.

Yet you can add them such that all of the error messaged presented in #32344 are still very there and very misleading.

Shouldn’t one simply forbid associated constants in traits unless that restriction is lifted? I dont’t think that it was a good idea merge #42809 (i.e. remove the feature gate) with a feature in such an incomplete state.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Aug 29, 2017

Member

@nwin It's not "in const expressions" - but rather "in types", i.e. array types.

Member

eddyb commented Aug 29, 2017

@nwin It's not "in const expressions" - but rather "in types", i.e. array types.

@frehberg

This comment has been minimized.

Show comment
Hide comment
@frehberg

frehberg Sep 7, 2017

Contributor

Is there any plan to introduce LEN (or similar attribute) as associated const for the built-in rust-primitives 'arrray' or 'slice'? , for example

const N : usize = b"my_byte_string"::LEN;

or

is there any plan to declare std::intrinsics::size_of_val(v) as const-fn(?) enabling somehing like:
#![feature(core_intrinsics)]
const N: usize = unsafe { std::intrinsics::size_of_val(b"my_byte_string") };

Contributor

frehberg commented Sep 7, 2017

Is there any plan to introduce LEN (or similar attribute) as associated const for the built-in rust-primitives 'arrray' or 'slice'? , for example

const N : usize = b"my_byte_string"::LEN;

or

is there any plan to declare std::intrinsics::size_of_val(v) as const-fn(?) enabling somehing like:
#![feature(core_intrinsics)]
const N: usize = unsafe { std::intrinsics::size_of_val(b"my_byte_string") };

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Sep 7, 2017

Member

@frehberg When const generics are implemented you will be able to do that yourself, for example with an impl<T, const N: usize> MyLenTrait for [T; N]

Member

eddyb commented Sep 7, 2017

@frehberg When const generics are implemented you will be able to do that yourself, for example with an impl<T, const N: usize> MyLenTrait for [T; N]

@robinst

This comment has been minimized.

Show comment
Hide comment
@robinst

robinst Sep 28, 2017

Contributor

Anyone landing here from googling "associated const", this was released in Rust 1.20, see the announcement: https://blog.rust-lang.org/2017/08/31/Rust-1.20.html

Contributor

robinst commented Sep 28, 2017

Anyone landing here from googling "associated const", this was released in Rust 1.20, see the announcement: https://blog.rust-lang.org/2017/08/31/Rust-1.20.html

@robinst

This comment has been minimized.

Show comment
Hide comment
@robinst

robinst Sep 28, 2017

Contributor

Also, if anyone is looking for the documentation of this, it's here: https://doc.rust-lang.org/stable/reference/items.html#associated-constants

(It was surprisingly hard to find.)

Contributor

robinst commented Sep 28, 2017

Also, if anyone is looking for the documentation of this, it's here: https://doc.rust-lang.org/stable/reference/items.html#associated-constants

(It was surprisingly hard to find.)

tokenrove added a commit to tokenrove/fixie-trie that referenced this issue Oct 30, 2017

Make FixedLengthKey levels constant
The last time I looked at this, rust-lang/rust#29646 wasn't finished,
but now it is.  This avoids the possibility of a pathological
implementer of FixedLengthKey returning varying values for levels.

(Thanks Raph!)
@SergioBenitez

This comment has been minimized.

Show comment
Hide comment
@SergioBenitez

SergioBenitez Feb 12, 2018

Contributor

Shouldn't equality bounds be possible with associated consts? The following does not compile today:

trait Foo {
    const BAR: usize;
}

// error: expected type, found `10`
fn f<T: Foo<BAR = 10>>() { }

The original associated items RFC makes it clear that this should be possible. I'm wondering: was this simply forgotten about? Or perhaps there are/were complications with implementing this?

Contributor

SergioBenitez commented Feb 12, 2018

Shouldn't equality bounds be possible with associated consts? The following does not compile today:

trait Foo {
    const BAR: usize;
}

// error: expected type, found `10`
fn f<T: Foo<BAR = 10>>() { }

The original associated items RFC makes it clear that this should be possible. I'm wondering: was this simply forgotten about? Or perhaps there are/were complications with implementing this?

@SergioBenitez

This comment has been minimized.

Show comment
Hide comment
@SergioBenitez

SergioBenitez Feb 16, 2018

Contributor

Furthermore, using an associated const as an array size does not appear to work:

pub trait Can {
    const SIZE: usize;
}

fn f<T: Can>(t: T) {
    // error[E0277]: the trait bound `T: Can` is not satisfied
    let x = [0u8; <T as Can>::SIZE];
}

There error message is clearly wrong, so this is either a bug in rustc or unimplemented functionality resulting in a bogus error message.

Contributor

SergioBenitez commented Feb 16, 2018

Furthermore, using an associated const as an array size does not appear to work:

pub trait Can {
    const SIZE: usize;
}

fn f<T: Can>(t: T) {
    // error[E0277]: the trait bound `T: Can` is not satisfied
    let x = [0u8; <T as Can>::SIZE];
}

There error message is clearly wrong, so this is either a bug in rustc or unimplemented functionality resulting in a bogus error message.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Feb 16, 2018

Member

using an associated const as an array size

Probably related to #42863, #44168, #44774 ?

Member

shepmaster commented Feb 16, 2018

using an associated const as an array size

Probably related to #42863, #44168, #44774 ?

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Feb 17, 2018

Contributor

Furthermore, using an associated const as an array size does not appear to work:

This usage of associated const was not stabilized, as documented in this issue (it doesn't work on nightly either, and probably won't work until const-generics implementation improves).

Contributor

gnzlbg commented Feb 17, 2018

Furthermore, using an associated const as an array size does not appear to work:

This usage of associated const was not stabilized, as documented in this issue (it doesn't work on nightly either, and probably won't work until const-generics implementation improves).

@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Jun 5, 2018

Contributor

I don't know if this is the same issue that @eddyb mentioned here: #29646 (comment)

trait Foo { const A: usize; }
fn foo<F: Foo>(f: F) {
    const B: usize = F::A; // ERROR
    let b = F::A; // OK
}
Contributor

gnzlbg commented Jun 5, 2018

I don't know if this is the same issue that @eddyb mentioned here: #29646 (comment)

trait Foo { const A: usize; }
fn foo<F: Foo>(f: F) {
    const B: usize = F::A; // ERROR
    let b = F::A; // OK
}
@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jun 5, 2018

Member

@gnzlbg Those are two items nested in eachother, we don't allow "inheriting" type parameters in such a situation and it'd be a significant language change to start doing that.
IOW, what you wrote is more or less equivalent to:

const __HIDDEN_B: usize = F::A;
fn foo<F: Foo>(f: F) {
    use self::__HIDDEN_B as B;
}

(and this is not in any way, shape, or form, specific to const or associated const)

Member

eddyb commented Jun 5, 2018

@gnzlbg Those are two items nested in eachother, we don't allow "inheriting" type parameters in such a situation and it'd be a significant language change to start doing that.
IOW, what you wrote is more or less equivalent to:

const __HIDDEN_B: usize = F::A;
fn foo<F: Foo>(f: F) {
    use self::__HIDDEN_B as B;
}

(and this is not in any way, shape, or form, specific to const or associated const)

@zpgaal

This comment has been minimized.

Show comment
Hide comment
@zpgaal

zpgaal Jun 26, 2018

Having const fn is this feature still required ? Of course it'd require to have const fn in traits as well.
(For now no array size can be given using either associated const or const fn)

((Or one could be the desugaring'of the other ))

zpgaal commented Jun 26, 2018

Having const fn is this feature still required ? Of course it'd require to have const fn in traits as well.
(For now no array size can be given using either associated const or const fn)

((Or one could be the desugaring'of the other ))

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jun 26, 2018

Member

@zpgaal this feature is implemented and stable, so regardless of it being "required", it has to stay!

Member

steveklabnik commented Jun 26, 2018

@zpgaal this feature is implemented and stable, so regardless of it being "required", it has to stay!

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Jul 11, 2018

Contributor

@steveklabnik It seems like rustdoc does not generate documentation for associated constants in structs. Is this a bug?

Contributor

vks commented Jul 11, 2018

@steveklabnik It seems like rustdoc does not generate documentation for associated constants in structs. Is this a bug?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 11, 2018

Contributor

@vks I cannot reproduce this. rustdoc a.rs with the code below does document the constant.

pub struct Foo;

impl Foo {
    pub const BAR: u32 = 7;
}
Contributor

SimonSapin commented Jul 11, 2018

@vks I cannot reproduce this. rustdoc a.rs with the code below does document the constant.

pub struct Foo;

impl Foo {
    pub const BAR: u32 = 7;
}
@gnzlbg

This comment has been minimized.

Show comment
Hide comment
@gnzlbg

gnzlbg Jul 11, 2018

Contributor

@SimonSapin I think the problem is:

pub struct Foo;

impl Foo {
    /// This doc comment won't be shown anywhere.
    pub const BAR: u32 = 7;
}
Contributor

gnzlbg commented Jul 11, 2018

@SimonSapin I think the problem is:

pub struct Foo;

impl Foo {
    /// This doc comment won't be shown anywhere.
    pub const BAR: u32 = 7;
}
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 11, 2018

Contributor

Oh I see. Please file a bug separately?

Contributor

SimonSapin commented Jul 11, 2018

Oh I see. Please file a bug separately?

@vks

This comment has been minimized.

Show comment
Hide comment
@vks

vks Jul 11, 2018

Contributor

Oh I see. Please file a bug separately?

See #52260.

Contributor

vks commented Jul 11, 2018

Oh I see. Please file a bug separately?

See #52260.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment