Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsigned numbers in Okio #536

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

bnorm
Copy link
Collaborator

@bnorm bnorm commented Nov 12, 2018

Fixes #513

@bnorm bnorm changed the title Unsigned numbers in Okio [WIP] Unsigned numbers in Okio Dec 27, 2018

/** Marker interface for APIs related to unsigned numbers. */
@Experimental
annotation class OkioUnsignedApi
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to have our own experimental annotation or pass through the ExperimentalUnsignedTypes annotation?

On one hand it would be nice to have our own annotation so we don't have to become non-experimental when unsigned types do, but on the other I don't see this API changing much. I'm leaning towards removing OkioUnsignedApi, let me know if you want me to keep it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would pass it through the original because we're using their types in the public API. If we were using them as implementation detail only I would prefer our own annotation.

@bnorm bnorm force-pushed the bnorm.1109.unsigned branch 2 times, most recently from 5e0317e to 62974a0 Compare January 30, 2019 23:19
@bnorm bnorm changed the title [WIP] Unsigned numbers in Okio Unsigned numbers in Okio Jan 30, 2019
@swankjesse
Copy link
Collaborator

The annotation is the most interesting part of this. I think my preference is to publish this as a gist or sample until unsigned types are stable.

@bnorm
Copy link
Collaborator Author

bnorm commented Feb 5, 2019

I would be fine with either a sample or gist. I think I would lean to a sample as it will force us to update it if unsigned types ever change and might make it easier to find.

@swankjesse
Copy link
Collaborator

Good call. Make is so!

build.gradle Outdated
@@ -10,7 +10,7 @@ buildscript {
'assertj': '1.7.0',
'shadowPlugin': '4.0.4',
'nodePlugin': '1.2.0',
'ktlintPlugin': '5.1.0',
'ktlintPlugin': '7.1.0',
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old version didn't like unsigned literals in the samples project. Not sure why it was okay before.

Copy link
Collaborator

@swankjesse swankjesse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bnorm sorry for sitting on this!

Add sample for the experimental unsigned numbers introduced in Kotlin
1.3. New sample inline extension functions on BufferedSource and
BufferedSink which allow reading and writing with unsigned numbers.
@swankjesse
Copy link
Collaborator

Still waiting on unsigned types?

@ImUrX
Copy link

ImUrX commented Feb 13, 2023

😭

@ImUrX
Copy link

ImUrX commented Apr 21, 2024

whats missing from this? it would really nice to have it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BufferedSource.readUByte etc.
4 participants