Make non-native endianness access easier.

[Mehmetyaz]

I want to perform a complex task with library "typed_data". But unfortunately I have to choose ineffective ways at every step.

Unfortunately you have to use a loop to set an typed data array to ByteData:

    // TO WRITE
    for(var i in [1,2]) {
      byteData.setUint16(offset, i);
      offset += 2;
    }
    
    // TO READ
    var l = [];
    while(l.length < count) {
      l.add(byteData.getUint16(offset));
      offset += 2;
    }

If you don't want to use loop, you have a option for writing to ByteData:

    // TO WRITE
    // typedData is Uint32List/Int64List etc.
    // I will read only certain part of [byteData]
    var typedToUint8List = typedData.buffer.asUint8List();
    var uint8List = byteData.buffer.asUint8List()
      ..setRange(offset, offset, typedToUint8List);
    var data = uint8List.buffer.asByteData();
    offset += typedToUint8List.length;

    // TO READ
    byteData.buffer.asInt64List(offset, lengthInBytes);

This option is quite efficient compared to using a loop. We are still copying the byteData on the write operation. There's really no need for this.
BUT, this solution does not seem possible. Because it is not possible to give endianess to methods and the methods use different endian in my example.

Solution

To TypedData

Add method bufferWith(Endian).

So, for example, we can create a ByteBuffer with given endian from a Uint32List.

I may not know exactly how it works in native. Maybe this parameter should be added to ByteBuffer.as*List functions instead.

ByteData

Add set*List(int offset, TypedData value, [Endian endian = default]) and get*List(int offset, int lengthInBytes, [Endian endian = default])

Thanks!

[lrhn]

As with many other things, Dart follows the JavaScript typed array behavior, because it has to be compiled to JavaScript anyway.
JavaScript typed arrays always use the native endianness of the system it's running on (for speed!), and therefore so does Dart.
The goal of typed-data arrays/lists is to be efficient, space and time, otherwise you can just use List<int>.
That's why you are not allowed to use non-native endianness or do unaligned access.

The intended workaround is to use a ByteData or Uint8List view, depending on what you're trying to achieve.

We could probably provide a Uint32BigEndianList and Uint32LittleEndianList (on top of the current, Uint32List, which is native-endianness), but it would suggest that it's actually efficient, which it won't be if it's not using the native endianness.