Skip to content

Commit

Permalink
improve Rust-related articles
Browse files Browse the repository at this point in the history
  • Loading branch information
soc committed Jan 22, 2024
1 parent 2039900 commit 7055e17
Show file tree
Hide file tree
Showing 3 changed files with 33 additions and 36 deletions.
45 changes: 23 additions & 22 deletions _languages/lower-bar-of-rust-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,16 +25,17 @@ as a learning opportunity for future language designers:

#### Drop struct initialization syntax

No point having special syntax to initialize structs if everyone immediately defines `::new()` functions to avoid it.
People voted with their feet, and language designers need to respect that.
There is little reason why invoking functions, initializing structs and enums and initializing tupled structs and enums have to follow different rules.

Dropping it also solves the ambiguity in `if X { ...`.
Also, there is no point in having special syntax to initialize structs if everyone immediately defines `::new()` functions to avoid it. People voted with their feet, and language designers need to respect that.

See [this article](rust-struct-initializer-mistake) for more details.

#### Named parameters using `=`

After dropping struct literal initialization there is no point in using `:` for this, but lots of reasons against.
After dropping struct literal initialization there is no point in using `:` for value assignments, but lots of reasons against.

This allows restoring the intuition that `: Type` can be attached to every value to ascribe its type.
This allows restoring the intuition that `=` is followed by a value and `:` is followed by a type, and that every value can receive a type ascription.

#### Vararg parameters

Expand All @@ -44,51 +45,51 @@ Don't hand out rocket artillery to people wanting to cut their toenail.

#### Drop range syntax

It takes up way too much language footprint for very little actual benefit.
It takes up way too much language footprint for very little actual benefit, and is a source of constant language expansion proposals.

Also fix the relationship of ranges with `Iterator`/`IntoIterator` and perhaps [a few other problems](https://ridiculousfish.com/blog/posts/least-favorite-rust-type.html).
Also, fix the relationship of ranges with `Iterator`/`IntoIterator` and perhaps [a few other problems](https://ridiculousfish.com/blog/posts/least-favorite-rust-type.html).

#### Drop array and slice syntax

This frees up the `[]` bracket pair for more useful purposes.

#### Fold `Index` and `IndexMut` into `Fn` trait family

Providing traits to let people decide how round they want their function call parentheses to be is
not a useful feature.
This frees up the `[]` bracket pair for more useful purposes.

#### Make generics use `[]` instead of `<>`/`::<>`

Turns out "trying to preserve the strangeness budget"[^4] can't fix a [broken design](stop-using-angle-brackets-for-generics).

Pretending it's not broken doesn't help either, otherwise we would have seen results by now,
because various languages tried that approach really hard for a few decades already.
because various languages tried that approach really hard for a few decades already.

#### Fold `Index` and `IndexMut` into `Fn` trait family

Providing traits to let people decide how round they want their function call parentheses to be is
not a useful feature.

#### Remove the hierarchy between `Eq`/`Ord` and `PartialEq`/`PartialOrd` traits

This means that floating point values can correctly implement the total order operation as defined in the IEEE754 spec.[^5]

#### Drop `::`

The distinction between path navigation (`::`) and member access (`.`) is not important enough to bother users with it at every single occassion.
The distinction between path navigation (`::`) and member access (`.`) is not important enough to bother users with it at every single occasion.

Instead, let the IDE handle it with some syntax coloring and be done with it.
Instead, let the IDE use some syntax coloring and be done with it.

#### Drop `as`

... or at least make it make sense: it should *either* do type conversions *or* value conversions, but not both.

#### Remove significance of semicola
#### Drop `if-let`

Varying the meaning of a piece of code based on the presence of a `;` at a specific line is bad user interface design.
You know a feature is not well thought out if it has spawned 4 extensions proposals already.

Remove it and implement automatic semicolon inference, such that IDEs can show them, but no user has to ever type them.
Instead, use the vastly superior [`is` design](unified-condition-expressions-comparison).

#### Drop `if-let`
#### Remove significance of semicola

You know a feature is not well thought out if it has spawned 4 extensions proposals already.
Varying the meaning of a piece of code based on the presence of a `;` at a specific line is bad user interface design.

Instead, use the vastly better [`is` design](unified-condition-expressions-comparison).
Remove it and implement automatic semicolon inference, such that IDEs can show them, but no user has to ever type them.

[^1]: ["Does Rust have any design mistakes?"](https://old.reddit.com/r/rust/comments/wvynot/does_rust_have_any_design_mistakes/)
[^2]: [label:rust-2-breakage-wishlist](https://github.com/rust-lang/rust/issues?q=label%3Arust-2-breakage-wishlist)
Expand Down
15 changes: 8 additions & 7 deletions _languages/popular-but-wrong.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,10 +13,11 @@ redirect_from:
4. `[]` for arrays ([see](stop-using-angle-brackets-for-generics))
5. `Type ident` instead of `ident: Type` ([see](type-annotations))
6. having if-then-else *and* switch/case *and* a ternary operator ([see](unified-condition-expressions))
7. separate namespaces for methods and fields
8. having both modifiers and annotations ([see](annotations-obsolete-modifiers))
9. method overloading
10. namespace declarations doubling as imports
11. special syntax for casting
12. using cast syntax for things that are not casts
13. requiring `()` for methods without parameters
7. having both modifiers and annotations ([see](annotations-obsolete-modifiers))
8. `async`/`await`
9. separate namespaces for methods and fields
10. method overloading
11. namespace declarations doubling as imports
12. special syntax for casting
13. using cast syntax for things that are not casts
14. requiring `()` for methods without parameters
9 changes: 2 additions & 7 deletions index.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,14 +72,9 @@ navigation: true
<li><a href="languages/popular-but-wrong">Popular, but Wrong</a></li>
<li><a href="languages/implicit-numeric-conversions" class="compact">Implicit Numeric Conversions</a></li>
<li><a href="languages/package-objects-in-scala">Package Objects in Scala</a></li>
<li><a href="languages/lower-bar-of-rust-2">The lower bar of "Rust 2.0"</a></li>
<li><a href="languages/rust-struct-initializer-mistake">Struct initialization in Rust</a></li>
<li><a href="languages/design-mistakes-in-rust">Design Mistakes in Rust</a></li>
</ul>
</section>
<section id="rust-compatibility"><i>Rust compatibility:</i>
<ul>
<li><a href="languages/winding-down-rust-feature-development">Time to wind down Rust feature development</a></li>
<li><a href="languages/lower-bar-of-rust-2">The lower bar of a hypothetical Rust 2.0</a></li>
<li><a href="languages/design-mistakes-in-rust">(More) Rust Design Mistakes</a></li>
</ul>
</section>
</td>
Expand Down

0 comments on commit 7055e17

Please sign in to comment.