Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upCalling methods on generic parameters of const fns #2632
Conversation
oli-obk
added some commits
Oct 5, 2018
This comment has been minimized.
This comment has been minimized.
One alternative syntax design that is not mentioned here is the question of There are strong arguments that Conversely, as far as I'm aware, (I don't like to start the discussion with syntax bikeshedding, but as mentioned in the original post, this RFC has already ungone significant design discussion and I'm satisfied it's close to the optimal conservative design.) |
cramertj
reviewed
Feb 5, 2019
fbstj
reviewed
Feb 5, 2019
Centril
added
T-lang
A-syntax
A-typesystem
A-const-eval
labels
Feb 5, 2019
This comment has been minimized.
This comment has been minimized.
rpjohnst
commented
Feb 5, 2019
How do we want |
This comment has been minimized.
This comment has been minimized.
I imagine it makes most sense to use the same (syntactic) rules for |
This comment has been minimized.
This comment has been minimized.
I don’t think this has been mentioned before, but putting |
This comment has been minimized.
This comment has been minimized.
ExpHP
commented
Feb 6, 2019
•
I'm not sure why {
let local = get_thing();
// Implicitly inserted
// (each one is individually omitted if that type
// does not explicitly implement Drop)
Drop::drop(&mut local);
Drop::drop(&mut local.field_1);
Drop::drop(&mut local.field_2);
} Requiring (one could argue that allowing |
This comment has been minimized.
This comment has been minimized.
It has been mentioned before. This was even the original syntax. Reasoning for the change can be found at rust-rfcs/const-eval#8 (comment) cc @scottmcm for consistency (not in semantics, but user expectations) I have slowly come back around to |
This comment has been minimized.
This comment has been minimized.
ExpHP
commented
Feb 10, 2019
Ultimately the location of Conceptually, the keyword is attached to the trait. I.e. it's not an |
Centril
self-assigned this
Feb 14, 2019
This comment has been minimized.
This comment has been minimized.
I think that's looking at it from the wrong perspective. It's not that it's |
This comment has been minimized.
This comment has been minimized.
But as far as I can tell, the Constness is not a property of the Trait, but of the impl, which is not the same for dyn, right? |
This comment has been minimized.
This comment has been minimized.
I agree with this in particular when viewed in light of effect systems. Moreover,
Traits can be seen as logical requirements and implementations are proofs that those requirements are satisfied. In that light, e.g. |
oli-obk
added some commits
Feb 16, 2019
Centril
added
the
A-effects
label
Feb 16, 2019
Centril
reviewed
Feb 16, 2019
oli-obk
added some commits
Feb 16, 2019
Centril
reviewed
Feb 16, 2019
Centril
and others
added some commits
Feb 16, 2019
pnkfelix
reviewed
Feb 19, 2019
* can only pass types with explicit (const or not) `Drop` impls, | ||
still can't drop any values inside the function | ||
* mention `Drop` in the parameter bounds | ||
* can only pass types with explicit `const Drop` impls (so no `u32`) |
This comment has been minimized.
This comment has been minimized.
pnkfelix
Feb 19, 2019
Member
this bullet seems internally inconsistent (potentially due to a typo?): you say "mention Drop
in the parameter bounds" for the bullet, but then say in the sub-bullet that such a bound will require explicit const Drop
impls. I would think that you either want the bullet to say "method ConstDrop
in the parameter bounds", or you want the sub-bullet to say that the Drop
bound will only allow passing types with explicit Drop (not const Drop
) impls.
This comment has been minimized.
This comment has been minimized.
oli-obk
Feb 20, 2019
Author
Contributor
This is part of the intro as to why we need ConstDrop
. The ConstDrop
trait has not been mentioned before here, and I'm introducing it below to offer a fourth way (and actually useful) way to have const fn
interact with Drop
Having a T: Foo
bound on a const fn
will allow you to only pass types that implement const Foo
if you are within a const context. Drop
isn't special here, so you can only call a const fn
with a T: Drop
bound with a type that has a const Drop
impl.
ExpHP
reviewed
Feb 19, 2019
A notable use case of `impl const` is defining `Drop` impls. | ||
Since const evaluation has no side effects, there is no simple example that | ||
showcases `const Drop` in any useful way. Instead we create a `Drop` impl that | ||
has user visible side effects: |
This comment has been minimized.
This comment has been minimized.
ExpHP
Feb 19, 2019
I'm confused. Surely this impl should be forbidden due to interior mutability? (i.e. Cell::set
would never be const
)
This comment has been minimized.
This comment has been minimized.
oli-obk
Feb 20, 2019
Author
Contributor
There's no reason to forbid Cell::set
in const environments (that I know of). The following piece of code has deterministic behavior, so we can theoretically allow it in const contexts.
let x = Cell::new(42);
x.set(5);
assert!(x.get() == 5);
Do you have a problematic example in mind?
oli-obk commentedFeb 5, 2019
•
edited
TLDR: Allow
and
cc @Centril @varkor @RalfJung @eddyb
This RFC has gone through an extensive pre-RFC phase in rust-rfcs/const-eval#8
Rendered