Add "was ever locked" flag for Encoding standard?

[ricea]

The Encoding Standard would like to use "mode locking" to prevent the method API being used after the streams API.

Unfortunately, we can't currently tell if a stream has ever been locked, and this leads to some odd behaviour. See the test "locking, writing, then unlocking the writable should not block the encode() method" in https://github.com/GoogleChromeLabs/text-encode-transform-prollyfill/blob/0bb89a918952b319554ebde1ae2fb42e3c8a4cff/tests/locking.html.

Once solution would be to add a boolean flag to ReadableStream and WritableStream to indicate whether the stream has ever been locked. There's no foreseeable implementation difficulty in doing this.

A couple of issues:

1. Is this ever likely to be used by some other standard, or will we be stuck with a flag that's only used by the Encoding Standard?
2. It won't be possible to accurately polyfill this behaviour unless we expose the flag to Javascript. But if we did that we'd have an ugly, confusing property that 99.9% of people would never need. Plus it would render shipping implementations non-compliant overnight for no good reason.

An alternative is just to accept the behaviour in the test I linked above as a minor inconsequential wart on the Encoding Standard.

[yutakahirano]

For ReadableStream, we have disturbed property. Are you fine with the property? Does it make sense to have the counterpart in WritableStream?

[domenic]

Having a disturbed counterpart for WritableStream seems OK, but per whatwg/encoding#72 (comment) I don't quite understand why this would be necessary if we have layering.

[ricea]

We've abandoned this approach in the Encoding standard, so I'm closing this issue. We can always reopen it if the same thing comes up in future.