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

impl traits in consts through const fns are allowed but shouldn't #87277

Closed
spastorino opened this issue Jul 19, 2021 · 8 comments
Closed

impl traits in consts through const fns are allowed but shouldn't #87277

spastorino opened this issue Jul 19, 2021 · 8 comments
Labels
F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@spastorino
Copy link
Member

The following code compiles after #87141 but shouldn't

#![feature(const_impl_trait)]
#![feature(min_type_alias_impl_trait)]

type Foo = impl Send;

struct A;

const VALUE: Foo = value();

 const fn value() -> Foo {
     A
 }

fn main() {
}
@spastorino spastorino added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. F-min_type_alias_impl_trait F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` labels Jul 19, 2021
@tyranron
Copy link

tyranron commented Aug 4, 2021

@spastorino could you please clarify why this should be forbidden? Seems like a nice feature to have, keeping in mind that there is a lot of anonymous types usages in Rust code.

@spastorino
Copy link
Member Author

Ohh sorry for the lack of explanation, to be clear, this should be supported at some point. We were in the middle of removing impl traits in bindings for min_taits and the example in this issue is part of that combo that we were removing. In that sense is that it shouldn't work, because we were removing it's support. At some point when let bindings are reintroduced this example should work :). Sorry for the lack of context provided.

@oli-obk maybe you want to add a bit more info here.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 5, 2021

We are trying to avoid any and all mentions of traits other than Sized from const fn until we have a proper story here. you can't use the result of an impl trait returning const fn within another const fn anyway, so the usefulness is limited.

@clarfonthey
Copy link
Contributor

Are there any particularly challenging caveats here or does this just need const expressions to have a "type filter" that forbids TAIT types?

@oli-obk
Copy link
Contributor

oli-obk commented Oct 28, 2021

well.. I have recently come around to "just allowing trait bounds" in const stuff and requiring explicit const bounds (placeholder syntax ~const right now on nightly). So if we can RFC that, we can get function pointers, impl trait and dyn trait all in const fn, and they'll just not be callable from within the const fn.

@clarfonthey
Copy link
Contributor

I guess that my main reason for asking is that this seems like the biggest blocker for getting TAIT stabilised in at least a minimal form, and I'm mostly looking for what needs to be done before I can have nameable, zero-sized function types, which requires TAIT for the moment.

Am currently trying to figure out whether it would be easier to get TAIT stabilised, or figure out some feature to add named function types that doesn't require TAIT and implementing that. Definitely leaning toward the former, but mostly just wanna figure out the details.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 28, 2021

I would presume that TAIT in const (without the ability to call methods on it) would be faster to stabilize, since it's already fully implemented and "just" needs stabilization.

@oli-obk
Copy link
Contributor

oli-obk commented Apr 4, 2022

We have stabilized -> impl Trait on const fn, so there is no reason to forbid TAITs.

Closing as there is no further action required here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Development

No branches or pull requests

4 participants