Expose EfficientLength interface

[DartBot]

This issue was originally filed by davidm...@google.com

---

EfficientLength is currently part of dart._internal, meaning third party collection libraries can't advertise their efficientness and performance suffers as a result.

Please share ;)

[lrhn]

Anything that implements List, Set, Map or Queue will also inherit EfficientLength. The classes require an efficient length operation and already implement EfficientLength.

I can see why it would be useful to mark some iterables deriving from new collections as having efficient length.
I'm sympathetic to making the marker interface public, even if it's not the best solution - and it begs for an "EfficientContains" interface too.

If exposed, the name should be changed. As an internal name, it's just a marker, but it actually extend Iterable, so a public implementation would be:

abstract class EfficientLengthIterable<T> extends Iterable<T> {
  const EfficientLengthIterable();
}

We should not change any return type to EfficientLengthIterable - that type is an implementation detail, not an API type. Methods returning iterables should still return Iterable and document in text that the length of that is efficient. That allows inefficient implementations as well, breaking only performance, not static types.

---

Added Area-Library, Library-Collection, Triaged labels.

[DartBot]

This comment was originally written by davidm...@google.com

---

Sounds good to me. Thanks.

[DartBot]

This comment was originally written by @Fox32

---

This file has typo and is talking about a EfficientLengthIterableIterable: https://codereview.chromium.org/1104063002/patch/60001/70012

[lrhn]

Doh, thanks.

[lrhn]

The introduction of EfficientLengthIterable has been reverted.
It's still not the right way to solve the problem - it's a property of the object, but it's hidden away in the type, creating two types of Iterables. This breaks if you use wrapper classes, and it allows you to use EfficientLengthIterable as a type assertion (no matter how much we discourage it).

The real solution requires adding something to Iterable, and though it is harder to push through without breaking existing code, but in the long run, it's better.

[DartBot]

This comment was originally written by davidm...@google.com

---

So the suggestion would be to have Iterable.isEfficient? (Iterable.asList would also work).

That would solve my use case, but -- is there any way that could actually happen? A breaking change to Iterable sounds not just hard, but impossible.

Equivalent for my purposes would be to remove EfficientLengthIterable from the internal code and assume efficiency. This would cause bad effects for people passing around inefficient iterables. Personally I prefer this approach: defensive use of "toList" is a good idea anyway in my experience. (Debugging with lazy iterables gets very hard very fast).

Thanks!

[davidmorgan]

Any ideas where this might be headed, please?

[lrhn]

We don't plan to expose the interface (so closing this issue).

We haven't decided either way on whether we will eventually make it possible to check if an iterable has an "efficient" length implementation (something that doesn't require iterating all the elements), but it definitely won't happen until Dart 2.0 since it changes the Iterable interface.