or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Stabilization process
Expected outcomes
Background
the current feature pipeline
case studies
Dyn upcasting coercion #65991
AFIT and RPITIT #115822
TAIT #63063
|T-lang| - 2
approvals and entered FCP which was then blocked on updating thereference
Key questions for discussion
The key question is whether and how to improve the stabilization process for types team decisions. Maybe during lunch?
Did a significant Types Team issue ever slip through
We still haven't reached a very good design/impl for RPIT? There are currently 2 unsound issues. There are multiple backcompat hacks for it as well. I still feel like it was alright-ish to stabilize it? TAIT stabilization nearly slipped through.
Priorities for stabilization
May be good to have some chats about our priorities, not necessarily rn. From @BoxyUwU "would be nice maybe to have a policy of not stabilizing features that have soundness bugs that are not just "the same" as pre-existing ones".
Ideas on how to improve the process
Related issues
Require a T-types FCP when using unstable features in std. We're currently stuck with specialization because std uses it in a user-facing way: "does
vec.into_iter().collect::<Vec<_>>()
allocate". This is blocking changes to specialization, which is an issue given that it is hard to soundly support with the new solver. There have also been attempts addingfeature(generic_const_exprs)
to std. Potentially add an "allowed features in std" file checked by tidy and pinging T-types if it is changed?Notes, minutes from the meeting itself
Questions
dyn Trait upcasting
https://github.com/rust-lang/rust/issues/65991
CE: I feel this is blocked without a clear path forward.
lcnr: The original FCP didn't have enough details at all.
CE: It feels too defensive.
Jack: We want things proven out in a-mir-formality, but that should be early in the process.
NM: I'm fine unblocking it. The FCP there didn't go into detail on the implementation. But it did go into detail on the T-lang issues, the user-facing issues. So it's an issue of things going well and things that could be better.
Have there been any recent features proposed/accepted that overlap with T-types?
The case studies are all "old". I guess RPITIT?
lcnr: Linking to the relevant source code could be useful to the experts.
NM: Linking to the dev guide makes me happy, as it's persistent. I'd like stabilization reports to link to other persistent documents in general.
Jack: The stabilization report shouldn't have any new questions. One thing that is difficult is when new questions come up in the thread where the stabilization report is posted.
NM: I liked how this worked out. We kept older drafts:
https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety-2.html
TC: To Niko's point about persistent documents, as well as to the point of adding more detail to stabilizations, one option is to use RFCs and the RFC process for stabilization.
(Discussion about pros/cons of that.)
NM: I really like having repositories for things.
NM: I would like a stabilization report that has sections per team.
NM: Part of this is a cultural issue; i.e. reminding people to do things and fill things in. Maybe the template should be a kind of checklist that's started after the RFC is accepted that leads toward stabilization.
Niko thoughts
Strong agree with template on stabilization reports, these are confusing right now. I think making progress on a-mir-formality / spec would help here too.
Would like to modify rfcbot to enable t-types members to block any t-lang stabilization. (I'd probably be ok allowing ANY rust team member to block ANY stabilization, but allow the team to override that block; lang has a policy that we can also override the objection).
Brute force change would be to add t-types as FCP to all stabilization. I'm reluctant to do that because slow. But maybe it's a good idea.
(TC: Another brute-force approach; an +I-lang-nominated with a list of concerns from a T-types member (or the team as a whole) would almost certainly have the same effect.)
One thing I really like:
When stabilizing, make it very concrete what the questions for each team are. I've tried to do this but I think we could do better.
some notes
nikomatsakis: similar things arose with this specific question, I made the link…
Stabilization template:
evaluate
/confirm
/fulfill
/project
/Instance::resolve
Next steps:
https://docs.google.com/drawings/d/11KtHLYsqJzi2_Y3mOBz2FbXeG3verSHz-PFBuiwYIQw/edit
FCP process: