Crystal: Should Dir API expose entry info?

[asterite]

With #8081 merged we have these options:

1. Do nothing (backwards compatible)
2. Expose a Dir::Entry API in addition to the existing API (String) (backwards compatible)
3. Change the Dir API to user Dir::Entry instead of String (backwards incompatible)

[RX14]

I'd err towards Dir itself being Iterable(Dir::Entry), but of course have Dir.each remain the same.

[didactic-drunk]

With 3. I could avoid extra stat calls and speed up my code. Dir::Entry could also provide a memoized .info method and .path to return a Path.

[straight-shoota]

I suppose we'd need to break the API anyway in order to introduce Path return types. So making a breaking change for Dir::Entry isn't a big deal, but we should coordinate these changes to happen together.

@RX14's suggestion sounds good, it provides a simple API with Dir.each and a more detailed API when instantiating Dir. But I'm not sure whether it's a good idea that Dir.each and Dir#each have different behaviour.

[RX14]

@straight-shoota the difference isn't such a big deal because you'd make the mistake once then the compiler would complain at you :) In effect, the methods have the same semantics, just different types. And i'm fine with that.

[miketheman]

CodeTriage

It appears that there's some consensus around making the breaking change, especially if the change is surfaced immediately on the next recompilation.

A question I'd ask is whether there's a facility for providing the compiler output with distinct messages on how to resolve a change like this?

[didactic-drunk]

It's a common pattern to skip or have different actions based on file type. Passing Path by itself discards the file type forcing many applications to call stat. For remote file systems this is especially bad.

Why optimize in #8081 without optimizing the Dir API for the exact same issue?