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
Never type discussion
The revised proposal is:
!
on 2024 edition.unsafe
function.deny-by-default
or a hard error in Rust 2024.!
.!
always everywhere.Infallible = !
.!
(!).Analysis of that
objc
bug:Playground link
Discussion
Attendance
Meeting roles
Fallback to type you can't write
NM: In Rust 2024, this would mean we'd fall back to a type you can't write. Is that a problem?
NM: You can always coerce it to any other type. I don't see any immediate problems.
What does it mean to pass a type to an unsafe function?
NM: What does it mean to pass a type to an unsafe function?
TC: Here's the
objc
example (minimized):NM: Is the lint just for the top-level types or also nested?
Waffle: Also nested.
NM: How much code are we expecting this to affect?
Waffle: Probably not much.
NM: I suppose that we could tune this over time. It's just a lint after all.
NM: E.g., if the type appears in the input arguments, then it should be fine, because you must have produced a value of it.
Waffle: That sounds fine, but I don't want to only look at the return type because you could still create UB by creating a value of the type only within the function.
NM: I'm wondering about a case like this:
Waffle: There may be something like this possible, but I have a hunch that this is rare.
NM: Probably, and it'd be better to tune based on real examples.
Missing unsafe
NM: Let's talk about this:
NM: This is buggy, of course, but we wouldn't detect this.
NM: Maybe we could lint to say this function should be
unsafe
. But how?Waffle: What the lints would say is that since you're producing a value that is unbounded and the function is safe…
Waffle: It's clear to a human that this function is unsound because you can give it an
R
that causes UB. Not sure how we teach the compiler to do this in general.NM: We're trying to say:
R
where…R
was produced by an unsafe function that can return any value, perhaps one from a known set (e.g., zeroed, transmute)…R
is a type parameter without any unsafe trait in the bound…NM: This isn't a blocker; but it's a good idea for a lint.
The "deserialize" pattern and
?
interactionsnikomatsakis: My other concern has been the interaction with
?
, which imo is deeply surprising, and things like:TC: The proposal to change the
?
desugaring:https://github.com/rust-lang/rust/pull/122412
NM: What occurs to me is that in arms where control-flow is dead, they don't contribute to the type… but of course they do right now.
Waffle: It's an interesting idea, but I'm not sure it fits into Rust. I'm not sure we have any control-flow specific things like that.
NM: I'm not sure that's true, but nonetheless I agree. It's not as good as something that could be more type based. E.g. I'd prefer if this worked the same way, and there are many other variations:
NM: It may be possible to change
coerce_many
to handle many but not all cases. It wouldn't work when we needed information that is only available later in the process. If we could find a way to solve this I'd have basically no qualms.NM: The first lint make total sense and we should definitely do it (flowing the unboutd variable into
unsafe
). The second lint (missingunsafe
) is less important but also makes sense and isn't a blocker. Perhaps we could put it in clippy, e.g.Waffle: Regarding
?
, the first step is changing that desugaring. Then we could add a lint.NM: Seems like we have two tenets:
…and you are saying you prefer them in that order and for correctness to be addressed via lint. Why then not apply same reasoning to
?
? It has a simple desugaring…Waffle: Probably for me, the
?
case feels like a leaky abstraction.NM: I value a simple desugaring. I'm probably OK with the lint only. Let's just do the lint only. If we want to change
?
desugaring, we could do that later after we collect data.NM: Probably I want a hard error here. I think we can achieve that with the lint approach. This may require improvements in the implementation of our type system.
Waffle: How would the lint work?
NM: What we're looking for is that you have a type variable that is the target of a coercion from both a fallback variable and a non-fallback variable and that type variable's type is determined by fallback. Graphically:
…and V3's type is determined by fallback.
NM: Would I block on this? I don't know. I would like to see this explored.
"Add a future incompat lint for some/most of the code that will be broken by fallback to
!
."NM: What would this lint look like?
Waffle: I'm hoping to think about the details of this later. We have a crater run going now that turns off fallback entirely. We're hoping to go through some of the examples of breakage here to come up with ideas.
TC: That crater run is:
https://crater.rust-lang.org/ex/no-never-type-fallback
NM: …you had a type variable, and there was a trait matched against it, and its value was determined by fallback. I.e.:
?X
?X
?X: Foo
is a subset but probably the most commonOption<?X>: Foo
or(): Foo<?X>
etc etc?X
is determined by fallbackTwo possibilities:
?X = !
?X = !
Other extraneous cases:
?X: IsEq<?Y>
(impl IsEq<()> for ()
,impl IsEq<!> for !
)?X
falls back to()
, now?Y
becomes()
as a result of second round of trait solving?X: Something<Output = ?Y>
Next steps
TC: So the next steps are:
unsafe
function.Other things:
?
desugaringunsafe
.Waffle: The main work seems to be to implement these lints and to run crater on them to see how code that they flag.
Hard error or
deny-by-default
in Rust 2024?TC: What are your thoughts about making the lint against fallback flowing into an
unsafe
into a hard error or adeny-by-default
lint in Rust 2024?NM: Makes sense to me. We have a policy on
deny-by-default
being when something is almost certainly a bug, and that seems to be the case here.OK on plan?
NM: The plan sounds good to me.