Make trait methods callable in const contexts

[oli-obk]

Please remember to create inline comments for discussions to keep this RFC manageable and discussion trees resolveable.

Rendered

Tracking:

• Tracking issue for RFC 2632, impl const Trait for Ty and ~const (tilde const) syntax (const_trait_impl) rust#67792

[juntyr]

I love it and I’m very excited to get to replace the outlandish const fn + associated const hacksworkarounds I’ve joyfully come up over the last years :D

Thank you for all of the hard work that everyone working on the various implementation prototypes and around has put into const traits!

[letheed]

I didn’t see const implementations in alternatives. Is there a reason they can’t be considered ?

Eg. const impl PartialEq for i32 { … } where only this impl is const, no changes to the trait.

[jackh726]

I think this needs to be expanded on quite a bit more in the main text.

Up until reading this section, I actually hadn't really considered the examples below. I think it's really important describe better the different ways you might use a const (or maybe const) trait both inside and outside of const contexts. The main text does a bit to motivate the need to distinguish between const and maybe-const bounds, but does not really go into why you need the distinguish between maybe-const and not-const bounds. The first example below hints a bit at it, but in my opinion is pretty incomplete. For my own sake, I expanded the first example below to make it work on nightly and to show how the code must change between going from with non-const bounds (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=25b7e140187aca91a5ce377b42f86140) and without (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7ce4396310758e4595704e4228f45d69). Now, what this doesn't do, for me, is show why being able to write the non-const bound version is actually useful. A real-world example would go far here.

---

Now, going into this RFC, I was strongly in favor of this alternative (and still do favor it, though am slightly convinced by the associated const example below), for two reasons:

First, I expect the maybe-const bound to be what users want in the overwhelming majority of cases. In that sense, having "extra" noise to the syntax of bounds results in a reduced user experience. Though, as a counterpoint, the explicitness of them being "different" from what you see elsewhere is nice.

Second, ~const bounds are new weird syntax. And, for many, Rust already has a lot of weird syntax, so we should be wary about adding more. On the contrary, users are already used to ?Sized bounds, so ?const bounds is not that weird or different. I am very unconvinced by argument below that this ~const syntax is "the one folks are used to for a few years now": 1) I expect plenty of people that will eventually use this don't actually use this on nightly 2) being "used to" a syntax does not automatically make it best.

[tgross35]

Second, ~const bounds are new weird syntax. And, for many, Rust already has a lot of weird syntax, so we should be wary about adding more. On the contrary, users are already used to ?Sized bounds, so ?const bounds is not that weird or different. I am very unconvinced by argument below that this ~const syntax is "the one folks are used to for a few years now": 1) I expect plenty of people that will eventually use this don't actually use this on nightly 2) being "used to" a syntax does not automatically make it best.

I was going to write similar will piggyback on this instead. ~const reads to me very strongly as "not" or something along those lines, since ~ is bitwise not in C/++ and indicates a destructor in C++, and I think this is likely to be more understood by users than ~ meaning maybe. Not that we should necessarily base any syntax decisions off of C/++, but I don't know that a percentage of users being familiar with a nightly syntax makes that strong of a case either.

The ? reads much stronger to me as "maybe", as in ?Sized = "maybe sized" and ?const = "maybe const".

This syntax was discussed recently at https://rust-lang.zulipchat.com/#narrow/channel/328082-t-lang.2Feffects/topic/Nadri's.20effect.20elision, and reasons came up for using ~ over ?. However, reading again, I think the reasoning had the assumption that if ~const were changed to ?const then the exact semantics should be updated to nearly the same as ?Sized. That is, changing the syntax would imply const trait by default and ?const trait opts out, similar to Sized by default.

Imo the correlation doesn't need to go that deep though: we can say "read ? as "maybe' ", or "?X opts out of the default state of X", i.e. use the ? sigil with const without changing any behavior here.

[oli-obk]

Yes, in an ideal world we'd do that, I mean, my original RFC from years ago proposed that. But that needs new syntax considering how many ppl are using nonconst bounds on const fns (and not just Copy bounds).

You need those when you just need access to assoc consts or types, or when your struct has bounds, as you need to replicate those on the impls, even if the specific const fns you wrote don't need them.

The reason we gave up on ?const was that we messed up the impl, because we made the impl try to mirror that. Today's impl is ~const, opting into the constness, which is much simpler impl wise. We can invert the syntax, but the impl is opposite that and just how traits work. Yes traits have ?Sized, but that's a thing we regularly get wrong somewhere in the impl, and we already know that adding new opt out traits is a breaking change, just like adding opt out constness would be.

[oli-obk]

