Drop Concurrent::Future and top-level methods delay, future, lazy

[bcardiff]

The motivation behind this was that the original merge was premature.
And there might be more interest to develop a more robust approach (ref: #6468).

Since there is no migration path from here, the methods can be removed directly.

If it is a stopper for someone, the future.cr file is self contained and can be included in the app.

Since the consensus was to remove these top-level methods I am assuming that the Concurrent module is also expected to be removed.

[jhass]

I don't quite get this to be honest.

1. I don't follow how structured concurrency replaces this, the approaches seem complementary.
2. This has been basically maintenance free since its inception and still works. Why drop this now?
3. If you insist on dropping this, let's be a bit nicer here and drop this to a semi maintained shard that people can just include instead.

[bcardiff]

@veelenga @benoist what do you think if I submit a crystal-community/future.cr shard with these contents? (It can't be named concurrent since that will hide the concurrent.cr file included in the prelude (although that could be renamed it we want to free that name) ).

@jhass the issues regarding structured concurrency are the lack of scope for the spawned created along the way and I believe exception handling opinions. I have used these constructs and I accept them as they are; moving them to crystal-community can be a nice sweet spot.

[veelenga]

@bcardiff for sure. The name is looking good. Let me know if you need any extra permissions or if I can help with something.

[bcardiff]

https://github.com/crystal-community/future.cr has been published, I changed the Concurrent::Future to Future::Compute to match the naming.

The top-level methods are the same.

The migration path is to

• include the shard github: crystal-community/future.cr
• add a require "future"
• replace Concurrent::CanceledError with Future::CanceledError

[jkthorne]

Seems like there should have been a depreciation step before removing the code. If some upgrades Crystal now there code will break.

Maybe we can add an exception pointing to the new repo.

[bcardiff]

IMO the deprecation is not needed here because the changes to make things work in nightlies can be done in current release.