3 ms·
That sounds potentially confusing. The same syntax yields closures that sometimes are Send, Sync, Copy, Clone, etc but usually aren't? I'd rather stick with nes
by eridius 12y ago
That sounds potentially confusing. The same syntax yields closures that sometimes are Send, Sync, Copy, Clone, etc but usually aren't? I'd rather stick with nested fn's. If you really want to be able to have inline functions that are lambdas but not closures, then maybe you should submit an RFC to add literal syntax of the form `fn(args) -> T { code }`
- blaenk 12y agoLike huon said, this is already the case, so I don't see how it could be confusing. The compiler would infer all of that and complain if the constraints are not satisfied. A literal fn syntax would be pretty cool, but I have doubts it'd ever be accepted, which is why I figured closure syntax could be adapted to allow this use case.