Skip to content

Conversation

fmease
Copy link
Member

@fmease fmease commented Jan 12, 2024

This follows from this Zulip discussion.

Basically in my opinion, it makes sense to allow ~const on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax <Ty as ~const Trait>::Proj/<Ty as const Trait>::Proj yet; that can happen as a follow-up.

This already allows more code to compile since T::Assoc where T is a type parameter and where the predicate <T as ~const Trait> is in the environment gets elaborated to (pseudo) <T as ~const Trait>::Assoc.

#[const_trait]
trait Trait {
    type Assoc: ~const Trait;
    fn func() -> i32;
}

const fn function<T: ~const Trait>() -> i32 {
    T::Assoc::func()
}

~const associated type bounds also work together with const bounds:

struct Type<const N: i32>;

fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above
    Type
}

NB: This PR also starts allowing ~const bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them?
For reference, it wouldn't make any sense to allow ~const Trait in GACs (generic associated constants, generic_const_items) because they'd be absolutely useless (contrary to const Trait).

[@]rustbot ping project-const-traits
r? project-const-traits

@fmease fmease added F-const_trait_impl `#![feature(const_trait_impl)]` F-effects `#![feature(effects)]` labels Jan 12, 2024
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 12, 2024
@rustbot

This comment was marked as resolved.

@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the tilde-const-assoc-ty-bounds branch from ee9c39a to f283739 Compare January 12, 2024 16:22
@compiler-errors
Copy link
Member

compiler-errors commented Jan 12, 2024

However, I don't know if those bounds are actually useful.

Yes, I think these GAT where bounds are both useful and necessary as long as we all ~const in item bound position. Some associated types may be conditionally ~const only if some generic type is ~const. For example:

#[const_trait] trait Foo {}
impl const Foo for Wrapper<T> where T: ~const Foo {}

#[const_trait] trait Bar {
  type Assoc<T: ~const Foo>: ~const Foo;
}
impl Bar for () {
  type Assoc<T: ~const Foo> = Wrapper<T>; // this is **only** `~const Foo` if `T: ~const Foo`
}

@bors r+

@bors
Copy link
Collaborator

bors commented Jan 12, 2024

📌 Commit f283739 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 12, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 13, 2024
…, r=compiler-errors

Allow `~const` on associated type bounds again

This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds).

Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up.

This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`.

```rs
#[const_trait]
trait Trait {
    type Assoc: ~const Trait;
    fn func() -> i32;
}

const fn function<T: ~const Trait>() -> i32 {
    T::Assoc::func()
}
```

`~const` associated type bounds also work together with `const` bounds:

```rs
struct Type<const N: i32>;

fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above
    Type
}
```

NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them?
For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`).

~~[`@]rustbot` ping project-const-traits~~
r? project-const-traits
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 13, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#119891 (rename `reported_signature_mismatch` to reflect its use)
 - rust-lang#119894 (Allow `~const` on associated type bounds again)
 - rust-lang#119896 (Taint `_` placeholder types in trait impl method signatures)
 - rust-lang#119898 (Remove unused `ErrorReporting` variant from overflow handling)
 - rust-lang#119902 (fix typo in `fn()` docs)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 13, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#119587 (Varargs support for system ABI)
 - rust-lang#119891 (rename `reported_signature_mismatch` to reflect its use)
 - rust-lang#119894 (Allow `~const` on associated type bounds again)
 - rust-lang#119896 (Taint `_` placeholder types in trait impl method signatures)
 - rust-lang#119898 (Remove unused `ErrorReporting` variant from overflow handling)
 - rust-lang#119902 (fix typo in `fn()` docs)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2c7ce1c into rust-lang:master Jan 13, 2024
@rustbot rustbot added this to the 1.77.0 milestone Jan 13, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 13, 2024
Rollup merge of rust-lang#119894 - fmease:tilde-const-assoc-ty-bounds, r=compiler-errors

Allow `~const` on associated type bounds again

This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds).

Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up.

This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`.

```rs
#[const_trait]
trait Trait {
    type Assoc: ~const Trait;
    fn func() -> i32;
}

const fn function<T: ~const Trait>() -> i32 {
    T::Assoc::func()
}
```

`~const` associated type bounds also work together with `const` bounds:

```rs
struct Type<const N: i32>;

fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above
    Type
}
```

NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them?
For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`).

~~[``@]rustbot`` ping project-const-traits~~
r? project-const-traits
@fmease fmease deleted the tilde-const-assoc-ty-bounds branch January 13, 2024 18:10
@fee1-dead fee1-dead added the PG-const-traits Project group: Const traits label Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-const_trait_impl `#![feature(const_trait_impl)]` F-effects `#![feature(effects)]` PG-const-traits Project group: Const traits S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants