Unsized types

[nrc]

Support unsized types using the type keyword. Use the usual built-in bounds checking rules and forbid in fields. Further checking required before it is safe for DST. Closes issue #12969.

[nrc]

@nikomatsakis r?

[nrc]

I realise I need to prevent unsized fields in enum variants as well as structs. I will do that as a follow-up.

[pnkfelix]

Is there a feature-guard part of this PR for this change? It seems like we should at the very least mark it by a feature guard until DST has gone through the RFC process.

[nrc]

I asked around on irc when I started and the consensus was we shouldn't bother with a feature guard for DST since it was widely accepted. Given that it had discussion before the RFC process existed, I'd be happy to make an exception for it.

[brson]

I need more convincing that type is the right word for this.

[nrc]

Me too! I still prefer unsized, but bowed to irc-peer pressure (I could live with either). @nikomatsakis, @pnkfelix could you try and convince @brson please?

[pnkfelix]

@nick29581 re: feature guard, my motivation is that I don't want newcomers to accidentally start using the syntax without realizing what they are getting themselves into. (Plus, the fact that we are potentially still debating the keyword to use is all the more reason to put it under a feature guard.)

@brson I am not sure what more I can say beyond my blog post. To my eye, the program text:

fn foo<unsized T>(x: &T) { ... }

simply reads wrong, because it to my eye says "T is an unsized type". That is not the right interpretation, because it would be wrong to conclude that the type T is itself unsized. T might be an unsized type. This distinction, between "is" and "might be", is crucial, and I think if we use unsized as the marker, we are inviting a lot of confusion from our user base.

The keyword is meant to be a marker that we are broadening our domain to a strict superset of the defaults you get without the marker, not switching it between two incomparable/disjoint domains. But to me (and I think also for @nikomatsakis), unsized T reads as if it is saying "we are switching from sized to unsized."

This insight, that we are going from the domain sized to the domain sized + unsized (not just unsized), is what led me to conclude that type is a better marker for this notion, since, as I have said, type = sized + unsized.

[nrc]

I hope we can decide on a keyword before landing this, but if we don't lets definitely feature gate it. Otherwise, the keyword doesn't really do anything, so I don't think anyone will use it, coming across it by chance seems unlikely. My concern is with what to actually feature gate - the unsized/type keyword is pretty easy, but further DST features are going to be pretty tricky to cover.

On the keyword, I prefer type for the reasons Felix gives above. I prefer unsized because it has the word size in it, and I feel we should be indicating that it is the size we are doing anything about. Put another way, type = szied + unsized, but also type = vector + scalar or type = monomorphic + polymorphic, etc. There is no indication that this use of type has anything to do with DST.

[pnkfelix]

@nick29581 I quibble with some of the details you state. e.g., until we have higher-kinded types, type = monomorphic, not type = monomorphic + polymorphic, no? So I'm not really convinced by that example.

And when we do add higher kinded types, you still wouldn't use type to represent the higher-order types. I suspect we will want to write those kinds in the same spot, e.g. perhaps with a syntax like:

// `type(type)` is the kind * -> *
fn foo<type(type) F: Functor, X, Y>(x: F(X), f: X -> Y) -> F(Y) { x.map(f) }

---

But still, I do see your point: There may be other places where we discover that we want/need a generalization marker. So we should either

1. figure out how to reuse type for that same purpose (and do so in a backwards-compatible manner, which is the really nasty part of that idea), or
2. make a different generalization marker for each case, or
3. hope we do not actually discover such a need.

I've been hoping for (3.), but I guess I should give more consideration to it possibly happening.

E.g. to give a concrete example, lets say we discover that we've been thinking of all types as belonging to values made up of Bits, but in the future with quantum computing, we discover the need to generalize to Qubits in some types/values. And for some reason, this choice between bits and qubits leaks into the kinds of the types themselves, and cannot be encapsulated (much like our distinction between static-sized and dynamically-sized).

But, due to the strange nature of Qubits and what the common use cases are when programming, we still want the default, when you use fn foo<X>, for X to represent something made up of Bits; you have to opt into having a type parameter that could be instantiated with a quantum type.

So, an idea:

I have explained my proposal by saying that <X> desugars to <type X:Sized>; maybe there is some refinement of that that is forward-compatible with future generalization markers; e.g. maybe the desugaring of <X> could depend on which library crates you have pulled in at the compile-time phase.

• So in programs written with all crates that exist right now, <X> desugars to <type X:Sized>,
• but maybe in some future program that does #[phase(syntax)] extern crate quantum; will get a different desugaring of <X> to <type X:Sized + Bits> now, and <type Y:Sized> is actually meaningful: it means that Y can be instantiated even with types that are made up of qubits (as long as those types are not unsized).
• and in a program that does not pull in extern crate quantum, <type X> would still be able to rely on the invariant that any X is made up of bits; it would just denote the current generalization that X could be sized or unsized.

I'm just thinking out loud at this point. (I think niko and I had already dismissed attempting to make the type generalization marker having meaning beyond DST, but now I'm reconsidering that.)

@nikomatsakis any thoughts on the above crazy idea?

[nrc]

@pnkfelix to return-quibble, I meant types with zero type parameters vs types with one or more type parameters as opposed to types vs type constructors. But yeah, it was a silly example to illustrate that type could mean other things.

You spelling out of the non-future proof-ness of type makes me even less of a fan, sorry.

[pnkfelix]

maybe the marker should be [un]sized.. With literal brackets. I'm actually not kidding.

fn foo<[un]sized T>(x: &T) { ... }

[pnkfelix]

Or make use of question mark:
fn foo<sized? T>(x: &T) { ... }

[nrc]

After a bit of bikeshedding on irc, I think we came up with an idea which we could both stomach, which is to allow generlaisation bounds before a type variable marked with ?. So the unsized syntax would be fn foo<Sized? T>(x: &T) { ... }. We could theoretically support other generalisation bounds, e.g., fn foo<Send? T>(x: &T) { ... } or even combinations fn foo<Sized+Send? T>(x: &T) { ... } but these are hypothetical since we didn't think any other bound makes sense here (since none of them are on by default and therefore need generalising), but at least it demonstrates the design is future proof.

[nrc]

This PR is superseded by #13398. The discussion here is not addressed in that PR and is still relevant.