6 ms·
Rust does exactly this. No, Rust solved this problem by using non-nullable references. Closure allocation was a separate consideration. The question of whethe
by Locke1689 13y ago
Rust does exactly this.
No, Rust solved this problem by using non-nullable references. Closure allocation was a separate consideration.
The question of whether you can invent some arbitrary language that will enable your scenario isn't an interesting one. The problem is languages like Java and C#, which are heavily used and DO have nullable references. This "fix" is not one.
- masklinn 13y ago> No, Rust solved this problem by using non-nullable references. 1. its option types provide a number of combinators which use closures, it wouldn't surprise me at all to see this kind of stuff in rust (might even be more efficient, no need to allocate and return an option) 2. and blocks are heavily pushed for use in Rust, all iteration is closure-based for instance > The problem is languages like Java and C# I've no idea where you got that from, TFA merely used java to illustrate the "language without syntactically lightweight functions". COBOL being a turd didn't stop people from investigating objects.
- Locke1689 13y agoI've no idea where you got that from, TFA merely used java to illustrate the "language without syntactically lightweight functions". Really? We're investigating nullable reference semantics and C# and Java aren't the target? Hell the initial example -- the one that spurred the discussion -- is in Java. Anyway, "syntactically lightweight" is a red herring -- syntax is surprisingly easy to add.