Language support for BufferView

[atrick]

This roadmap discusses the language and compiler features required to implement a "BufferView" type in Swift. Non-copyable and non-escaping types provide the language foundation for BufferView. These new type constraints provide stronger guarantees about the ownership and lifetime of their values. Such guarantees make it possible to design safe, efficient libraries based on a "container/view" programming pattern. Although, we expect this programming pattern to be broadly applicable, BufferView is a particularly important use case because Swift developers need safe and efficient views over a container's contiguously stored memory.

[benrimmington]

The roadmap uses "non-escaping" rather than "non-escapable".
Should the constraint be ~Escaping rather than ~Escapable?
(This is also consistent with the attribute for @escaping closures.)

[atrick]

Should the constraint be ~Escaping rather than ~Escapable?

I don't have much of an opinion. I expect plenty of bike-shedding. It isn't set in stone until we have a formal evolution proposal. We'll keep updating this document in the meantime.

We regularly talk about non-escaping values, which relates to the context in which a value is used. When talking about types, I could start using the term non-escapable if that matters to people.

I do think we'll end up with ~Escapable syntax which is analogous to ~Copyable. This is preferable when talking about negating a capability of the type.

It seems pointless to change @escaping at this point. I'm fine with slightly different terminology for these things, which have slightly different semantics.

[atrick]

Closing because this is a design exploration and roadmap for future proposals rather than a "vision" document. For future reference, refer back to the forum post.