I like this idea in general.
It might be more discoverable in the editor too (via code completion)

We must be careful: ByteBuffer must correspond to ArrayBuffer in the Typed Array Specification. http://www.khronos.org/registry/typedarray/specs/latest/#­5
I don't think this proposal has any problems in this regard.
(The main thing to avoid is adding any data access methods to ByteBuffer.)

As proposed, the signatures are slightly wrong: the last parameter is a length measured in the view unit, defaulting to the maximum legal view; for example, you get a view of 2 Uint32 values out of a 10 byte buffer starting at offset 0.

Maybe the methods should still contain the word 'view'

  abstract class ByteBuffer {
    ...
    Int8List viewAsInt8List([int offsetInBytes = 0, int length]);
    Uint8List viewAsUint8List([int offsetInBytes = 0, int length]);
    ...
    Float64List viewAsFloat64List([int offsetInBytes = 0, int length]);
    ByteData viewAsByteData([int offsetInBytes = 0, int length]);
  }

  factory Uint8List.view(ByteBuffer buffer, [int offsetInBytes = 0, int length]) =>
      buffer.viewAsUint8List(offsetInBytes, length);

If we make this change, I would want to mark the T.view constructors as deprecated, and find some way to document for each T that a T can be created from a ByteBuffer.

One thing that is slightly more tricky: dart2js could easily see an explicit length argument to the constructor and do better type analysis and eliminate bounds checks from fixed-sized views. This is more difficult with the indirection.

It appears that this suggestion is implemented in https://code.google.com/p/dart/source/detail?r=37974

1. Should we mark the matching factory constructors as deprecated?
2. I think the documentation on the methods could be improved

  /**
   * Creates a new [Uint32List] view of this buffer.
   */
  Uint32List asUint32List([int offsetInBytes = 0, int length]);

This contains much less information than the matching factory constructor

  /**
   * Creates a [Uint32List] view of the specified region in
   * the specified byte buffer. Changes in the [Uint32] will be
   * visible in the byte buffer and vice versa. If the [offsetInBytes] index
   * of the region is not specified, it defaults to zero (the first byte in
   * the byte buffer). If the length is not specified, it defaults to null,
   * which indicates that the view extends to the end of the byte buffer.
   *
   * Throws [RangeError] if [offsetInBytes] or [length] are negative, or
   * if [offsetInBytes] + ([length] * elementSizeInBytes) is greater than
   * the length of [buffer].
   *
   * Throws [ArgumentError] if [offsetInBytes] is not a multiple of
   * [BYTES_PER_ELEMENT].
   */
  factory Uint32List.view(ByteBuffer buffer,
                          [int offsetInBytes = 0, int length]) {
    return buffer.asUint32List(offsetInBytes, length);
  }

The asXXX method should contain the same information, perhaps simplifying the factory constructors to say they are the same as the asXXX methods.

I would also suggest improving the original descriptions with an additional paraphrasing of the constraints, i.e. the view is within the bounds of the buffer, the view is must be aligned to the element type.

cc @lrhn.

That's done.