Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove static_assert #1096

Merged
merged 1 commit into from
Jun 2, 2015
Merged

remove static_assert #1096

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions 0000-remove-static-assert.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
- Feature Name: remove-static-assert
- Start Date: 2015-04-28
- RFC PR:
- Rust Issue: https://github.com/rust-lang/rust/pull/24910

# Summary

Remove the `static_assert` feature.

# Motivation

To recap, `static_assert` looks like this:

```rust
#![feature(static_assert)]
#[static_assert]
static asssertion: bool = true;
```

If `assertion` is `false` instead, this fails to compile:

```text
error: static assertion failed
static asssertion: bool = false;
^~~~~
```

If you don’t have the `feature` flag, you get another interesting error:

```text
error: `#[static_assert]` is an experimental feature, and has a poor API
```

Throughout its life, `static_assert` has been... weird. Graydon suggested it
[in May of 2013][suggest], and it was
[implemented][https://github.com/rust-lang/rust/pull/6670] shortly after.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: Should be [text](url), not [text][url]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll fix this if it's about to get merged.

[Another issue][issue] was created to give it a ‘better interface’. Here’s why:

> The biggest problem with it is you need a static variable with a name, that
> goes through trans and ends up in the object file.

In other words, `assertion` above ends up as a symbol in the final output. Not
something you’d usually expect from some kind of static assertion.

[suggest]: https://github.com/rust-lang/rust/issues/6568
[issue]: https://github.com/rust-lang/rust/issues/6676

So why not improve `static_assert`? With compile time function evaluation, the
idea of a ‘static assertion’ doesn’t need to have language semantics. Either
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how CTFE obviates the desire for static_assert. If anything, I think CTFE makes static_assert much more powerful. CTFE allows us to calculate things at compile-time, and static_assert then lets you abort compilation if a given CTFE expression doesn't have the expected value.

That said, with CTFE, I'd expect static_assert to take the form of a macro static_assert!(condition[, message]).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was under the assumption that in a macro, you could just panic, or use something like https://github.com/huonw/compile_msg 's compile_error, which would outright replace the current static_assert.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what the current thinking is on CTFE, but I'm a little skeptical that panicking is something that would be compatible with CTFE. Similarly, I don't know whether CTFE would be able to use syntax extensions like compile_error (as opposed to a syntax extension evaluating a CTFE, which is what my proposed static_assert!() would be).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose with CTFE, this static_assert!() macro could be provided by a crate, although it seems like a reasonable candidate to bake into the language (e.g. because the standard libraries might want to use it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't see how CTFE obviates it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, assuming a CTFE where begin_unwind[_fmt] (and whatever other functions are needed for panic!) are const fns (throwing compile errors at runtime) then we could just use the regular assert! macro:

static _assert: () = assert!(FOO);
// Or, in a future Rust where statements are allowed at module-level:
assert!(FOO);

`const` functions or full-blown CTFE is a useful feature in its own right that
we’ve said we want in Rust. In light of it being eventually added,
`static_assert` doesn’t make sense any more.

`static_assert` isn’t used by the compiler at all.

# Detailed design

Remove `static_assert`. [Implementation submitted here][here].

[here]: https://github.com/rust-lang/rust/pull/24910

# Drawbacks

Why should we *not* do this?

# Alternatives

This feature is pretty binary: we either remove it, or we don’t. We could keep the feature,
but build out some sort of alternate version that’s not as weird.

# Unresolved questions

None with the design, only “should we do this?”