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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
