You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Kotlin being more and more standalone ecosystem, especially in the face of the multiplatform adoption, it would be nice to start moving towards a unified out-of-the-box experience for the core Kotlin functionality.
IO primitives are the unified and common layer for the applications and libraries, and having them in a separate library with its own release cycle and Kotlin compatibility matrix is just an additional burden for the users, esp. taking into account that we do not expect much of changes there after the stabilization. It would be nice to see core primitives (ByteString, Sink, Source, Buffer) in the standard library, leaving kotlinx-io as the additional extensions and fast-paced library for new-coming APIs (filesystems, processes, encodings).
Apart from technical and operational peculiarities, one of the biggest questions for this change is whether we are willing to tolerate unsafe API in the standard library, as it potentially hinders the platform integrity
The text was updated successfully, but these errors were encountered:
With Kotlin being more and more standalone ecosystem, especially in the face of the multiplatform adoption, it would be nice to start moving towards a unified out-of-the-box experience for the core Kotlin functionality.
IO primitives are the unified and common layer for the applications and libraries, and having them in a separate library with its own release cycle and Kotlin compatibility matrix is just an additional burden for the users, esp. taking into account that we do not expect much of changes there after the stabilization. It would be nice to see core primitives (
ByteString
,Sink
,Source
,Buffer
) in the standard library, leaving kotlinx-io as the additional extensions and fast-paced library for new-coming APIs (filesystems, processes, encodings).Apart from technical and operational peculiarities, one of the biggest questions for this change is whether we are willing to tolerate unsafe API in the standard library, as it potentially hinders the platform integrity
The text was updated successfully, but these errors were encountered: