5 ms·

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. A

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.

purplesyringa 2y ago
This is true, strictly speaking, but rarely causes problems. Inherent methods are prioritized over trait methods, so this only causes problems if two traits suddenly define a single method, and the method is invoked in an ambiguous context. This is a rare situation, and std thrives to prevent it. For example, in [1], a certain trait method was called extend_one instead of push for this reason. Crater runs are also used to make sure the breakage is as rare as T-libs-api has expected. The Linux kernel in particular only uses core and not std, which makes this even more unlikely. [1]: https://github.com/rust-lang/rust/issues/72631 https://github.com/rust-lang/rust/issues/72631
- School-Cotton 2y ago
  Okay, but “they try to avoid issues” is not the same as “they guarantee never to intentionally break BC except to fix compiler bugs”.
sophacles 2y ago
That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ff49076bd187d56c6980d2d0881906f8 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- School-Cotton 2y ago
  My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.
  - sophacles 2y ago
    Look at the linked code - it literally shows what happens in that case. What happens is not what you're saying.
    - School-Cotton 2y ago
      This code compiles on 1.81 and fails to compile on 1.82: https://godbolt.org/z/9GbbMKjcf https://godbolt.org/z/9GbbMKjcf
      - estebank 2y ago
        You are always free to use fully-qualified paths to protect yourself from any change in your dependencies (including std) that would break inference (by making more than one method resolve).
gpderetta 2y ago
That's true for literally every non static function in C, given the lack of namespaces. So it can't be a blocker.
- School-Cotton 2y ago
  New versions of gcc don't cause new C standard library functions to exist.

purplesyringa 2y ago

This is true, strictly speaking, but rarely causes problems. Inherent methods are prioritized over trait methods, so this only causes problems if two traits suddenly define a single method, and the method is invoked in an ambiguous context. This is a rare situation, and std thrives to prevent it. For example, in [1], a certain trait method was called extend_one instead of push for this reason. Crater runs are also used to make sure the breakage is as rare as T-libs-api has expected. The Linux kernel in particular only uses core and not std, which makes this even more unlikely. [1]: https://github.com/rust-lang/rust/issues/72631 https://github.com/rust-lang/rust/issues/72631

School-Cotton 2y ago
Okay, but “they try to avoid issues” is not the same as “they guarantee never to intentionally break BC except to fix compiler bugs”.

sophacles 2y ago

That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ff49076bd187d56c6980d2d0881906f8 https://play.rust-lang.org/?version=stable&mode=debug&editio...

School-Cotton 2y ago
My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.
- sophacles 2y ago
  Look at the linked code - it literally shows what happens in that case. What happens is not what you're saying.
  - School-Cotton 2y ago
    This code compiles on 1.81 and fails to compile on 1.82: https://godbolt.org/z/9GbbMKjcf https://godbolt.org/z/9GbbMKjcf
    - estebank 2y ago
      You are always free to use fully-qualified paths to protect yourself from any change in your dependencies (including std) that would break inference (by making more than one method resolve).

gpderetta 2y ago

That's true for literally every non static function in C, given the lack of namespaces. So it can't be a blocker.

School-Cotton 2y ago
New versions of gcc don't cause new C standard library functions to exist.