add docs for never type #206

canndrew · 2018-01-21T14:11:57Z

No description provided.

alercah · 2018-01-21T14:30:56Z

src/types.md

+
+The never type `!` is a type with no values, representing the result of
+computations that never complete. Although it has size `0` the empty bit
+pattern is not a valid representation. Expressions of type `!` can be coerced


I'm not sure what the comment about a representation is intended to mean; since it has size 0, it has no representation, I thought?

An n-bit type has 2^n possible bit-patterns that can represent values. bool is represented as a byte, but only two of the 256 different bit-patterns are valid values: [00000000] (false) and [00000001] (true).

() is size 0 which means it has one bit-pattern: the empty array of bits []. In the case of () this represents the value ().

! is size 0 but it the empty array of bits does not represent any value.

Ah, right, I see what you're saying. Is that actually true, though? It seems to me that it's more accurate to say that () has one value, but no representations. Rust generally doesn't try to encode a representation of (), for instance, Vec<()> is effectively just a length field.

I'd probably just drop the sentence; I don't think it adds more clarity.

Okay, fixed.

alercah · 2018-01-21T14:31:30Z

src/types.md

+The never type `!` is a type with no values, representing the result of
+computations that never complete. Although it has size `0` the empty bit
+pattern is not a valid representation. Expressions of type `!` can be coerced
+into any other type.


I think type-coercions.md should be updated too?

Thanks! Done.

matthewjasper · 2018-01-21T14:46:39Z

The section on diverging functions will also need some changes. At least this sentence has to be removed

https://github.com/rust-lang-nursery/reference/blob/6608583d99d33cbfa643607d48e5d12cef682134/src/items/functions.md#L111-L112

cc rust-lang/rust#47630

canndrew · 2018-01-21T15:22:01Z

I've removed the section on diverging functions entirely since they're no longer special.

alercah · 2018-01-21T16:49:13Z

They're still special though, because they cause code afterward to be unreachable. The example there about using the diverging function to conclude that f will always return an i32 (the coercion from ! to any other type is not applicable there, because the statement calling my_err has type (), not !).

mrhota

I think the divergent functions section should stay, but it needs to be updated to account for the never type. I also think you should keep the link in the loop section to either (or both?) the divergent functions section or the new Never type section.

mrhota · 2018-01-22T05:34:26Z

src/expressions/loop-expr.md

-may terminate, and must have type compatible with the value of the `break`
-expression(s).
+A `loop` expression without an associated `break` expression is diverging and
+so has type `!`. A `loop` expression containing associated 


Can you link to the new Never type section you created?

And can you rephrase the end of the first sentence to one of these?

"expression is divergent and has type !."

"expression diverges and has type !."

"and so" is redundant.

mrhota · 2018-01-22T05:39:57Z

src/items/functions.md

@@ -93,52 +93,6 @@ sufficient context to determine the type parameters. For example,

 [path]: paths.html

-## Diverging functions


Why remove this? The information about what constructs produce the ! return type remains useful. Also, the new section below doesn't use "diverges", "diverge", or "divergent", though we make use of "diverges" in the section about loop {}s.

I say just keep this section in tact, with adjustments to account for new thinking about the Never Type.

There's not really a good reason to have information on divergence in the function items page. Perhaps mention in the function call and method call operators that calling a function that returns ! diverges? Divergence sort of needs its own section in the Expressions page itself, I think? I haven't thought too much about whether it's a property of expressions, statements, or both? And that can be done separately from this.

It would be nice to pull the example into the Never type docs though.

I agree with @Havvy here. Divergence isn't specifically a property of functions, it's its own thing entirely and really needs its own section. I don't fully understand the semantics of it though, so I'm not confident that I'd be able to write that section.

Yeah, put the information where ever you think it fits best, but I don't want to lose the information.

Maybe someone like @arielb1 can help here. Is this an accurate-enough description of type-checking w.r.t divergence and !?

Expressions of type ! cause everything in the computation graph after the ! to be marked unreachable.

If a block ends in a statement, and the end of the block is unreachable, then the block has type !.

I know it's not exactly implemented like this in the compiler, but have I left out any relevant caveats? Do you think the reference needs a section on divergence separate from !?

I'll make sure that divergence information doesn't get lost before the next beta, even if this PR loses it.

canndrew · 2018-01-24T15:33:39Z

They're still special though, because they cause code afterward to be unreachable.

That's true of any diverging expression though, not just function calls. I can do:

struct ContainsNever {
    never: !,
}

fn mk_it() -> ContainsNever  {
    panic!("aah");
}

