Stream: t-compiler/const-eval

Topic: #55009

oli (Nov 19 2018 at 09:25, on Zulip):

How do we continue with unstable experiments wrt unconst?

RalfJ (Nov 19 2018 at 12:10, on Zulip):

I think we have to decide which guarantees we expect to be upheld about const fn (on top the usual guarantee of being safe to call at runtime), and analyze what the failure modes are when the guarantees are violated (the biggest issue being promotion IMO, so completing the docs on what gets promoted and what does not should also help)

RalfJ (Nov 19 2018 at 12:11, on Zulip):

e.g. I wonder if we plan to ever promote calls to user-defined const fn? I would think so. Then what does that imply?

oli (Nov 19 2018 at 12:24, on Zulip):

I don't think we should ever promote user-defined const fn without explicit requests for promotion

oli (Nov 19 2018 at 12:25, on Zulip):

so some sort of anonymous constants via const { foo } blocks or sth, but not automatic promotion

RalfJ (Nov 19 2018 at 13:12, on Zulip):

@Oli but that seems really arbitrary

RalfJ (Nov 19 2018 at 13:12, on Zulip):

I guess I could agree if we plan to also deprecate promoting any const fn automatically

RalfJ (Nov 19 2018 at 13:13, on Zulip):

1. come up with some syntax for explicit promotion
2. make it a warning to not use that syntax when calling a const fn (any const fn, including the ones we currently promote) and relying on it being promoted
3. transition to an error with the next edition, or so

RalfJ (Nov 19 2018 at 13:14, on Zulip):

basically, I'd like to impose the constraint that in the "final state", all const fn are treated equal for promotion

Last update: Jan 19 2020 at 10:35UTC