Skip to content

Conversation

tomjw64
Copy link

@tomjw64 tomjw64 commented Aug 26, 2023

Here's an alternative approach to support 64 bit integer types than the one taken in #112.

Rather than blessing one approach, with #119 being merged, it seems like it's possible to accept this oddity of TypeScript/JavaScript and force users of Typeshare (or rather, only those using it to output TypeScript) to make a decision appropriate for them and their use-case.

More or less resolves #24

@wyatt-herkamp
Copy link

I swapped my install to this this fork. It is working.

@tomjw64
Copy link
Author

tomjw64 commented Nov 9, 2023

@Lucretiel @inquisitivepenguin Sorry to bother, but could I get a review on this?

@annie444
Copy link

annie444 commented Feb 9, 2024

This closes #112 for sure. A very beautiful solution I might add!

@mattyg
Copy link

mattyg commented Feb 18, 2024

I'd like to see this included as well.

You may also want to add u128 and i128 to the supported types.

@mattyg
Copy link

mattyg commented Mar 14, 2024

@anish-1p sorry to bother you -- would you mind taking a look at this PR and reviewing or merging? Thank you!

@esmevane
Copy link

esmevane commented Mar 7, 2025

@tomjw64 Thanks for putting this together - I've just followed a trail of breadcrumbs here and you've helped me out a lot!

@bwilliams-sequence
Copy link

@charlespierce can you review this? This is a blocker for many of us working with 64 bits ints.

Copy link
Collaborator

@charlespierce charlespierce left a comment

Choose a reason for hiding this comment

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

Thanks for submitting this! The change seems perfectly reasonable for 64 bit types (i64 & u64). My only concerns are around the pointer-width types usize and isize for two reasons:

  1. These types aren't always the same size depending on the target platform, so translating them into types for other languages could potentially be incorrect.
  2. It seems that the individual language implementations are inconsistent with how they handle usize and isize—Scala & Kotlin treat them as 32-bit integers, Swift & Go treat them as platform-specific size.

The inconsistency doesn't matter currently, since the parser error means they aren't ever instantiated in the first place.

Would it be unusable to make this change for i64 and u64 but leave isize and usize as unsupported types?

@tomjw64
Copy link
Author

tomjw64 commented Jun 12, 2025

@charlespierce Thanks for the review!

Could these both be resolved by also requiring type overrides for isize and usize (but not i64 and u64) for the other languages? That should be a requirement that could get folks unblocked but also that could be relaxed in the future while maintaining backwards-compatibility.

@charlespierce
Copy link
Collaborator

Yeah, updating the other languages to also require an override for usize & isize would definitely be a reasonable solution!

@tomjw64
Copy link
Author

tomjw64 commented Jun 12, 2025

@charlespierce Updated to also require overrides for all languages for pointer sized types and updated docs. LMK if you would like any other changes!

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.

Are usize and i64 not supported?
7 participants