Nonescapable stdlib primitives #2657
Conversation
|
|
||
| ### Unsafe bit casts | ||
|
|
||
| To cover a common low-level need that regularly came up while experimenting with nonescapable use cases, we propose to narrowly generalize the existing `unsafeBitCast` function to allow its input value to be of a nonescapable type. |
There was a problem hiding this comment.
This is giving unsafeBitCast new unsafe powers on top of the ones it already has and we won't be able to take them away when the experimentation phase is over. It will prevent mistakes if the function that changes the bit interpretation of a value to something arbitrary can't also change the lifetime to something arbitrary at the same time. The current interface doesn't allow developers to clarify their intent to change only one of these two things.
There was a problem hiding this comment.
We can delay generalizing unsafeBitCast, but I do believe we need to provide a last resort escape hatch, and this function looks like the obvious way to express it. There are very few cases in Swift where developers legitimately need to reach for unsafeBitCast -- its usages stick out like a sore thumb, with or without this generalization.
We are also planning to add a separate function to unsafely override lifetime dependencies, but it will not be capable of type casting like this, so it doesn't seem a viable replacement.
One option is to move this functionality into a new function, with a different name. Such a function may also pave the way towards casting between nonescapable types. Naming suggestions are welcome.
This document proposes to allow
OptionalandResultto hold instances of nonescapable types, and continues the work of adding support for noncopyable and nonescapable types throughout the Swift Standard Library.