Rust's Ugly Syntax

• rust

  2,683 93,041 10.0 Rust

  Empowering everyone to build reliable and efficient software.

  

To my knowledge, this closure syntax was a direct Ruby influence mainly because this syntax was also supposed to work like Ruby blocks: `array.each |e| { ... }`. Originally owned and shared closures had a different syntax (`fn~() { ... }` or `fn@() { ... }`)---this was back when Rust had a built-in shared reference, roughly equivalent to `std::sync::Arc` in the modern Rust---and it was pointed out that they should be harmonized at some point [1]. It was that time when people realized that then-loop-only syntax can be generalized into any closures, and this semi-decision got stuck even after the "internal" iterator that accepts a closure has long gone.

[1] https://github.com/rust-lang/rust/issues/1864

• ante

  23 1,833 8.0 Rust

  A safe, easy systems language

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• hylo

  54 1,106 9.9 Swift

  The Hylo programming language

  

• rfcs

  666 5,711 9.8 Markdown

  RFCs for changes to Rust

  

That was proposed and rejected for Rust recently:

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

I was against because I felt that there should always be parens/brackets/braces (macros can use any of them) for better scannability when you're invoking an unclear amount of extra stuff behind the scenes.

(An appeal to the "make costs explicit" side of Rust's philosophy that also requires explicit .clone() rather than copy constructors.)

Suggest a related project