Second, ~const bounds are new weird syntax. And, for many, Rust already has a lot of weird syntax, so we should be wary about adding more. On the contrary, users are already used to ?Sized bounds, so ?const bounds is not that weird or different. I am very unconvinced by argument below that this ~const syntax is "the one folks are used to for a few years now":

I didn't say ~const is what they are used to on nightly, but I see the ambiguity. What I meant was folks on stable are used to T: Trait bounds existing and giving you only static access to the trait items.

I'll adjust the text

[fee1-dead]

I argued against using ?const for implicit maybe-const, and opting out for non-const bounds semantics in my comment in the Zulip thread which was mentioned above.

~const reads to me very strongly as "not" or something along those lines, since ~ is bitwise not in C/++ and indicates a destructor in C++, and I think this is likely to be more understood by users than ~ meaning maybe. Not that we should necessarily base any syntax decisions off of C/++, but I don't know that a percentage of users being familiar with a nightly syntax makes that strong of a case either.

I'd say that ?const reads much more strongly as "not" for me, as with ?Sized, so I don't like the idea of using ?const as syntax of what ~const does today. I mainly oppose this because of the dissonance implied in that: adding ?Sized opts-out and relaxes requirements. Suggesting that ?const (used in place of ~const) would "opt-out" of traits being non-const by default is a stretch, especially since it doesn't relax requirements, it makes requirements stricter.

[RalfJung]

Ah, good point. When we see a fn type anywhere outside a function signature we can't tell if this is ever meant to be used in const contexts.

Maybe the defaults should be different for static and dynamic dispatch (the latter being fn() and dyn Trait types), but that could also easily be confusing. The RFC says next to nothing about the vision for dynamic dispatch so it's hard to compare.

[Jules-Bertholet]

