RFC: Centralize on special types as a way of informing inference about special constraints

[nikomatsakis]

As part of the discussion in #5922, it became clear that there are a number of cases in which we must inform the compiler about special constraints that pertain to specific types. These constraints almost always arise because of unsafe code that does things the compiler can't know about. We don't have a central mechanism for propagating such constraints:

1. Annotations like #[no_freeze] are used to inform the builtin-bounds.
2. Except for non-copyable, which has a special type.
3. Variance currently has no mechanism, so unused lifetime parameters don't necessarily behave like people expect.

I think we should centralize on one mechanism. My current thought is to employ 0-sized types for this. So we would remove the #[no_freeze] annotations and add types like Nonfreezable, as well as CovariantLifetime<'a> and so on. These would be lang items specially recognized by the compiler.

Nominating and adding to the agenda for next week.

[nikomatsakis]

Some arguments I considered in favor of using marker types:

1. They are discoverable and documentable, in contrast to annotations.
2. They are less intimidating than special syntax.
3. It's easy to add more, unlike special syntax.

[zkamsler]

Marker types seem relatively straightforward to use for structs, but could it result in awkwardness for enum variants, especially because they are more frequently destructured? Even if there they are easily ignored, there is still some programmer overhead in ignoring a field that does not contain any data.

[sfackler]

NonCopyable as it is currenlty implemented (with a Drop impl) has some problems as it should - but doesn't currently - prevent the type from being used in a static variable. The std::unstable::atomics family uses NonCopyable which causes some strange issues like #10577.

[glaebhoerl]

One positive aspect of this is that it commits us to basically nothing in terms of backwards compatibility at the language level. If we later come up with a better way to do these, we can add that and also keep the marker types around without any awkwardness.

[nikomatsakis]

On Fri, Dec 06, 2013 at 06:41:20AM -0800, zkamsler wrote:

...Marker types seem relatively straightforward to use for structs, but could it result in awkwardness for enum variants..

There is an easy workaround. Convert

enum Foo { A(..), B(.., Noncopyable) }

to

struct Foo { v: Foo1, _nc: Noncopyable }
enum Foo1 { A(..), B(..) }
``

and then match on `x.v` instead of `x`.

I think it's not so common though to use enums as the "top-level" type
for unsafe things like `Rc` etc.

[nikomatsakis]

@sfackler I agree that non copyable should be integrated as a lang item into the compiler, though I don't think that we should necessarily prohibit types that contain dtors from appearing as static items (as I explained in that issue at some point).

[nikomatsakis]

cc @thestinger, as one of the bigger users of these sorts of annotations. This was discussed in meeting on dec 10 and generally approved of.

[pnkfelix]

Accepted for 1.0, P-backcompat-libs