6 ms·

You are right, but it doesn't mean we can't complain about it :) As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even fe

• JoshTriplett 1y ago
  > As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition. Rust language hat on: I hope so too. We very much want to, once we've replaced its various use cases.
  • bigstrat2003 1y ago
    As a Rust user, I hope that "as" never goes away. It's way too useful to get rid of, e.g. deliberately truncating numbers to a smaller number of bits. Can you do that in other ways? Absolutely. But they are all less ergonomic than "as". At most I would be ok with restricting "as" to an unsafe block, though that isn't a perfect solution because unsafe isn't really meant to apply to such cases.
    • JoshTriplett 1y ago
      I'm hoping that we provide ergonomic alternatives for all the individual use cases. The brevity of `as` is a major reason we haven't removed it yet. We have `.into()` for lossless conversions like u32 to u64. We need to fix the fact that `usize` doesn't participate in lossless conversions (e.g. even on 64-bit you can't convert `usize` to `u64` via `.into()`). We need to fix the fact that you can't write `.into::<u64>()` to disambiguate types. And I'm hoping we add `.trunc()` for lossy conversion. And eventually, after we provide alternatives for all of those and some others, we've talked about changing `as` to be shorthand for `.into()`.
      • Rusky 1y ago
        A method call like `.trunc()` is still going to be abysmally less ergonomic than `as`. It relies on inference or turbofish to pick a type, and it has all the syntactic noise of a function call on top of that. Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless).
        • int_19h 1y ago
          The compiler doesn't have to implement a call as a call; having "magic functions" calls to which are special-cased by the code generator is an old and time-honored tradition.
          • Rusky 1y ago
            Yes, that's how it should work. It is not how it works in today's rustc.
        • JoshTriplett 1y ago
          > A method call like `.trunc()` is still going to be abysmally less ergonomic than `as`. It relies on inference or turbofish to pick a type, and it has all the syntactic noise of a function call on top of that. If `as` gets repurposed for safe conversions (e.g. u32 to u64), there's some merit to the more hazardous conversions being slightly noisier. I'm all for them being no noisier than necessary, but even in my most conversion-heavy code (which has to convert regularly between usize and u64), I'd be fine writing `.into()` or `.trunc()` everywhere, as long as I don't have to write `.try_into()?` or similar. > Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless). I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions.
          • Rusky 1y ago
            > I'd be fine writing `.into()` or `.trunc()` Yes, this is specifically what I'm disagreeing with. > I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions. That's the cost to compile time I mentioned.
  • 1718627440 1y ago
    How are people supposed to use a language, that changes syntax?
    • sunshowers 1y ago
      Rust's edition system allows the language frontend to be changed every few years.
      • JoshTriplett 1y ago
        In particular, note that new Rust compiles code with both old and new editions. Upgrading Rust does not require you to move to the new edition. And one project can pull in crates from multiple editions. (Imagine if Python 3 let you import Python 2 modules seamlessly.)
        • 1718627440 1y ago
          That's nice, but I think at some point they will cut the old implementation, as otherwise they would end with hundreds of versions. And it doesn't exactly help to compile newer software on an older OS.
          • sunshowers 1y ago
            No, there's a commitment to not cut old editions. A new edition/frontend comes out every 3 years, so Rust (and maybe humanity) is probably going to be completely dead long before it has hundreds of versions.
          • steveklabnik 1y ago
            To elaborate on what sunshowers said, because editions only impact the early parts of the compiler, most of the code isn’t edition specific, which makes maintenance easy.
• jcranmer 1y ago
  As much as I hate 'as' and try to avoid it, it also covers several things that are impossible otherwise (integer <-> float casts are impossible without it, e.g.). I've found that sometimes just being able to express a coerce-to-type-damn-the-consequences is useful. Another painful bugbear is when I'm converting to/from usize and I know that it is really either going to be a u64 or maybe u32 in a few cases, and I don't care about breaking usize=u128 or usize=u16 code. Give me a way to say that u32 is Into<usize> for my code!
• Starlevel004 1y ago
  As someone working with bitfields and enums-to-ints a lot, you can take ``as`` out of my cold dead hands.