I think right now this is straddling a line between two things, and it would be better if we decided specifically which we wanted:
r#ident, where when we reserve-and-stabilize
yeetin Rust 1337, you can use that feature via
r#$yeeton any(*) edition, for which most of the questions are about a tolerable syntax.
But I don't think that conversation would go well on github, so I wanted to start a topic here.
cc @Lokathor of course
I have spoken to approximately one additional person about the RFC outside of the people who were at today's meeting and spoke on zulip and they were, I would describe it as "violently positive" about the idea of being able to get features into usage without worrying about syntax details.
I would agree with them and say that "get features into usage earlier" is my main vote, and then "use new stuff even in previous editions in some ugly way" is just an accidental side benefit.
The thing I worry about is that syntax choices being hard is a lang team process social problem, and needn't actually be the long pole for most things. Getting the semantics into a form that we're willing to commit to forever is, in many ways, far scarier to me. For example,
r#$default doesn't solve any of the problems that currently exist with specialization, and it would be easy for us to have stabilized
r#$catch without success-wrapping back in 2017, and it would have been rather suboptimal to be stuck with that forever when the team now thinks that's wrong.
So it's not obvious to me that allowing not-done things on stable is any better of an idea now than it was when the decision was made way back when that feature flags are nightly-only.
(well gosh, now he tells me :P )
But yeah, that's why I tried to be clear that stabilizing a feature via experimental keyword is _possible_ on a case by case basis.
Heck, plenty of people don't even want the syntax arguments to hold up things getting into nightly.
Hmm, that response makes me notice that I did a bad job in the OP for this topic, I think. I'm totally good with
(1) also being "and this is used in nightly for placeholder keywords that aren't yet stable keywords in any edition, and may never be stable", or a 3rd option that also hits that kind of hybrid.
(As a less-hacky option than
do catch and friends)
It's clearly true that syntax discussions are currently _painful_. But having non-final syntax doesn't get us out of those holes; we still need to find a way to have them to decide the final syntax without burning out valuable team members. And as burnout-enducing as await was, it was nowhere close to the long pole in the work to stabilize the feature, near as I could tell.
I wholeheartedly agree with not letting syntax arguments block getting things in nightly.
It's also worth mentioning that if we had stabilized
r#$catch without Ok-wrapping, we could have put surface syntax over that with Ok-wrapping.
I agree; there's nothing that would have stopped us from also having
r#$try that does have it.
It just seems sad to have both versions stable forever.
(Or really surprising if
r#$try doesn't ok-wrap but
Yeah, not going to argue with that.
I left the meeting on the fence. I really like the idea of trying to change our process so that we can separate out the idea of syntax, but I'd like to talk throw in more detail some examples of how we expect it to play out.
I mentioned that Ember has a similar process -- I want to verify that =) and maybe share some details from how it works there.
I think maybe I was wrong to try and link this with
&raw, in the sense that this discussion is perhaps bound to be longer and more thoughtful, and we might want to move on
&raw faster and just consider the possibility that this syntax will get deprecated.
Or at least I think we shuldn't "deploy" a "preview keyword" without some guidance and sense of what we expect the surface syntax to ultimately look like.
I think btw that
preview::raw_borrow captures better the spirit than
@scottmcm seems to me like with
try, there were still open question about semantics even back then, so it basically would not have been eligible for this process
in contrast, with
&raw pretty much the only open question is syntax. that's what this new process is for.
but maybe that's just not common enough to warrant a process?
I expect it to be common.
The "return an error" keyword is in the same boat.
(or, it will be, as soon as we finish working on the Try trait)
To me, "return an error" is the "we picked something and want a way to use it before an edition lets us reserve it", though.
Anything we can do takes 6-12 weeks to get to stable. If we really wanted to, as lang we could just make a decision in a few weeks and be done. Then we say "look, it's
fhqwhgads error;", and that's it. To me, if all the hard parts about
Try are done -- which I suspect will be more than a few weeks to prove out -- and we're de facto stabilizing it, we should just stabilize it de jure.
I think that if lang can't make a decision on something that, while not unimportant, is just a bikeshed in 6 weeks, we should fix the lang process, not add a new kinda-not-stable-but-still-stable feature channel. We have things where we're deadlocked on much harder questions about whether something is needed, but keyword choices really doesn't feel like one of those fundamental conflicts.
(Unless there's some material facts of which I'm unaware that have changed since the decision was made that experimentation happens in nightly. And none of what I say here is meant to imply that we couldn't have both
r#$fhqwhgads on nightly for people to try both, if people decided that would be valuable.)
dunno, I feel like picking good syntax is actually genuinely hard, so I dont think "it took us 3 months to find good syntax" is necessarily a process failure