(in reply to #3762 (comment))

context-dependent syntax

With your proposal, in a normal fn, : Trait just means “requires Trait”, but in a const fn, it means “requires Trait in non-const context, and const Trait in a const context”. The context of fn vs const fn affects the meaning of the construct.

[RalfJung]

You already said that above, and I already answered it: The meaning of T: Trait under my proposal is always "must be const in const context". Some functions just cannot be called in const context, making the requirement equivalent to "doesn't have to be const". I see no reason to explain this in such a complicated way as you did, and I disagree with the claim that this is context-dependent. We just have the simple rule that the bound, by default, matches the const context (i.e. behaves like ~const) except when you want to change it by saying "must always be const" or "doesn't ever have to be const", which are the less common cases.

[Jules-Bertholet]

less common cases

I don’t think it will be all that uncommon, because of marker traits with no const version. And I think e.g. ?const Copy is far more likely to cause confusion than anything in this RFC’s syntax, on top of being a strict downgrade from the current edition.

[fee1-dead]

The RFC says next to nothing about the vision for dynamic dispatch so it's hard to compare.

My personal thinking is that fn pointers intended to be used in const contexts should be ~const fn, and the same goes for dyn ~const Fn(). That to me makes it much more consistent, as compared to the opt-out which might require a split. That is one of the reasons I support ~const (or any syntax for opt-in) over ?const (or any syntax for opt-out).

[Jules-Bertholet]

Maybe this should just be ~const Drop? Drop bounds in their present form are completely useless, so repurposing them would make sense. Drop would be implemented by every currently existing type, and ~const Drop only by ones that can be dropped in const contexts.

(Overall, very impressed by this RFC. It addresses essentially all the concerns I thought I might have going in. Thank you @oli-obk and team for all your hard work!)

[oli-obk]

Yea that would be neat. But it needs an edition and giving the ppl that needed T: Drop bounds the ability to still do whatever they were doing

[Jules-Bertholet]

the ppl that needed T: Drop bounds

Are there any such people at all? Making more types implement a trait should not be breaking or require an edition, no? Unless there is some useful property (for e.g. unsafe code) that only types that are currently Drop have—and there isn’t, AFAICT. (Plus, removing an explicit Drop impl from a type is usually not considered breaking.)

[compiler-errors]

I still think it's very useful conceptually to split Destruct and Drop since the former is structural and the latter really isn't -- it's more like an "OnDrop" handler. If we moved to ~const Drop, then in order to write a well-formed ~const Drop impl, you need to write where {all of my fields}: ~const Drop in the where clause.

That is to say, there's a very good reason we split ~const Destruct out of ~const Drop in the first place :)

[Jules-Bertholet]

it's more like an "OnDrop" handler.

Yeah, that’s what it is right now, but we could expand its meaning.

in order to write a well-formed ~const Drop impl, you need to write where {all of my fields}: ~const Drop in the where clause.

The bound could always be made implicitly inferred. Drop is extremely magic already, why not a little more?

But actually, I think it’s a good thing that these bounds can be specified explicitly, because it enables library authors to leave room for adding or changing private fields in the future. I could see allowing impl Drop/impl const Drop blocks with no fn drop() method, that serve only to add restrictions on dropping in const contexts. (In today’s Rust, you could use a ZST field for this.)

[fee1-dead]

It would still be possible to change the meaning of : Drop over an edition

Right, so before we have a consensus on how that would look like, having both Destruct and Drop feels completely fine for me. Since we just want to know whether something can be dropped (T: ~const Destruct) and we know that we will accommodate any existing uses of the Drop bound and impls, any reformulating of how that works can still be done through an edition even if we choose to add Destruct here.

[workingjubilee]

Changing how random trait bounds of otherwise typical traits are presented, even over an edition, is not useful. It's not Fn, FnMut, FnOnce, or Sized. The mistake isn't that you can write a Drop bound, it's that Drop was handled by a typical trait, despite having atypical needs, and was not given special treatment to begin with. That is something you cannot simply change over an edition. Otherwise, introducing a magical special case too-late to help is not really for the best.

[Jules-Bertholet]

@workingjubilee Can you elaborate? To be clear, my suggestion is that Drop should be like a normal trait (at least in terms of its trait bounds). The “magical special case” I suggested would be only for old editions, to preserve compatibility for the small number of people relying on the current not-like-a-normal-trait behavior (where a type that satisfies the Drop bound is less capable than one that does not).

[workingjubilee]

??? Perhaps I misunderstood something?

[Jules-Bertholet]

Current Drop: trait bound satisfied only when an explicit impl exists. Such an impl must contain an fn drop(). Adding such an impl makes the type less capable.

Proposed Drop: trait bound always satisfied on new editions (like this RFC’s Destruct). Bare : Drop bounds retain their current behavior on old editions (with a warning), for compatibility. ~const Drop bounds behave like this RFC’s ~const Destruct on all editions. Conceptually: when implementing Drop manually, you override the default impl (like with an auto trait). An explicit impl may specify ~const bounds, or an fn drop() handler. Adding such a handler implicitly (a) makes the type ineligible for destructuring, and (b) unimplements auto trait TrivialDrop.

[matthieu-m]

How difficult would it be to support const associated functions in traits from the get go?

trait Foo {
    const fn ctfe();
    
    fn runtime();
}

There's already significant support for const functions today:

• Functions can be declared const, and invoked at compile-time.
• const trait functions can be invoked at compile-time.

As an observer it seems a bit bizarre to me to launch const traits without support for const associated functions, which is likely to lead to churn in the ecosystem, rather than "close the gap" first.

But being just an observer, maybe I'm just misunderstanding how much work there would be to bring const associated functions?

Note: I do understand we don't have them today, I merely think the RFC could perhaps take the stance they should be implemented before stabilizing const Trait, it'll take a while anyway, so hopefully they would be!

[fee1-dead]

As an observer it seems a bit bizarre to me to launch const traits without support for const associated functions, which is likely to lead to churn in the ecosystem, rather than "close the gap" first.

Which primary use case do you envision allowing const fn in traits enable?

[matthieu-m]

As an example, consider the Store proposal, which today implements the split-trait strategy in order to provide a const-constructible dangling handle, without forcing the user to have a fully const Store, because calling OS primitives isn't const:

#[const_trait]
trait StoreHandle {
    type Handle: Copy + ...;

    fn dangling(&self) -> Self::Handle;
}

#[const_trait]
trait StoreSingle: StoreHandle {
    fn allocate(&mut self, layout: Layout) -> Result<Self::Handle, AllocError>;

    ...
}

This is necessary for:

impl<T, S> Vec<T, S>
where
    S: StoreSingle,
{
    pub const fn new() -> Self
    where
         S: ~const StoreHandle
    {
         todo!()
    }
}

The ideal interface would instead be:

const trait StoreSingle {
    type Handle: Copy + ...;

    //  No reason NOT to have a const constructible handle type.
    const fn dangling(&self) -> Self::Handle;

    fn allocate(&mut self, layout: Layout) -> Result<Self::Handle, AllocError>;
}

Which makes for a simpler API, and enables a simpler implementation:

impl<T, S> Vec<T, S>
where
    S: StoreSingle,
{
    pub const fn new() -> Self {
         todo!()
    }
}

Is a simpler API sufficient motivation to wait for const associated function in traits? Or should the current trait API be split, knowing that splitting is a breaking change, and so is fusing them back when const associated functions make it to stable?

I am afraid that this is the kind of unfortunate trade-off that library maintainers will face, with users that don't care about the const asking to wait, and users who do care about const asking to make the two breaking changes.

It's an uncomfortable situation.

[fee1-dead]

I do think this should be looked at, designed, and implemented. However I disagree with saying that we should prioritize this before const traits. Almost all traits in the standard library would benefit from having const traits, and the standard library currently does not have traits (or at least I don't know of anything) that requires all implementers to write a const fn. It makes much more sense for us to try to get for x in 0..100 {} in const working, and then see if this design pattern would be beneficial.

Also, it would be helpful if you could elaborate (perhaps with more context) on why an associated const wouldn't work in this case, though my point above still stands.

[matthieu-m]

Also, it would be helpful if you could elaborate (perhaps with more context) on why an associated const wouldn't work in this case, though my point above still stands.

It's a good question, actually. I would expect in most cases S::DANGLING would work quite well. The one tiny advantage of store.dangling() is that the return value can be depend on the instance of store. For example it may allow "randomization" by passing a different seed to store, to help fuzz usecases where dangling handle is incorrect used to ultimately produce a reference. Quite niche, admittedly.

It makes much more sense for us to try to get for x in 0..100 {} in const working, and then see if this design pattern would be beneficial.

Oh I definitely wish to be able to use traits in const contexts. And for loops in particular.

Which is why I asked how much work it would be to support const associated functions.

It seems like most of the scaffolding is here to me, but I am unfamiliar with compiler internals. If the answer is "it's a couple days work", then I'd argue it's really worth it to avoid all the potential churn (and maintainer pains) in the ecosystem. If the answer is "it's at least a month work, possibly a lot more as there are unresolved questions", then I'll back the decision to just stabilize const traits first without reserve.

Would you have an educated guess as to the amount of work required?

[programmerjake]

And this is where one may rightfully ask why not use RTN instead of all of these individual patches around what RTN would just allow. Ignoring my opinions on RTN and the impl effort required for it, we'd then need to figure out what kind of problems that produces for API authors and users.

I have some objections to using RTN as a replacement for marking some trait methods as const:

1. if we have a RTN-like syntax, it should not be T::method(..): const since that looks like marking the return type as const rather than the method itself, I think syntax like T::method: const or T::fn method: const is better RTN-like syntax (there should be a better name than RTN since RTN is Return Type Notation -- syntax for getting the return type, not the method itself).
2. using RTN-like syntax makes trait bounds extremely verbose, e.g.

   where
       T: MyTrait,
       T::foo: ~const,
       T::bar: ~const,
       T::baz: ~const,

To be clear, I'm not saying RTN-like syntax shouldn't exist, but that it should only be used where you can't just mark some trait methods as const in the trait definition or mark the whole trait as const.

[traviscross]

This potential for verbosity is shared with RTN also, and the answer we settled on in that case is that we would ship trait aliases, so that rather than repeating, e.g.,

where
    T: MyTrait,
    T::foo(..): Send,
    T::bar(..): Send,
    T::baz(..): Send,

...that either the trait author or a downstream user could write a trait alias such as trait SendMyTrait = .. that states all those bounds once, and that in fact the trait author could use a proc macro (provided by our project) to wrap that up and never have to spell out those bounds at all, e.g.:

#[trait_variant::make(SendMyTrait: Send)]
trait MyTrait { .. }

In fact, that already works today without trait aliases, because we can polyfill that in other ways.

The point is, shipping some more precise and expressive mechanism doesn't mean that people are forced to verbosely repeat themselves. As with RTN, we can build on top of it to handle the common case.

In terms of a name, I'd probably boringly call this return effects notation (RKN). In terms of syntax, I don't think T::foo: .. is right. That notates the type of the function item itself, which the set of output effects is not. If we had or planned a generic effects notation, e.g.:

fn f<effect K>(x: u8) -> u8 do K { x }
//   ~~~~~~~~         ~~~~~ ~~~~
// Generic effect       |      |
//   parameter     Return type |
//                             |
//                       Output effects

Then I'd perhaps suggest to mirror that with RKN, directly extending RTN in a similar syntactic way, so we'd write, e.g.:

where T: Tr<foo(..): Send do const>

(There are other reasons that may make an RTN-style approach difficult in this case, but syntax or verbosity don't strike me as the blockers any more than they did for RTN.)

[Jules-Bertholet]

I agree about the parallel to trait aliases, it motivates my proposal here.

output effects

What do you mean by “output” here?

[traviscross]

If we were to write:

fn f<T: Send>() -> Vec<T> { Vec::new() }
//   ~             ~~~~~~
// Input type    Output type

We might say that the function takes an input type and produces an output (or return) type. Similarly, with generic effects, we could say:

fn f<effect K>() -> () do K - const { .. }
//          ~             ~~~~~~~~~
//   Input effect set     Output effect set

That is, the function takes an input set of effects, and produces an output (or return) set of effects. The output set of effects are the effects that may be exhibited by the function itself.

[RalfJung]

"output effects" or "return effects" make no sense to me. In formal notation, the effects of a function are often annotated at the arrow, since they are part of the process from the inputs to the outputs. Also why do you abbreviate "effects" with "K" in "RKN"?

What you call "input effect set" and "output effect set" is an artifact of row polymorphism, I don't think it s a good guide for terminology here.

I'd call this something like "effect bounds" or so; it is about controlling the effects of trait functions.

[Jules-Bertholet]

There should be an equivalent of this example with the current proposed syntax (const trait Foo: ~const Bar + Baz {}), just to be clear and explicit about what supertrait bounds look like.

Ideally, there would also be an example with #![feature(trait_alias)] (e.g. const trait Foo = ~const Bar + Baz;); or alternately, those should be explicitly relegated to a future possibility.

[RalfJung]

Overall I am really excited about this; with &mut out of the door, traits are the next big frontier for const. I fully agree we shouldn't block this on the async/try effects work; const is quite different since there's no monadic type in the language reifying the effect, and I also don't want to wait another 4 years before const fn can finally use basic language features such as traits.

My main concern is the amount of ~const people will have to add everywhere. I'm not convinced it's such a bad idea to make that the default mode for const fn. However that would clearly need an edition migration so it doesn't have to be part of the MVP. I just don't agree with the way the RFC dismisses this alternative.

[RalfJung]

Interesting. This can be seen as an extension of the fact that all vtables have a drop slot, so in a sense all traits already have the Destruct supertrait.

[RalfJung]

For the reference-level section, this seems more understandable than the <T as Default>::k#host = Conditionally thing above, but maybe that's just because I have already through about the "be generic over constness" formulation quite a bit.

[RalfJung]

The first issue referenced here is not a ?const issue, it is a min const fn issue, isn't it? We meant to reject const fn foo<T: Foo>() but some loopholes were left open.

[oli-obk]

Yes, which is my whole argument. An opt out is too easy to get wrong.

[RalfJung]

The text says this is about the history of ?const bounds, and then links to a PR that has nothing to do with ?const bounds. That's at the very least confusing.

I also find this not a good justification for lang design decisions -- a borrowck is also easy to get wrong, so should we just not do it? Or a coherent trait system? IMO this is not a good argument.

[Jules-Bertholet]

If the behavior is hard to understand for implementers, it’s going to be even harder for users. (Borrowck is a great example here!) Given that the simpler design can do anything the complicated one can, why bother with the latter?

[RalfJung]

The implementation concerns aren't about "hard to understand". The concept of "const fn should not have trait bounds" is trivial to understand, it just turns out it's easy to get wrong during implementation.

Given that the proposal differs from the RFC only in syntax, I don't think the proposed alternative is any harder or easier to understand than what the RFC says. The concepts people have to understand (and the concepts that have to be implemented in the compiler) are the exact same either way.

There are good arguments against making ~const Trait the default. I think the RFC should focus on gathering those. I just don't think "we got something wrong in the compiler because it was implemented in a very syntax-directed manner" is a good argument.

[Jules-Bertholet]

only in syntax

Yes, syntax that is context- and edition-dependent. That’s harder both for implementers and for users. The current RFC does not have that problem.

[RalfJung]

That's a different argument from what the RFC makes, so it seems you are agreeing with me on the original point that started this subthread?

Not sure what you mean by "context-dependent syntax". But yes, an edition migration has downsides. Anyway please move discussion of the alternative proposal to the other thread; this thread is about the paragraph starting "The implementation correctness argument is partially due to our history". The argument that the RFC makes here is rather odd in two ways:

• The argument is not supported by the issue it links. I don't think "we got something entirely unrelated to ~const wrong in the past" supports the claim that ?const is hard to implement. I don't buy the relation to ?Sized either, these are very different things -- ?Sized adds a fundamentally new concept to the language that would not exist otherwise; ?const does not involve a new concept compared with ~const.
• It's a weak argument to begin with, given that the entire underlying complexity here is about parsing. "We forgot to check where clauses" is a mistake that just sometimes happens; I don't buy the implicit claim that the proposed RFC is somehow immune to oversights like this (or less susceptible to them than the ?const alternative). The ?Sized issues arise because rustc architecture makes it somewhat tricky to support certain syntax only in a few specific places rather than everywhere. The obvious solution is to support the syntax everywhere. ;) More seriously though
  • ~const apparently would also be supported only in a few places, so it has exactly the same issue.
  • If the syntax provides enough benefits, I don't think we should reject it for reasons like this. That would be really, really bad news for the future evolution of Rust. Maybe we should block it on a re-architecture of the parser that makes such issues less likely to occur, or so, but we can't stop adding good syntax just because our parser/lowering has a suboptimal architectures.

[oli-obk]

• ~const apparently would also be supported only in a few places, so it has exactly the same issue.

The linked things about other ? bounds like ?Sized or abitrary ?Trait are not parser issues. They are handled "correctly" all the way to the type system, they are just either redundant there, because the traits are already opted out, or in the case of ?const we were missing a requirement for an opt-out. It is much easier to forbid an opt-in, instead of requiring an opt-out, because you're forbidding the existance of something instead of forbidding the non-existance of something.

Anyway, I do not want to review, maintain or do that work (and thus be on the hook for any potential breakage around there), so 🤷 I will not talk about it anymore and others can figure it out. We can instead talk about the lang reasons not to do the opt out (other threads).

If the syntax provides enough benefits, I don't think we should reject it for reasons like this.

Agreed, but I consider this another nail in the coffin of ?const, which I don't think we should have out of lang reasons

[RalfJung]

I'm completely okay with the RFC comparing ~const and ?const entirely based on lang reasons and concluding that ~const is the better choice for now. In fact I think that's exactly what the RFC should do -- the migration effort alone makes ?const not suited for an MVP. But then the text that this thread is attached to (i.e., the implementation reasons) should be removed.

[Aloso]

The RFC doesn't mention which traits in the standard library will be constified. I guess the goal is to constify all of them, but it might not be possible to constify traits that use unsupported features, e.g. heap allocation.

This is due to the main limitation of this proposal: To constify a trait, all methods have to be const. This also means that marking a trait as const is a big comment, since after that you can't add non-const default methods backwards compatibly.

I particularly care about Iterator, which has a lot of default methods, and has a big impact due to its use in for loops. I'd like to know if Iterator can be constified under this proposal.

[onestacked]

@Aloso Iterator should be possible with this RFC, however with how many methods it has that is quite difficult to do all at once.

AFAIK the current plan for constifying Iterator is to add a way to add a way to declare some trait methods as always non const with something like a rustc_non_const_trait_method attribute (see this issue). Not sure if that will be usable by non std code.

Deciding what exactly to constify in std is a Libs-API question and not really in scope for this PR.

[Jules-Bertholet]

Another possible syntax is:

const trait Tr {
    // Must be `const` in all impls
    const fn foo();
    // Must be `const` in `const` impls
    ~const fn bar();
    // Never needs to be `const`
    fn baz();
}

This is analogous to the syntax for trait bounds.

A further possibility is to not require the const keyword in front of the trait for impls, but instead infer based on the annotations of the methods:

// This impl is `const`, because `fn bar()` is
impl trait Tr for () {
    const fn foo() {}
    const fn bar() {}
    fn baz() {}
}

// This impl is not `const`, because `fn bar()` is not
impl trait Tr for u32 {
    const fn foo() {}
    fn bar() {}
    fn baz() {}
}

This has several advantages:

• Implementations of functions can run in const if and only if they are annotated as const in the source.
• If combined with allowing impls to individually refine any function as const: impls can start marking functions as const immediately after the feature stabilizes, without waiting for the library defining the trait to update. And when said library does eventually update their trait to const Trait, the implementers will automatically support it without need for further changes.

It also imposes the limitation that a const trait must contain at least one ~const function or bound. That is not necessarily a bad thing, however.

[oli-obk]

It seems very suprising to have such aggregate behaviour where individual method annotations change sth about the entire impl.

We have that for fields, but there's no precedent for impls and it seems a footgun

[Nadrieril]

Depends how we interpret what const Trait means; we could mean it as "the methods can be called in a const context". This would solve the ~const Copy issues because that would make T: const Copy and T: Copy equivalent.

[Jules-Bertholet]

In my proposal above, const Trait bounds are basically sugar for the RTN-like syntax discussed at e.g. #3762 (comment). In my example above, bounding by const Tr is equivalent to defining a trait alias trait ConstTr = Tr where Self::bar: const;, and then bounding by ConstTr.

In other words, const Trait is nothing more than a convenient alias for “implements Trait with certain functions being const”. It’s a derived property of the impl, not a fundamental one.

[Jules-Bertholet]

Arguably “it’s just an alias” also makes the feature easier to teach.

It also imposes the limitation that a const trait must contain at least one ~const function or bound.

Alternatively, we could allow it with a warning, so that a const Trait bound for a const trait with no ~const in its definition is equivalent to the bare Trait bound.

[usamoi]

By first syntax it seems that there is no need to mark a trait as const, since fn methods' default bodies are unnecessary to being const.

[Jules-Bertholet]

One question with my proposal is how to handle default method bodies whose constness depends on that of other methods, like all the Iterator helpers. Here, I imagine that ~const bounds on a method declaration would be considered to apply to the default impl. So, for example, count() from Iterator would be declared as ~const fn count(self) -> usize where Self: ~const Iterator { /* ... */ }. (This relies on coinduction.)

Going further, perhaps where ~const could be added as a shorthand for where Self: ~const TheTraitBeingDefined. So our count() declaration could be written ~const fn count(self) -> usize where ~const { /* ... */ }.

[programmerjake]

this should probably be changed to a new tracking issue, see: rust-lang/rust#67792 (comment)

[WaffleLapkin]

Wouldn't that prevent const-ification of standard library traits? I.e. if we stabilize that (some) standard library traits imply ~const Destruct, we won't be able to take that back.

It's also quite easy to come up with an example where we'd want a const trait but not ~const Destruct:

static EV: Vec<u8> = Vec::new(); // this works
static EV: Vec<u8> = Vec::default(); // so why shouldn't this?

[programmerjake]

Some good example traits that I don't think should ever imply ~const Destruct: AsRef, AsMut, Borrow, Deref, PartialEq, ToString, fmt::Debug (and other formatting traits, though fmt::Write is probably an exception)

[clarfonthey]

Perhaps the link here is that these traits permit ?Sized types, whereas others don't?

Perhaps there could be an argument for making ~const Destruct simply inherited in all the places with a default Sized bound? This still doesn't answer the question of opting out, but at least it gives an idea of where it could be added by default.

[WaffleLapkin]

I think ?Sized is accidental here. The underlying thing is that if you do not accept T by value, you don't need to destruct it.

It just so happens that if you don't accept T by value, you also likely support !Sized types.

[programmerjake]

yeah, a good example of where Sized is required but Destruct is not: the Hasher in Hash::hash (though if we could redo it it would allow ?Sized)

[clarfonthey]

I mean, if you had const Hash, wouldn't you also need the Hasher to have ~const Destruct here? I agree that the design isn't ideal, but given the current design, it seems to not be a good counterexample.

[clarfonthey]

You do mention const Drop impls later in the RFC with regards to bounds, but I'd make an additional note here or before here clarifying that const Drop implementations are allowed, since at first glance it's not immediately clear what their purpose would be.

A simple example might be worthwhile: even though you can't mutate global state, you could for example have a value being borrowed inside the object which gets mutated in some way in the Drop impl, which can be done in const context.

This also adds another interesting question: is forget allowed for non-const Destruct types? I would assume yes, but it's not clear here.

[Jules-Bertholet]

This also adds another interesting question: is forget allowed for non-const Destruct types? I would assume yes, but it's not clear here.

It would be a breaking change to start disallowing it, so yes, it would continue to work

[clarfonthey]

I actually had no idea what the current behaviour was for forget, so, thank you for clarifying that. Definitely worth mentioning in the RFC itself.

[clarfonthey]

One thing which is worth briefly touching upon is the idea of traits without methods being marked const, since it technically does nothing by itself. It's a useful API guarantee if you choose to later add methods, but in the future, we may have traits which have an API guarantee to never have methods (e.g. marker_trait), and it's not clear how we should handle those. Even though it's speculating about unstable features, I think it's worth at least mentioning.

[clarfonthey]

Since you want inline threading and I'm not sure where best to put this, putting it here.

You should probably talk about how const fn and methods in const traits are compatible with const Fn traits, since you otherwise only briefly touch on const fn pointers, which are related but not technically the same.

Even if const closures are an unanswered question, I'd prefer if Option::map and similar methods were possible if you passed them const fns defined explicitly.

[davidtwco]

In #3729, we had a question about what the precedence should be for relaxed bounds - ?(const Sized) or (?const) Sized? Are you opt-ing out of the constness or the whole trait?

[oli-obk]

The parser acts as if you need to write const ?Sized (that being explicitly rejected right now is just because it wasn't useful so far)

[algesten]

The RFC template has under Alternatives, the question:

• What is the impact of not doing this?

Should this RFC have a section that reasons about the implications of NOT doing this?

For me on the sidelines, I see a complicated new syntax, but also don't know the big picture to where this takes us.

[hadronized]

I see constness as a binary property of an interface: either it’s const or it’s not. You introduce new syntax (const Trait, impl const Trait, T: const Trait and T: ~const Trait), but is the initial problem (not being able to call a trait method (not marked const) in a const-context an API problem? I’m not so certain.

My point is that if you have a function of the form const fn, then it’s perfectly fine to call it at runtime. If you have to implement a fn function, but provide its implementation with a const fn, then it’s perfectly okay.

const fn default<T: Default>() -> T {
    T::default()
}

Because the function is marked const, we already have all the info in the type system to know that any method called with <T as Default> must be implemented as a const fn.

Then why not just accept that code, and only authorize calling it for T implementing Default by providing a const fn for Default::default? I.e. allowing this:

trait Default {
    fn default();
}

impl Default for MyType {
    const fn default() {  MyType { x: 123 } }
}

I fail to see the unsoundness of doing this, because it should be allowed to implement a fn with a const fn, and I think that would solve most of the problems you try to solve?

---

EDIT: I realized I missed one situation you cover:

fn interior_const_default<T: Default>() {
    const x = T::default();
}

This indeed would require to annotate something on T to know that interior_const_default will only work for T implementing Default::default with a const. Hence, instead of annotating the trait, why not just adding that to a trait bound?

fn interior_const_default<T: Default<default: const>>() {
    const x = T::default();
}

[fee1-dead]

Please read the thread above discussing syntax, which has a list of reasons why deriving the constness of trait bounds from the context would not work.

#3762 (comment)

[hadronized]

I read it, and I’m not entirely sure why (I might have missed an argument against it?).

[RustyYato]

This doesn't work because you can have trait bounds on const fn now. You simply can't call any methods on the trait. So requiring all methods be const is a breaking change. And Rust (almost) never looks at the body of a function to see if a call-site is well typed. That would be a backwards compatibility hazard, since any change to the body of a function could be a breaking change.

Irrelevant note: if you are using impl trait in return position, then Send and Sync are inferred from the body, but this is the exception to the rule.

[hadronized]

This doesn't work because you can have trait bounds on const fn now. You simply can't call any methods on the trait.

But that’s my point! Since we can’t call them, why not simply not just add constness bounds?

// current Rust
const fn default<T: Default>() -> T {
    // we can’t call anything from T because Default::default is not const
}

// what would work
const fn default<T: Default<default: const>>() -> T {
    // now we can cherry-pick what is const, and thus here we can
    // call default::<T>() where <T as Default>::default() is const
}

What am I missing?

[hadronized]

What you originally proposed (allowing const fn a<T: Foo>() { T::foo(); } to just work) has been debated many times, and I posted some of the reasons in my linked thread. Besides the countless language design concerns needed to be considered for those semantics, I do not think the main stakeholders (project-const-traits) on the compiler side is willing to implement them.

Okay, I get that, hence why I suggested the syntax T: Trait<method: const>.

---

For the Iterator example, it would require Self::next: const at the implementor level, right? Not at the trait definition.

[tmccombs]

For the Iterator example, it would require Self::next: const at the implementor level, right? Not at the trait definition.

How do you handle methods defined on the trait itself? Of which Iterator has many. Such methods would need to be const if and only if the next method of the implementation is const.

[traviscross]

Default bodies are really kind of just bodies of blanket default impl items in an RFC 1210 sense, so in that way, aside from how we might syntactically expose that for default bodies, it's perhaps the same underlying question of whether this could be handled at the impl level.

[Jules-Bertholet]

For the Iterator example, it would require Self::next: const at the implementor level, right? Not at the trait definition.

How do you handle methods defined on the trait itself? Of which Iterator has many. Such methods would need to be const if and only if the next method of the implementation is const.

My thinking here is that a where Self::method: ~const bound on a const fn in the trait definition would be considered to apply to the default implementation. For example, all the Iterator combinator methods would have where Self::next: ~const.

[RalfJung]

If you have to implement a fn function, but provide its implementation with a const fn, then it’s perfectly okay.

What if I also have

const fn default2<T: Default>(x: T) -> T {
    x
}

This may seem like a silly function to write, but in general it may certainly happen that you write a const fn with a bound and then don't use the bound to call a method. Maybe you just convert some &T into &dyn Trait, or you need an associated type or associated const of the trait but no method. (In fact you can already do that on stable.)

Would you say that calling that function with a T whose Default impl is non-const should be accepted or not?

• If it should be accepted, then your proposal violates the principle that the function signature fully determines how the type-checker treats this function.
• If it should not be accepted, that's a breaking change.