We're still figuring that out. 
Expect to see more pitches and discussion of this in the very near future.
To elaborate a bit on the sketch I posted here, Joe's roadmap vision, and John's "Ownership Manifesto" there are a bunch of things we need to sort out:
- New language features to provide ways to manage data without copying. (SE-0366) (SE-0377) (@noImplicitCopy) (others coming soon)
- Concrete move-only types that don't involve generics
- Support for move-only types as generic type arguments
- New standard library features (such as BufferView)
- Retrofitting existing standard library support (which rests heavily on generic support, of course)
And of course, we need to ensure that the optimizer is fully aware of all this new machinery as we proceed.
The first item above has proven to be larger than I initially expected. In retrospect, it's pretty obvious that "non-copyable types" aren't all that useful if the basic language constructs expect to copy everything. 
We may be able to change a few core constructs to eliminate the copying assumptions, but we'll also need to extend the language with new operations such as the ones linked above.
As those fundamentals come together, we should soon be able to show prototypes of actual working move-only types (#2). And we think there are a few places in the standard library where we can use move-only types without generics (parts of #4).
But I am not optimistic that we'll get everything above done this year. In particular, the generic support (#3 and #5) is going to require some delicate surgery to Swift's type system and we want to take time to make sure we get that right.
Tim