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
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?
The text was updated successfully, but these errors were encountered:
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").
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 proposeI8
,I16
,I32
, andI64
for brevity's sake.Some open questions associated with this feature:
intptr_t
? Word-sizedInt
should be equivalent to this on most modern systems - perhaps we could even specifically defineInt
as pointer-sized?I128
could have some uses. What about atypicalwidths likeI7
orI50
?The text was updated successfully, but these errors were encountered: