Stream: t-lang

Topic: Focusing the direction of RFC#2919 experimental_keywords

scottmcm (May 01 2020 at 02:08, on Zulip):

I think right now this is straddling a line between two things, and it would be better if we decided specifically which we wanted:

  1. The complement to r#ident, where when we reserve-and-stabilize yeet in Rust 1337, you can use that feature via r#$yeet on any(*) edition, for which most of the questions are about a tolerable syntax.
  2. An exploratory option for having some things on stable that in some ways "aren't done yet", for which most of the questions are about stability guarantees.

But I don't think that conversation would go well on github, so I wanted to start a topic here.

scottmcm (May 01 2020 at 02:08, on Zulip):

cc @Lokathor of course

Lokathor (May 01 2020 at 02:12, on Zulip):

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.

Lokathor (May 01 2020 at 02:13, on Zulip):

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.

scottmcm (May 01 2020 at 02:27, on Zulip):

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.

scottmcm (May 01 2020 at 02:29, on Zulip):

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.

Lokathor (May 01 2020 at 02:30, on Zulip):

(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.

scottmcm (May 01 2020 at 02:33, on Zulip):

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.

scottmcm (May 01 2020 at 02:34, on Zulip):

(As a less-hacky option than do catch and friends)

scottmcm (May 01 2020 at 02:38, on Zulip):

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.

scottmcm (May 01 2020 at 02:39, on Zulip):

I wholeheartedly agree with not letting syntax arguments block getting things in nightly.

Josh Triplett (May 01 2020 at 02:52, on Zulip):

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.

scottmcm (May 01 2020 at 02:57, on Zulip):

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.

scottmcm (May 01 2020 at 02:58, on Zulip):

(Or really surprising if r#$try doesn't ok-wrap but try does.)

Josh Triplett (May 01 2020 at 03:22, on Zulip):

Yeah, not going to argue with that.

nikomatsakis (May 01 2020 at 09:26, on Zulip):

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.

nikomatsakis (May 01 2020 at 09:27, on Zulip):

I mentioned that Ember has a similar process -- I want to verify that =) and maybe share some details from how it works there.

nikomatsakis (May 01 2020 at 09:28, on Zulip):

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.

nikomatsakis (May 01 2020 at 09:29, on Zulip):

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.

nikomatsakis (May 01 2020 at 09:29, on Zulip):

I think btw that preview::raw_borrow captures better the spirit than experiment::raw_borrow =)

RalfJ (May 01 2020 at 10:00, on Zulip):

@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

RalfJ (May 01 2020 at 10:00, on Zulip):

in contrast, with &raw pretty much the only open question is syntax. that's what this new process is for.

RalfJ (May 01 2020 at 10:01, on Zulip):

but maybe that's just not common enough to warrant a process?

Josh Triplett (May 01 2020 at 16:58, on Zulip):

I expect it to be common.

Josh Triplett (May 01 2020 at 16:59, on Zulip):

The "return an error" keyword is in the same boat.

Josh Triplett (May 01 2020 at 16:59, on Zulip):

(or, it will be, as soon as we finish working on the Try trait)

scottmcm (May 01 2020 at 17:55, on Zulip):

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#$yeet and r#$fhqwhgads on nightly for people to try both, if people decided that would be valuable.)

RalfJ (May 02 2020 at 09:21, on Zulip):

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

Last update: Jun 05 2020 at 22:05UTC