Inline values should not be produced for `Iterable`s, `Stream`s, `Future`s

[FMorschel]

If you have this code:

void main() {
  f({}, []);
}

void f(Set<int> s, List<int> l) {
  print('test');
}

And place a breakpoint on print, these are the values you'll see:

It feels a bit weird that s only shows Set and l shows List (0 items). I feel like all iterables should display the number of items or something like that.

CC @DanTup

[lrhn]

An iterable definitely shouldn't show its length since computing that can be a linear operation (and have side effects).

List, Set and Map can probably be trusted to have side-effect-free and efficient length.

[FMorschel]

Well, I guess we can't ever have an Iterable instance since it is abstract, but you're right. Thanks for the correction!

[lrhn]

True. We also can't have a List instance for the same reasons, so the debugger has to decide which objects it trusts enough to call getters on. Maybe only built-in collection classes, maybe only ones where the length getter is a field default getter. Just don't trigger arbitrary user code.

[DanTup]

so the debugger has to decide which objects it trusts enough to call getters on. Maybe only built-in collection classes, maybe only ones where the length getter is a field default getter. Just don't trigger arbitrary user code.

Executing getters for Inline Values is currently behind a flag dart.experimentalInlineValuesProperties, but the plan is probably to change this to the existing dart.showGettersInDebugViews or dart.evaluateGettersInDebugViews once we're happy with it. We do default to evaluating getters in places like Hovers and the Variables/Watch window, because users seemed to expect/desire this (and generally have more getters without side-effects).

That said, Inline Values is probably likely to trigger these more often than the other debug views (since they often rely on expanding some object), so I could see an argument for keeping them behind a separate flag (and even not defaulting them to true) - this is the kind of feedback I'm after while it's behind a flag.

so the debugger has to decide which objects it trusts enough to call getters on

I would love if we could formalize this in some way. I think taking away evaluation of getters by default would really harm the user experience, but the possibility of side-effects has always been a concern. I don't know if the "stable getters" feature would help with this?

[lrhn]

Stable getters would likely be side effect free too. (I guess a stable getter which has side effects only on the first invocation is technically stable/idempotent, but I don't want to have to specify that.)
Many getters won't be marked as stable even if they currently believe as stable. It's not just a marker, it's an API promise.

I'd probably have a list of known unstable getters. Anything returning Future, Stream or Iterable (which includes every member of Stream). Most getters of Iterable, unless it's also a known non-lazy subtype like List or Set
(or length of something implementing EfficientLengthIterable).
Then trust the rest to not have side effects.

[eernstg]

As proposed in dart-lang/language#1518, stable getters do not restrict side effects. They focus entirely on providing the guarantee that if you evaluate a stable getter twice on the same receiver and both invocations return an object then those two objects are identical. That is, stable getters enforce immutability of the return value.

I made the choice to allow side effects because some immutable properties give rise to a substantial amount of work when they are initialized, and it should be allowed to implement a stable getter as a late final variable with an initializing expression. Similarly, there are lots of other situations where some amount of side-effecting work needs to be done, in spite of the fact that the property is immutable (say, logging, optimizations like tree balancing that clients shouldn't be able to observe, etc).

So stable getters won't make anything pure, not even if it is guaranteed that a particular invocation of a stable getter is not the first one.

It would certainly be possible to introduce explicitly declared side-effect-free operations. This would enable things like shared memory concurrency, and it would probably combine rather well with stable getters (they'd basically have to be implemented as non-late final variables or as getters returning a constant expression).

[DanTup]

I was just looking at this and noticed that the original request was slightly different to what we ended up discussing. As such, I've opened #60488 about the issue that "Lists and Sets show differently" in the debugger. The reason for this is that the debug adapter special-cases Lists to show their counts, but does not do the same for Set. As noted above, we can't do this for all Iterables, but perhaps we can do the same for some basic built-in types like Set (IIRC we already special case Maps).

I'll update this issue to reflect the issue of Inline Values (when the property experiment is enabled) can easily trigger things like length, first, last on streams and iterables, but they should be excluded even if the experiment is enabled.