We need TypedTuple

[open-novel]

The feature of Tuple, that comparisons between sequences of the same value are considered the same, comes in handy when dealing with binaries in JavaScript.
Therefore, we need an API like the following.
Uint8Tuple, Int8Tuple, ......., Float64Tuple

[lygstate]

Make sense

[rricard]

Hello, can you give more details on how you would use those structures? It could make a potential follow-on proposal but we would have to understand use cases better first.

[Jack-Works]

Binary data that can be compared with ===

[rricard]

Ok, so to me that looks similar to #134, do I have it right? Additionally, I'd like to know how you would construct the binary data on both sides of the ===?

[ghost]

The API ought to be equivalent to that of %TypedArray%:

const binary = Uint8Tuple.of(-1, -2, -3, -4); // Uint8Tuple(4) [ 255, 254, 253, 252 ]

const new_binary = binary.map(u8 => u8 >>> 1); // Uint8Tuple(4) [ 127, 127, 126, 126 ]

const u32_view = Uint32Tuple(binary.buffer); // Uint32Tuple(1) [ 4244504319 ]

u32_view[0] = 2; // TypeError: Cannot assign to read only property '0' of Uint32Tuple

Uint8Tuple.from(Uint8Array.of(1, 2, 3)); // Uint8Tuple(3) [ 1, 2, 3 ]

I believe that such a follow-on proprosal would require introduction of read-only ArrayBuffers alongside it.

[bionicles]

typed records and tuples would be huge for API contracts, codegen, serialization/deserialization, parsing environment variables. +infinity from me. Would use

a typed record is equivalent to a Struct, a convention in other languages also. We could use this to easily map between many languages

[Jack-Works]

Please take a look at https://github.com/Jack-Works/proposal-freeze-arraybuffer-and-readonly-view
It might be able to integrate with the R&T.

[ghost]

a typed record is equivalent to a Struct, a convention in other languages also...

I strongly disagree with this, a struct can store different types, a DataView is closer to a struct. Typed tuples would merely be immutable arrays of a statically-sized integer/float type.

Hopefully we can all agree on, and understand what we are trying to introduce here.

[bionicles]

@crimsoncodes0 totally agree on tuples

sounds like we're talking about different stuff. do you mean, a TypedRecord would be a map, where all the values were the same type? If so, I'm fine with it! I just also think Structs would be handy for javascript, where we could have a variety of different types for the values of different keys.

However, these nice ideas, are almost surely out of scope of the records and tuples proposal, and take us into the realm of runtime static types for javascript, which is a huge can of worms. I'd suggest we finish the records and tuples, and then we could build on it, to bring runtime static types into JS, and make sure both TypedTuples, TypedRecords, and Structs, wind up in that proposal

[ghost]

@bionicles TypedTuples, having been brought so late, would almost certainly have to be a follow-up proposal, being standardized well after R&T has been standardized or possibly implemented.

Structs may be taken care of by the Wasm<->es typed objects proposal when it comes around.

And I was not suggesting anything about typed records or maps, merely that structs may contain other values than the same type.

A TypedTuple would only hold a single type, e.g. Uint8Tuple only holds Uint8s, whereas a C struct could be the following:

struct T {
    Uint8 x;
    Uint32 y;
};

T::x and T::y have completely different types, this couldn't be represented in a TypedTuple.

With a DataView, one could do the following:

function readFromStruct(dataViewOfT) {
    const x = dataViewOfT.getUint8(0, true);
    const y = dataViewOfT.getUint32(1, true);
}

Terribly unergonomic, but better than an array.

[bionicles]

sounds like TypedTuple could save a lot of memory!

[littledan]

It's not the most ergonomic solution, but you can sort of encode a typed tuple as a BigInt. This is relatively efficient in memory and supports ===. I agree with @rricard 's labeling of this as a follow-on proposal, since between ordinary Tuple and BigInt, you can get by to start, and we have time to see what will be needed.

[acutmore]

Related page on the internet: https://github.com/rbuckton/proposal-struct
I'm mentioning this other proposal not as an endorsement but for the sole reason that it might interest some participants in this thread

[rricard]

In order to focus on changes that are necessary to finish this proposal, we are closing issues related to follow-on proposals. You are free to continue the discussion here and reference it in other venues.