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

Add sub-64-bit integer types as primitives. #29

Open
elucent opened this issue Oct 4, 2021 · 1 comment
Open

Add sub-64-bit integer types as primitives. #29

elucent opened this issue Oct 4, 2021 · 1 comment
Labels
planned feature Planned feature for upcoming language revision.

Comments

@elucent
Copy link
Contributor

elucent commented Oct 4, 2021

Basil should support integer types with widths less than 64 bits.

Similar to Go's primitive int types, I propose redefining the current Int type as a generic "best size" integer type equal to the word size of the target architecture. We'll augment this with types with explicit sizes: I propose I8, I16, I32, and I64 for brevity's sake.

Some open questions associated with this feature:

  • Should we include unsigned integers in the language? What should their semantics be (specifically w.r.t. type coercion)?
  • Is there a compelling reason to define a distinct equivalent of C's intptr_t? Word-sized Int should be equivalent to this on most modern systems - perhaps we could even specifically define Int as pointer-sized?
  • Should we consider generalizing ints for arbitrary bit-widths? I128 could have some uses. What about atypicalwidths like I7 or I50?
@elucent elucent added the planned feature Planned feature for upcoming language revision. label Oct 4, 2021
@dumblob
Copy link

dumblob commented Oct 4, 2021

Similar to Go's primitive int types, I propose redefining the current Int type as a generic "best size" integer type equal to the word size of the target architecture. We'll augment this with types with explicit sizes: I propose I8, I16, I32, and I64 for brevity's sake.

👍

  • Should we include unsigned integers in the language? What should their semantics be (specifically w.r.t. type coercion)?

They're very dangerous but offer some potentially guarantees for low-level programming. I'd actually not support them and instead case-by-case added support for the kind of situation unsigned ints were/are being used in the wild (e.g. fixed-width bit registers/maps).

  • Is there a compelling reason to define a distinct equivalent of C's intptr_t? Word-sized Int should be equivalent to this on most modern systems - perhaps we could even specifically define Int as pointer-sized?

I can't think of any compelling reason to define them distinct (and I'm pretty sure it's a solvable problem in the given highly specific case if this proves false at some point later). Many new languages do not define them distinct.

  • Should we consider generalizing ints for arbitrary bit-widths? I128 could have some uses. What about atypicalwidths like I7 or I50?

I think, I'd go for that. It has some benefits. Though admittedly it's more work which seems to be the reason I didn't see this in any modern language (the point is, that such computations are usually better suited for BigNums/arbitrary_length_numbers and not just "4x as big integers").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
planned feature Planned feature for upcoming language revision.
Projects
None yet
Development

No branches or pull requests

2 participants