fn main() {
    let wow: ContainsNever = mk_it();

    println!("rustc thinks this is reachable");

    let _n = wow.never;

    println!("but this is not");
}

The example there about using the diverging function to conclude that f will always return an i32 (the coercion from ! to any other type is not applicable there, because the statement calling my_err has type (), not !).

It would be more correct to say that the entire else block diverges and therefore has type !. Even though it doesn't end in an expression.

canndrew · 2018-02-01T08:15:55Z

Is there anything else that needs to be done for this PR? The section on diverging functions that I removed didn't contain any information which isn't now completely redundant. All of it just boils down to "if you declare something to have type T then it must really have type T"

Havvy · 2018-02-04T03:37:05Z

src/items/functions.md

@@ -123,4 +123,4 @@ As non-Rust calling conventions do not support unwinding, unwinding past the end
 of an extern function will cause the process to abort. In LLVM, this is
 implemented by executing an illegal instruction.

-[external blocks]: items/external-blocks.html


Unrelated to this PR, but why does this keep showing up? And why this time in a file that is otherwise untouched?

Havvy · 2018-02-11T03:01:27Z

In the special types and traits page, can you add the never type to the list of copy types?

canndrew · 2018-02-12T14:59:17Z

@Havvy done.

matthewjasper · 2018-03-15T22:25:43Z

! is stable now, can you fix the merge conflict so that this can be merged?

I'll make sure that divergence information doesn't get lost before the next beta, even if this PR loses it.

@Havvy are you still happy to do this?

Remove section on diverging function since they are no longer special. Modify wording around description of `loop` accordingly. Add `!` to any coercion to list of coercions.

canndrew · 2018-03-16T04:51:08Z

@matthewjasper done.

matthewjasper · 2018-03-16T12:26:09Z

Thanks! 💟

alercah reviewed Jan 21, 2018

View reviewed changes

mrhota suggested changes Jan 22, 2018

View reviewed changes

Havvy added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Jan 30, 2018

Havvy reviewed Feb 4, 2018

View reviewed changes

Havvy approved these changes Feb 12, 2018

View reviewed changes

canndrew added 4 commits March 16, 2018 12:49

add docs for never type

1d9be09

updates for ! type stabilisation

ae2211d

Remove section on diverging function since they are no longer special. Modify wording around description of `loop` accordingly. Add `!` to any coercion to list of coercions.

Fix some nits around ! changes

fdab668

Add ! to list of Copy types

8671941

canndrew force-pushed the never_type branch from dda8bd1 to 8671941 Compare March 16, 2018 04:50

matthewjasper merged commit 75b8ec9 into rust-lang:master Mar 16, 2018

Havvy mentioned this pull request Mar 17, 2018

Divergence #271

Open

Havvy mentioned this pull request May 22, 2018

Never type was unstabilized #344

Closed

ehuss mentioned this pull request Oct 23, 2018

Split Types Chapter #454

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add docs for never type #206

add docs for never type #206

canndrew commented Jan 21, 2018

alercah Jan 21, 2018

canndrew Jan 21, 2018

alercah Jan 21, 2018

canndrew Feb 1, 2018

alercah Jan 21, 2018

canndrew Jan 21, 2018

matthewjasper commented Jan 21, 2018

canndrew commented Jan 21, 2018

alercah commented Jan 21, 2018

mrhota left a comment

mrhota Jan 22, 2018

mrhota Jan 22, 2018

Havvy Jan 22, 2018

canndrew Jan 24, 2018

mrhota Jan 24, 2018

canndrew Jan 24, 2018

Havvy Jan 25, 2018

canndrew commented Jan 24, 2018

canndrew commented Feb 1, 2018

Havvy Feb 4, 2018

Havvy commented Feb 11, 2018

canndrew commented Feb 12, 2018

matthewjasper commented Mar 15, 2018

canndrew commented Mar 16, 2018

matthewjasper commented Mar 16, 2018

		@@ -93,52 +93,6 @@ sufficient context to determine the type parameters. For example,

		[path]: paths.html

		## Diverging functions

add docs for never type #206

add docs for never type #206

Conversation

canndrew commented Jan 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matthewjasper commented Jan 21, 2018

canndrew commented Jan 21, 2018

alercah commented Jan 21, 2018

mrhota left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

canndrew commented Jan 24, 2018

canndrew commented Feb 1, 2018

Choose a reason for hiding this comment

Havvy commented Feb 11, 2018

canndrew commented Feb 12, 2018

matthewjasper commented Mar 15, 2018

canndrew commented Mar 16, 2018

matthewjasper commented Mar 16, 2018