#rust-lang

that's why I said either pretty scary or pretty cool

Yeah, and I meant to say I definitely don't find that cool at all.

legitimate view

I'm no fan of the entire EBCB thing

"is" that doesnt bind is great

as well as if guards on if

that would cover like 90% of use cases, be simple, and not require super complicated rules

EBCB?

"is" is matches!, why not just use matches!?

BCEC I mean

BCEC?

Binding Creation in Expression Context

Where?

I've made up that term to describe the proposed concepts

Oh in the RFC with the weird indent style.

either EXPR is Some(v) && v > 10

This looks like saccharine.

or let Some(v) = EXPR && v > 10

TBH I would be pretty pissed off to see this merged while let else was rejected.

_nox: yeah it is a quite sugary debate we have

Especially when the argument against let else was "just use match".

I've given up on the thread because there's like ten different proposals floating around

Including several that are only tangentially related

I could live without any of this stuff merged

well obviously

We definitely live without let else in Servo, but it would make code cleaner in many places.

I must say I am currently a bit sour on further syntactic sugar around control flow, seeing as I am currently reading code that could save several levels of indentations just with existing tools (early return, if let)

I just wouldnt want sugar merged that gives a bit sweetness but means a great deal of arbitrary rules

Sour on sugar?

:)

indeed

I often write code like let f = if let Some(v) = expr { v } else { continue; } or similar

est31: Same.

est31: https://github.com/rust-lang/rfcs/pull/1303#iss... is what I meant in my /me.

_nox: is that what let else is about? making that shorter?

est31: HTML is plenty of "if X is null, abort these steps".

est31: Yep.

est31: let Some(v) = expr else { continue }

oh that would be sweet

est31: https://github.com/rust-lang/rfcs/pull/1303#iss... has a real world example.

At this point I think the RFC should be closed, and reopened in another PR, because this BCEC stuff is not the PR, and everybody is ignoring it, and if we tried to go back to it, anybody new to the discussion would be so so so confused.

yeah

lets do it like the modules rfc

new pr for each day

_nox: let expr really looks great....

est31: A rogue-like RFC?

:)

Every time a legit argument against it is made, the RFC is killed and a new one must be ran.

est31: I don't mean have a new RFC, I mean that the comments on the RFC are totally unrelated to the RFC that it's impossible to actually discuss the RFC.

especially once we get arbitrary labeled blocks

Havvy: I've said "new PR for each day" not "new RFC" :)

got what you've meant

but yeah the modules rfc got revised each time and renamed

The modules one actually made changes based on discussion, as the discussion was related to the RFC.

okay, what on earth's going on here... 'if' expressions aren't supported in const fns?! I'm getting error[E0019]: constant function contains unimplemented expression type

that's true

if is not currently allowed in a const fn

steveklabnik, ?!

Havvy: a new PR won't fix that. anything addressing the use case of chained if-let is like a big invitation to propose BCEC

steveklabnik, I was under the impression lots of things (more complicated than if) were allowed underthe new MIRI evaluator

> although more useful than loops, conditional control flow (if/else and match) also remains unimplemented and only match would pose a challenge

miri isn't the default yet

it still runs side by side the old const eval

yes

rkruppe: The BCEC should be its own RFC and design work for it can be done there.

and, even then

rkruppe, ah rubbish. can I make it default?

i am pretty sure right now that it's restricted to the same things as the old evaluator? not 100% on that though

-Z miri

iirc

Noldorin: even if miri is the new default, one needs a new rfc to allow all the new stuff

we are not there yet

Havvy: you can't separate it very well since it's addressing the same use case

est31, what's so controversial about if's in const exprs?

nothing

then surely an RFC isn't needed

the RFC is needed to determine the exact extent

because miri can do much, much more than ifs

sounds like silly bureaucracy, but okay...

it's more like "actually design the language" rather than "let it do anything just because"

Noldorin: yeah its more of a bureocracy thing than controversies thing

Yes I don't expect it to be super controversial either

RFCs are no court, not made to end clan wars

steveklabnik, for things that need designing, sure. but "enabling if expressions in const expressions" seems so trivial as to not need it

est31, rkruppe fair enough

Noldorin: miri will likely enable far more stuff

But it's a major feature and it will impact all Rust implementations so it's good to make sure everyone's on board.

Noldorin: it allows meaningful recursion

est31, yeah, that's what I understand.

oli-obk is almost done with the miri PR, right?

miri is integrated into the compiler already

and non-linear control-flow

making some analysis harder

oh. well I got the impression oli-obk was working on some final stuff to do with it. at least that's what he told me

you don't want if/else without imperative loops

because people will write recursive implementations of algorithms

is there a way to enable miri when building Rust? for the stdlib.

eddyb, yeah, and Rust isn't optimised for that... makes sense

Noldorin: oli-obk is working on replacing the old CTFE with miri

miri is not usable for CTFE right now, only to double-check the results of old CTFE

aha

Havvy: I think all discussions in this area are like this, that everyone just brings up their pet proposal

eddyb, so I can't actually do anything more by enabling -Z miri right now eh?

in terms of CTFE

Noldorin: no it's just that we don't want people to do the C++ constexpr thing of rewriting their algorithms to some weird lambda calculus

Noldorin: correct

okay heh

fair

eddyb, any idea how close it is to completion? is there a PR for it? I'd be interested in trying it out. :-)

yeah filter by oli-obk's PRs

actually I may have it handy

[PR 46882] <open> WIP: add more boosters 🚀 to miri... <https://github.com/rust-lang/rust/pull/46882>;

eddyb, cool, thanks