#rust-lang

centril: finding a way to not have special const traits, to not have to make multiple versions of things that differ only in constness of arguments, etc sounds quite valuable

scottmcm: yeah - did you read the discussion I and eddyb had btw? it might suggest that const + MIRI is too powerful for it to be useful to have T: const Trait for a non-const fn

I don't even really know what the rules for `const fn` are

I just never want to see both `fn foo` and `const fn foo_const` next to each other :P

scottmcm: as far as I understood it, const fn:s must be deterministic

that's it, basically

scottmcm: for a const-fn called at runtime, this means that for the exact same runtime values (as arguments), the const-fn must produce the same return value, or, "produce exactly the same sequence of actions"

well, these would be the limits of const-fn - but it's not the story today

Arguably you could have a non-const version that is more optimized.

isHavvy: depends on what you can do in a const context, in the future const may be powerful enough to write the optimized version

In any case, we can have `const impl`s (all fn:s must be const), or we can have const-fn:s in impl:s and then for it to be callable from a const context all fn:s in the impl must be const-fn:s

eddyb: Thinking about it again, `const impl` and `impl X for Y { const fn ... }` (const-fn on every item) is not much of a difference

eddyb: on the T: const Trait part, I think both syntaxes can be used - then we have: for a normal fn, you must write T: const Trait to require "all methods are const", and for a const-fn, T: Trait implicitly means T: const Trait

so I think we can have our cake and eat it too

tho I think I prefer the syntax `const impl` cause a trait could actually want to write: trait Foo { const fn bar(I) -> R; }

tho I think impl Foo for X { const fn bar(I) -> R; } has no conflict with "all fn:s must be const" , for some traits, the only impl:s will be "all fn:s are const" ones.

we can use `const impl` as sugar for putting `const` on all fn:s

before I run off to write that RFC, someone please break the proposal apart :P

cc nmatsakis, woboats ^

centril: it seems okay. the reason I didn't want T: const Trait if T: Trait already does something is to avoid confusion

with e.g. const N: usize

eddyb: ah - that is syntactically different tho: const N: Type vs. T: const Trait

I think it is sufficiently noticable

centril: not ambiguity, confusion

eddyb: yeah got that

it's just const moved horizontally, that's not enough IMO :P

im saying the risk of confusion is not that great

because honestly the syntax for const generics could've well been N: const usize

and we might actually want to use "const usize" somewhere as a syntax

eddyb: still you have the trait/type difference as well

you can agree that less syntax in the language is objectively better, right?

so far I'm not aware of a real usecase of T: const Trait on a non-const fn

eddyb: sure, less syntax is better

but more expressivity is also better =)

eddyb: so I think perhaps we can start of with T: const Trait in the RFC and if no one likes it we can relegate to "maybe in the future"

and have it as an unanswered question

yes but expressivity for what?

or perhaps the reverse - start w/o it and have it as an unanswered question

I prefer the latter :P

eddyb: so im sure there's a use case - i just cant think of it now

:D

centril: I've thought about it for years and I doubt it

eddyb: ah =)

eddyb: but it's good to know there are no technical difficulties at least

we have the option if we like to use it

anyways - time to go do some TA:ing

const fn's are not really meaningful at runtime because we can't fully enforce the compile-time/runtime distinction is not observed

a const fn could detect it's at runtime and use an escape hatch to employ non-determinisim

or the detection of runtime itself involves a source of non-determinisim, I suppose

so it would have to be a compile-time use within a non-const fn

centril: you're probably looking at this all wrong IMO

centril: if you want to make an argument for T: const Trait it should be about using it in a constant location that's not a const fn

array lengths, associated consts in an impl, triggering rvalue promotion

that sort of thing

RalfJ: ping