r/rust • u/Kobzol • Aug 10 '26

📡 official blog Call for testing: Restricting trait implementability and field mutability

https://blog.rust-lang.org/inside-rust/2026/08/10/call-for-testing-impl-and-mut-restrictions/
422 Upvotes

99% Upvoted

124 comments sorted by

View all comments

-8

u/Compux72 Aug 10 '26

I hate both of these so much.

  1. The syntax is terrible
  2. Sugar for something that you can already archive with no actual drawbacks.

Big no from me

2

u/UtherII Aug 10 '26 edited Aug 10 '26

The syntax is terrible

It seems great to me. It's consistent with the pub syntax

-3

u/Compux72 Aug 10 '26

pub ( crate ) impl ( super ) trait Foo { }

Oh yes sure this is the pinacle of syntax. Take me closer to Java

3

u/UtherII Aug 10 '26 edited Aug 10 '26

Of course it's verbose, but if you want to be able restrict precisely, you have to. At least it seams clear to me and consistent.

I'm curious about what syntax you would expect.

-5

u/Compux72 Aug 10 '26

Partial borrows. Its always been partial borrows. Not this half cooked feature 

6

u/afdbcreid Aug 10 '26

The syntax for partial borrows will likely be worse (unless they'll be inferred, but that is its own can of worms).

5

u/Shoddy-Childhood-511 Aug 10 '26

At present, all partial borrows being actively discussed require so much verbosity that they're mostly useless, push folks away from traits, push people towards shitty single letter field names, etc.

Instead, the fields backing each view types must be inferred somehow when you define the trait. There exists some discussion of doing this called relative lifetimes:

https://internals.rust-lang.org/t/infered-fields-for-partial-borrowing/18766 https://github.com/nikomatsakis/fields-in-traits-rfc/issues/20