4 ms·

I'm new to Rust, so there may be precedent that I don't know, and I'm kinda spoiled because I'm a front-end dev mainly, where the rule is "don't break the web",

I'm new to Rust, so there may be precedent that I don't know, and I'm kinda spoiled because I'm a front-end dev mainly, where the rule is "don't break the web", but doesn't changing the syntax of a macro like that break backwards compatibility?

whatshisface 6y ago
`asm!` never made it out of the nightly builds, so nothing that's being changed has been released.
dralley 6y ago
The important thing in this case is that the previous syntax was never actually stabilized, and was only available in nightly releases of the compiler. So technically it does break some code, but only code which was deliberately opting into unstable features with the knowledge that it may break in the future.
jcranmer 6y ago
asm! has been an unstable feature for years, which means a) it's available only in nightly builds, and b) there is no guarantee that it will remain backwards-compatible. Actually, with regards to asm!, it's been known for a long time that it was unlikely to be stabilized as-is (being originally a very thin wrapper around LLVM's inline asm functionality). Probably nearly everyone who's been relying on inline asm to make their code work has already been following the effort to replace asm! with a better version.
- gpm 6y ago
  c) Even on nightly builds you need to put #![feature(asm)] at the root of your crate to use it. (Likewise for all unstable features, just replace asm with feature_name.)
- twic 6y ago
  > Probably nearly everyone who's been relying on inline asm to make their code work has already been following the effort to replace asm! with a better version Except for my colleague who basically says "nah, they'll never be able to move off the LLVM syntax, the code i'm writing now will be supported forever". Fortunately, we only have a small amount of assembly, so if we ever do want to upgrade to a version of the compiler which has dropped support, it won't be a lot of work.
  - dathinab 6y ago
    Support will likely not be dropped anytime soon, maybe never. You just need to rename it to `llvm_asm!`. Through with `asm!` likely going to be stabilized while `llvm_asm` never going to be stabilized it might be worthwhile to switch to the new asm to get of nightly in the future ;=)
trufas 6y ago
Every couple years they'll define an edition of a language (e.g. rust 2015, rust 2018), the idea being that if you choose to stick to one of them, the latest rust will still compile your code as long as you tell it what version you're targetting.
- JoshTriplett 6y ago
  This isn't related to editions; asm was never stable syntax and couldn't be used in the stable compiler; you could only use it on nightly and only if you opted in. This new syntax is something we hope to stabilize eventually.
knome 6y ago
> syntax was highly unlikely to ever graduate from nightly to stable Rust, despite being one of the most requested features. I think it's safe to infer from this line that there was not yet a guarantee of stability in the interface, and that breaking backwards compatibility was therefore fine. >We renamed the existing asm! to llvm_asm! They also kept the existing functionality under a different name to ease transition. Current users will need only update the macro name and then transition to the better syntax at their own pace.
amalcon 6y ago
To clarify, "unstable" in rust-speak means "You can use this, but it might completely change or go away, and therefore break your code." You need to deliberately opt in to unstable features, so you are unlikely to use something like this by accident.
- brandur 6y ago
  Also worth noting that the old syntax was renamed from `asm!` to `llvm_asm!`. It'll still disappear at some point, but existing users of the former on nightly have a very easy way of fixing their build in the meantime.
SpaceNugget 6y ago
"don't break the web" type issues are not really applicable to releases of precompiled languages or applications that ship their own interpreters and don't load third party content. Let's say you are browsing my website. Suddenly, your browser gets an update and prompts you to re-open the window. My site no longer displays correctly due to a backward incompatible change. My site is the web and your browser broke it. If you use a native app or service I write in rust 1.35 or whatever and there is a backwards incompatible change in a new version of rust it has no impact on your use of that app at all.
- dtech 6y ago
  backwards compatibility is still highly valued. Code no longer compiling in newer versions of the languages can create huge churn. It's one of the reasons Java is so widely used, you can still use Java 1.4 libraries in Java 13 and most 1.4 code will keep working and compiling.
coding_lobster 6y ago
>I'm a front-end dev mainly, where the rule is "don't break the web" left-pad flashbacks intensify
SAI_Peregrinus 6y ago
Rust has two ways of ensuring forwards compatibility (or incompatibility): The first is the `stable`/`nightly` system. Anything in `stable` gets compatibility guarantees, anything in `nightly` can change or be removed at any time. Nightly also has feature-gates: using an unstable feature requires an opt-in to enable it. The old `asm!` syntax which got renamed was only ever in `nightly`. The compatibility guarantees for `stable` are based on editions: each year there's an edition, your project's `cargo.toml` specifies which edition your code is for, and compilers will continue to support old edition code. New editions might require changes to existing code, but as long as you don't update the edition in your `cargo.toml` you can freely update your compiler (to a new stable version) without worrying about it breaking. You can use crates (packages) from any edition with any other edition, as long as the compiler is new enough to support the latest edition used.

