A few notes to the above comments:
- yeah,
async letis NOT fire-and-forget. It's more like a "fire, but don't forget"
- I agree that forcing the
async let x = try ...is weird because indeed a catch surrounding this would never trigger so it muddies the meaning of try.
The idea that people propose with async throws let is quite interesting... It is true that we're expressing an effect on the property after all, isn't it? In the same way as a computed property may be throws and async due to SE-0301: Effectful properties
I really wonder if assuming I'm not interested in errors is a viable approach. It feels quite different from the usual "in your face" with having to cover code with try and throws in Swift.
@kavon Your proposal to always force an async let to be awaited on at least some path is interesting. but a bit weird to me. It would indeed force the try to appear "somewhere" I suppose...
In either case, marking the "async throws let" or forcing the appearance of a try somewhere, at least there is some way to notice the potential throwing. I personally quite like the throws let-effect idea, it seems consistent with the rest of the language -- a declaration (here, a variable declaration) specifies effects -- so a function does with throwing and async, and an async let might as well... 