Proposal for new floating point and integer data types

Rick Waldron waldron.rick at
Sat Oct 26 21:06:01 PDT 2013

Sorry for the top post, but I recommend reading this:


On Saturday, October 26, 2013, Brandon Andrews wrote:

> I've seen posts asking for optional strong typing (often relating to
> typescript), but not many asking for data types. I think since the process
> takes a while it would be a good idea to consider adding extra data types
> on top of the already existing dynamic ones. I'll keep each comment short
> since everyone here is probably familiar with how Actionscript did their
> type specs. I'd like to discuss proposing these data types to start:
> int,int8/16/32/64
> uint,uint8/16/32/64
> single (32-bit IEEE 754)
> double (64-bit IEEE 754 as an alias for Number)
> These correspond to most computer hardware and have fairly standard
> instruction set operations on them. The goal here is mostly to bring
> ECMAScript closer to a generic bit based computer. These types are fairly
> standard across hardware and are well understood in other languages.
> var foo: uint16 = 100;
> var bar: uint64 = foo;
> var baz = bar >> 58;
> This would in turn expand things that JavaScript was never able to do,
> which is to work with 64-bit types. (The idea being this could be expanded
> later for higher bit types).
> This would translate to functions:
> function Foo(a: int32, b: int32): int32
> {
>     return a + b;
> }
> var foo = new function(): void { }
> Then expanding more, users would be allowed to type functions making
> function parameters easy to understand:
> function Foo(a: function(a: int32, b: int32): int32): void
> {
> }
> Other type specifications allowed would be bool, string, and object with
> the concept that classes would fit seamlessly into the typing when added
> later.
> Some specific rules would be applied. Integer data types would not throw
> exceptions when overflowing keeping them simple. Any binary operation would
> immediately convert a single and double type to corresponding uint32 and
> uint64 data types.
> The untyped Number data type would convert to any of the other types if
> possible. It would be up to the programmer to ensure a Number variable fits
> into the required data type.
> var foo = 1000;
> var bar: uint8 = foo; // 232
> However a programmer could explicitly convert the type with the following
> syntax:
> var foo = (10 * 100): uint8;
> This proposal would also include changes to Array, Map, and Set with a
> generic type syntax found in C#:
> var foo = new Array<int8>(100); // Identical to Int8Array
> var foo = new Array<string, int8>();
> var foo = new Map<int32,object>();
> var foo = new Set<object>();
> It would work as one would expect only accepting a specifically defined
> type.
> int and uint would correspond to big integer data types which would remove
> any current limitation with integer based math. they would support syntax
> for typed array like views.
> var foo: uint = 9999999999999999999999999999999999999;
> var bar: Array<uint8> = foo;
> var baz: uint8 = bar[0];
> These views would also work with the non-big integer types. So:
> var foo: uint32 = 42;
> var bar: Array<uint16> = foo;
> var baz: uint16 = foo[0];
> They would also be the only way to go from an uint32/64 and int32/64 to a
> single or double like:
> var foo: uint32 = 42;
> var bar: single = (foo: Array<single>)[0];
> While more verbose than other possible proposals it keeps with one syntax
> for all bitwise conversions.
> The last edge case I'd like to cover is making the changes work with Math:
> var foo: uint32 = 42;
> var bar: single = Math.cos((foo * 42):double);
> By default the return type would be inferred by the input type or storage
> type (in this case single) and the function would be overloaded for
> different inputs. As another example Math.min and Math.max would return
> their input data type rather than Number when the types are specified.
> Benefits to this proposal would be easier optimization to map to hardware
> and operators. It would also help to alleviate the issues that caused the
> need for the TypeArray spec. That is allowing the user to work with types
> that map to native hardware on the CPU and GPU.
> For developers who work with binary formats this simplifies the usage of
> integer and floats along with their respective binary operators.
> The main issue I see is that big integers are niche so it might be a bit
> naive to include them, but it's something I'd prefer was included as it
> makes the language flexible for the future. The other issue is defining any
> type of generic syntax using <> would need serious discussion if there are
> any issues making the system compatible.
> Future additions this would allow would be function overloading, but I
> left that out as it complicates the proposal.
> I've been looking through the archive for similar discussions as I assume
> something like this has been proposed before. If anyone has any related
> links that would be appreciated along with a discussion of issues or
> compatibility conflicts. (Or general feelings toward adding types in
> general as ECMAscript has been fairly unchanged over the years with regards
> to types).
> _______________________________________________
> es-discuss mailing list
> es-discuss at <javascript:;>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list