whatshisface 6y ago

`asm!` never made it out of the nightly builds, so nothing that's being changed has been released.

dralley 6y ago

The important thing in this case is that the previous syntax was never actually stabilized, and was only available in nightly releases of the compiler. So technically it does break some code, but only code which was deliberately opting into unstable features with the knowledge that it may break in the future.

jcranmer 6y ago

asm! has been an unstable feature for years, which means a) it's available only in nightly builds, and b) there is no guarantee that it will remain backwards-compatible. Actually, with regards to asm!, it's been known for a long time that it was unlikely to be stabilized as-is (being originally a very thin wrapper around LLVM's inline asm functionality). Probably nearly everyone who's been relying on inline asm to make their code work has already been following the effort to replace asm! with a better version.

gpm 6y ago
c) Even on nightly builds you need to put #![feature(asm)] at the root of your crate to use it. (Likewise for all unstable features, just replace asm with feature_name.)
twic 6y ago
> Probably nearly everyone who's been relying on inline asm to make their code work has already been following the effort to replace asm! with a better version Except for my colleague who basically says "nah, they'll never be able to move off the LLVM syntax, the code i'm writing now will be supported forever". Fortunately, we only have a small amount of assembly, so if we ever do want to upgrade to a version of the compiler which has dropped support, it won't be a lot of work.
- dathinab 6y ago
  Support will likely not be dropped anytime soon, maybe never. You just need to rename it to `llvm_asm!`. Through with `asm!` likely going to be stabilized while `llvm_asm` never going to be stabilized it might be worthwhile to switch to the new asm to get of nightly in the future ;=)

trufas 6y ago

Every couple years they'll define an edition of a language (e.g. rust 2015, rust 2018), the idea being that if you choose to stick to one of them, the latest rust will still compile your code as long as you tell it what version you're targetting.

JoshTriplett 6y ago
This isn't related to editions; asm was never stable syntax and couldn't be used in the stable compiler; you could only use it on nightly and only if you opted in. This new syntax is something we hope to stabilize eventually.

knome 6y ago

> syntax was highly unlikely to ever graduate from nightly to stable Rust, despite being one of the most requested features. I think it's safe to infer from this line that there was not yet a guarantee of stability in the interface, and that breaking backwards compatibility was therefore fine. >We renamed the existing asm! to llvm_asm! They also kept the existing functionality under a different name to ease transition. Current users will need only update the macro name and then transition to the better syntax at their own pace.

amalcon 6y ago

To clarify, "unstable" in rust-speak means "You can use this, but it might completely change or go away, and therefore break your code." You need to deliberately opt in to unstable features, so you are unlikely to use something like this by accident.

brandur 6y ago
Also worth noting that the old syntax was renamed from `asm!` to `llvm_asm!`. It'll still disappear at some point, but existing users of the former on nightly have a very easy way of fixing their build in the meantime.

SpaceNugget 6y ago

"don't break the web" type issues are not really applicable to releases of precompiled languages or applications that ship their own interpreters and don't load third party content. Let's say you are browsing my website. Suddenly, your browser gets an update and prompts you to re-open the window. My site no longer displays correctly due to a backward incompatible change. My site is the web and your browser broke it. If you use a native app or service I write in rust 1.35 or whatever and there is a backwards incompatible change in a new version of rust it has no impact on your use of that app at all.

dtech 6y ago
backwards compatibility is still highly valued. Code no longer compiling in newer versions of the languages can create huge churn. It's one of the reasons Java is so widely used, you can still use Java 1.4 libraries in Java 13 and most 1.4 code will keep working and compiling.

coding_lobster 6y ago

>I'm a front-end dev mainly, where the rule is "don't break the web" left-pad flashbacks intensify

SAI_Peregrinus 6y ago

Rust has two ways of ensuring forwards compatibility (or incompatibility): The first is the `stable`/`nightly` system. Anything in `stable` gets compatibility guarantees, anything in `nightly` can change or be removed at any time. Nightly also has feature-gates: using an unstable feature requires an opt-in to enable it. The old `asm!` syntax which got renamed was only ever in `nightly`. The compatibility guarantees for `stable` are based on editions: each year there's an edition, your project's `cargo.toml` specifies which edition your code is for, and compilers will continue to support old edition code. New editions might require changes to existing code, but as long as you don't update the edition in your `cargo.toml` you can freely update your compiler (to a new stable version) without worrying about it breaking. You can use crates (packages) from any edition with any other edition, as long as the compiler is new enough to support the latest edition used.