Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Anonymized return types will sadly not be a blocker for 1.0, though they will be an enormously high priority post-1.0.

In particular, the biggest pain point for the lack of anonymized return types won't be the use case mentioned in that SO thread (which is heinously ugly and leaks implementation details, but at least it's possible), but will rather be the fact that without anonymized return types it will be impossible for a function to construct a closure and then return that closure without stuffing it into a box (though note that it will still be possible for functions to return unboxed closures if it accepted that closure as a parameter to the function).



Great to hear that folk are aware of this and that it's not considered a breaking change for a future release. Where is the best place to get updates on these kinds of features? I was following the github ticket until it closed and it wasn't clear where to go afterwards.


Language changes are proposed through our RFC process, which is at this repository: https://github.com/rust-lang/rfcs

Open issues start a discussion, and then morph to a more formal proposal.


Thanks, Steve. I was following the previous RFC but it got closed. Do you know if there is a new one for abstract / anonymous return types?

This was the previous one for abstract return types:

https://github.com/rust-lang/rfcs/pull/105


It appears that (at least with my searching) we don't have an issue on the RFC repo, so I opened one. https://github.com/rust-lang/rfcs/issues/518


Awesome. Thank you.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: