@pnkfelix btw... in https://github.com/rust-lang/rust/pull/57045 @RalfJ used MaybeUninit::uninitialized().into_inner()
to go from MaybeUninit<[MaybeUninit; N]>
to [MaybeUninit; N]
which made me think of https://github.com/rust-lang/rust/issues/49147... which in turn is blocked on making MIR borrowck the default... Is this unblocked now?
MIR-borrowck is only the default on 2018 edition.
I assume #49147 would have an effect on both 2015 and 2018 editions?
@pnkfelix alright... so uhm; its unblocked for implementation on 2018 then? or should we wait before MIR-borrowck is extended to 2015 as well?
yeah it would, but maybe we can experiment on 2018 only for now?
(we do have other features that are only enabled when NLL is turned on. Namely #![feature(bind_by_move_pattern_guards)]
; see PR #54034 )
@pnkfelix haha; implemented 4 years later =P :tada:
So, assuming 1. #49147 would continue to have its own feature gate and 2. #49147 is truly only blocked by NLL, then I would not be opposed to treating it analogously to #54034
@pnkfelix btw... is #54034 stable on 2018?
nope
it just suggests the feature gate
there's a series of comments from me about this on #15287
oh that reminds me
#45600 is probably related to your in-progress RFC you pointed to earlier.
ill have a look
(added corresponding link)
@pnkfelix btw; isn't https://github.com/rust-lang/rust/issues/15287 supposed to be tagged T-lang?
The heart of #45600 (as it currently stands) is that we reject this:
struct Foo(String, String); fn x(f: Foo) { match f { Foo(a, ref b) => {} } }
but there might not be a good motivation for rejecting it at this point.
@pnkfelix btw; isn't https://github.com/rust-lang/rust/issues/15287 supposed to be tagged T-lang?
sure that sounds reasonable, given the current status.
aight; adding
@pnkfelix re. #15287 -- does it need to block on making NLL default on 2015 or could we stabilize to 2018 first and then backport?
well one might claim it might be good to keep the set of features enabled by NLL somewhat contained until we've managed to release it more broadly
(at least in migrate mode)
@pnkfelix yeah that's a reasonable objection
But I don't actually have much preference one way or another.
same
added note to the comment to try to capture that alternative
@pnkfelix I'll nominate for lang.mtg.next to see what we want to do