#rust-lang

is that current syntax?

Noldorin: try fn, async fn

Noldorin: no; I made it up :P

except for async fn

yeah

how would `try` work?

I agree it works well for `async` though

Noldorin: like fn, but -> impl Try + ok-wrapping [rathole: find consensus that we want this...]

Noldorin: might surprise users of async fn tho?

oh I see

so would `try` auto-generate a hidden return type?

also; if you say async fn foo<T: Bar>() ==> async fn foo<T: async Bar>(), then what is the explicit syntax for getting rid of 'async Bar' and literally having T: Bar but not T: async Bar?

Noldorin: oh no sorry; try fn would require that the return type is Try and 'return expr' would Ok-wrap 'expr'

ah

centril, but it would only work for infallible fns?

Noldorin: "infallible fns"?

functions that would never return e.g. None or Err

centril, surely that would be `async fn foo<T: async? Bar>()`, unless I misunderstand your syntax?

Noldorin: async? would mean possibly-async

oh yes, you'd say async fn foo<T: !async Bar>()

yes, I was just going to type that heh

Ok, seems like this could work

so for "possibly async" there the fn would be monomorphised, right?

Noldorin: yeah, you'd get two different monomorphic functions, one sync and one async (assuming you use both variants somewhere)

centril, rkruppe: eeek floats https://github.com/rust-lang/rust/issues/24111#...

[Issue 24111] <open> const fn tracking issue (RFC 911) <https://github.com/rust-lang/rust/issues/24111>;

centril, yeah, so monomorphised twice, I guess :-)

Noldorin: correct :)

Noldorin: but.. I would go with the more wordy const fn foo<T: const Bar> at first ("Stroustrup rule") and sugar later

centril, perhaps... I'm not against going straight to the shorthand syntax, but I see you reason

centril, anyway, if we're going to have negative effect bounds, that pretty much decides the syntax for possible effect bounds as `?const` (e.g.)

Noldorin: I think we can gain some experience with the longer one first and see how bad it is

fair

eddyb: i'm cackling

Noldorin: having '?const mod { .. }' eventually could be nice

or even: "make all the shit in this crate ?const"

eddyb: "float bullshit" ranks surprisingly highly on the list of things giving rust developers migraines

rkruppe: the gift that keeps giving!

Noldorin: so negative effect bounds is far from a given;

centril, hah! yeah, the stuff of dreams...

what do you mean "a given"?

Noldorin: remove 'a' :P

still not sure I get you

Noldorin: it is not a done deal that we'll get negative effect bounds; far from it.

centril, oh :(

centril, well if we implement the shorthand syntax, we need it... otherwise not necessarily

Noldorin: yep

eddyb, what... `const unsafe fn` is allowed?! https://github.com/rust-lang/rust/issues/24111

Noldorin: I did say they're orthogonal things...

Noldorin: the unsafe checker checks whether unsafe blocks wrap unsafe operations including calls to unsafe functions

[23:06:14] <eddyb>but even the old const eval ignored unsafe blocks

[23:06:24] <eddyb>which is the correct thing to do

but does it actually make sense

eddyb, you seem to be saying there that unsafe blocks should be ignored/disallowed in const eval

I mean... what is const undefined behaviour :p

Noldorin: "const eval" doesn't exist anymore. MIR doesn't have unsafe blocks explicitly, miri won't see them unless it looks at the scope in SourceInfo

eddyb, again, you know what I mean... miri evaluation in const context :-P

but okay... if MIR ignores them, fine

if you look at the MIR, there's nothing about "push unsafe"/"pop unsafe" or anything like that

I can't really think of a reason to disallow const unsafe fns

though I don't see the point of permitting `const unsafe` then... it could be misleading to users who think their unsafe code would work in const contexts

It would, though

only the unsafety checking pass cares about the presence of unsafe code

Noldorin: you're missing what "ignoring" means here :P

Noldorin: for a long time now, the "unsafe" in `unsafe {...}` has been ignored by basically everything but the unsafety checking pass

okay...

so everyone, including miri, sees a regular block (well, it's not even a block in MIR) with a regular call in it

sorry I guess the type-checker also has to look at the (un)safety in fn types

but somehow I fail

Noldorin: note that miri was designed to support unsafe Rust

I guess I'm changing my opinion on this subject to "why not"

eddyb, but unsafe Rust can be non-deterministic...

if we didn't want to, we could've went with something that allows symbolic interpretation

Noldorin: not under miri

so it disallows FFI?

miri can't even do FFI anyway

but yeah, any FFI static access/fn call is disallowed

Noldorin: https://internals.rust-lang.org/t/mir-constant-...

yeah, so it disallows it ;-)

eddyb, okay, I'm on the same page as you now

all is good

I should've linked that post earlier

no worries

there was this flying proposal about adding a C frontend to MIR

so that you can const eval C libraries :p

suggestion by eddyb iirc

/kban est31

how dare you! :P

(but yeah it'd be neat)

centril, so, are you thinking of writing up your const effect work into a new RFC soon then?

Noldorin: there are other unresolved issues... const impl or impl const

-> impl const Foo

-> const impl Foo

Noldorin: miri can enforce determinism for CTFE, and that's all fine and dandy, but if we want some form of purity / referential transparency out of const fn, that is preserved at runtime, it gets harder

ahh, classic bikeshedding :P

unsafe impl, impl unsafe

can we just simply get "normal" stable const rust?

eddyb: "win anything"?

eddyb, it will just be limited to the const effect to start. it's pretty much necessary for sound, workable const trait bounds

impl const vs const impl seem like niche features for me

est31: if that is niche, then I don't know what niche means...

important to discuss but is it worth for them to slow down stuff?

eddyb, it's the same feature, just different syntax, I think

right, centril ?

Noldorin: right

est31: dont mind stabilizing const fn when we figure out referential transparency

centril: right now const eval is super restricted. Impl trait is a highly advanced feature that's not needed in 99% of cases... after all rust worked well without it

const effect polymorphism can be added later

centril, `const/unsafe impl` makes more sense to me, since the effect can be seen as a modifier of sorts

est31: oh... impl const Foo for X { .. } is the major feature

imo, only the bikeshedding and potential backwards-compatibility issues it produces are the only blockers

alercah, agreed

alercah, but I think centril has thought about potential backwards-compatibility issues of the future, and is becoming more convinced they won't be a problem, as we add more effects... (if we do)

Yeah; I just want to be sure that we're going into this clear-eyed and introduce something conservative

but which we can extend upon

so we don't walk into future-compat hazards

Noldorin: re. const impl vs. impl const I was pro const impl but im going over to impl const

centril, hmm, why's that?

Noldorin: See it this way:

T: const Foo

impl const Foo for X

(note the added whitespace and grouping)

it also works better with -> impl const Foo

I agree with this

-> impl (Bar + const Foo)

> it's pretty much necessary for sound, workable const trait bounds

I've given up on that btw

I just want "extract from body"

cc scott on Lean's similar features

eddyb: about this example

(derive properties from functions' bodies)

what is the problem here? you write yourself that miri fails to compile

that it gives you a miri error*

est31: it fails to *interpret*

you might not attempt that at compile-time

but at runtime instead

and it breaks referential transparency

eddyb: expand on "extract from body"?

eddyb: I see

eddyb: so your statement is that safe const fn rust should guarantee referential transparency aka same outcome runtime as well as compile time?

est31: I'm not saying it should. I'm saying that some people want that and I am discussing the conditions for it being upheld