Typecasting features

[micahscopes]

We need to implement some basic typecasting features, whether by introducing new syntax, adding some implicit casting or otherwise.

let x: u32 = 10
mymem[x] // err, expected usize
mymem[x as u64]
mymem[x.into()]
mymem[x as usize]

(motivated by conversation around #1083)

[nadtech-hub]

looking to work on issue over weekend. could you assign it to me?

[sbillig]

Hi @nadtech-hub, you're welcome to work on this. Do you have thoughts about how this should be handled in the language?

We don't have any concrete plans defined yet. My tentative inclination is to allow implicit casting from smaller integer types to larger integer types (where signed-ness matches), eg it should be possible to use a u32 where a u64 is expected. (Allowing implicit upcasting to usize is tricky, because the size of usize depends on the target platform).

This could be defined as a trait in the core library, eg

extern {
  // magic functionality that needs to be provided by the compiler can be exposed as an extern fn
  fn cast_u32_to_u64(_ val: u32) -> u64
}

trait ImplicitCast<T> {
  fn cast(self) -> T
}

impl ImplicitCast<u64> for u32 {
  fn cast(self) -> u64 {
    cast_u32_to_u64(self)
  }
}

Then in the compiler, when checking the type of an argument passed into a function call against the type expected by the function definition, we could check for an appropriate ImplicitCast impl.

Other int casts shouldn't be implicit, so we should have something like:

pub trait IntDowncast<T> {
     fn downcast_truncate(self) -> T
     fn downcast_saturate(self) -> T
     fn downcast(self) -> Option<T>
 }

I'm not tied to this design btw; other suggestions are more than welcome.

[nadtech-hub]

Your approach makes sense, I guess casting is needed for all numeric types
Any other types such as bytes?
@micahscopes needs implicit type conversion in index, range expression for built-in and custom types?

[micahscopes]

Hey @nadtech-hub, those are good questions. The index/range expression conversion sounds like a necessity, definitely. We still need to build out basic traits in the core library, things like Index, PartialOrd and Range in Rust aren't yet defined yet. It's likely that we'll want to follow Rust on that, but we are taking these core library things step by step as they come. I guess I'd hope that whatever we do for implicit integer casting in general should ideally work for index/range expressions with little or no additional special handling.

As for other types like bytes, I don't know how that should look. Rust has all these coercion rules, but then also trait level stuff like AsRef, From and Into. Naively it seems like it ought to be easier to leverage conversions defined via traits and I wonder if Fe's type system could make that work better from the get-go? Maybe then we wouldn't need as many special cases to be baked into the compiler?

Recently I found myself frustrated with the experience of trying to implement something in rust to work generically over things that implemented AsRef<[u8]> vs AsRef<str>. In the end I needed to pass the decision of which one to rely on down to the end user because it's not currently possible in Rust to make that decision automatically just yet (see here).

[cburgdorf]

This should be a very high priority as we need it for quite a few things related to codegen.

[cburgdorf]

I gave this some more thought because I think we need to decide about something very soon.

Fe aims to be safe by default while remaining competitive for math-heavy, performance-critical code, both safety and efficiency matter.

Solidity ≥0.8 demonstrated that checked arithmetic as the default is the right choice because silent overflows have caused real exploits. However, Solidity's unchecked blocks are coarse-grained and easy to misuse.

I propose checked casts by default via as keyword, with two explicit, fine-grained escape hatches for when developers need to opt out. This gives application developers safety without thinking about it, while enabling library authors to write efficient low-level code with clear intent at each cast site.

Default: Checked Casts with as

let y = x as u8 // Reverts at runtime if x > 255

• Safe by default
• Prevents silent data loss
• Mirrors Solidity ≥0.8 philosophy

Escape Hatches

Truncating
let y = u8::truncating(x) // truncates to lower 8 bits (AND 0xff)

• Explicit intent: "I want the lower bits"
• Guarantees clean value (upper bits zeroed)
• Costs 3 gas (AND operation)
• Use case: bit manipulation, extracting bytes from words

Unchecked

let y = u8::unchecked(x) // zero-cost, no check, no truncation

• Explicit intent: "I've verified this fits"
• Zero-cost (true no-op)
• Requires compiler intrinsic (that's a bit lame but maybe ok?)
• Use case: math-heavy hot paths where bounds are already proven

Summary

  ┌───────────────────┬───────────────────┬─────────┬───────────────────────────┐                                                                                                                                   
  │      Syntax       │     Behavior      │  Cost   │         Use Case          │                                                                                                                                   
  ├───────────────────┼───────────────────┼─────────┼───────────────────────────┤                                                                                                                                   
  │ x as u8           │ Revert if x > 255 │ ~10 gas │ Safe default              │                                                                                                                                   
  ├───────────────────┼───────────────────┼─────────┼───────────────────────────┤                                                                                                                                   
  │ u8::truncating(x) │ Keep lower 8 bits │ 3 gas   │ Bit manipulation          │                                                                                                                                   
  ├───────────────────┼───────────────────┼─────────┼───────────────────────────┤                                                                                                                                   
  │ u8::unchecked(x)  │ No check, no-op   │ 0 gas   │ Performance-critical code │                                                                                                                                   
  └───────────────────┴───────────────────┴─────────┴───────────────────────────┘ 

What do you think?

[micahscopes]

@cburgdorf myself and @Turupawn have had some good fruits this week from looking at what it would take to implement a nicely optimized poseidon hash implementation in fe. I wonder if there's a concrete example like that that could help ground and motivate this stuff too?

[cburgdorf]

Good idea. A Poseidon implementation would be a solid test case for validating this design. It would help us verify:

1. Whether as (checked) is acceptable for the non-hot paths
2. Whether truncating(x) and unchecked(x) provide enough flexibility for the hot paths
3. If there are any casting patterns we haven't considered

[sbillig]

I think as syntax is good for the upcasting (eg u32 to u64) or other lossless casts (eg Address to u256a, Address to FooContract?), and could be implemented as a trait, eg

trait LosslessCast<T> {
  fn cast(self) -> T
}
impl<T, U> LosslessCast<Point<U>> for Point<T>
where T: LosslessCast<U>
{
  fn cast(self) -> Point<U> {
    Point {
      x: self.x as U,
      y: self.y as U,
    }
  }
}

let a: Point<u8> = ..
let b = a as Point<u64>

I don't really like the idea of high level syntax like x as u8 potentially causing a panic/revert; I think I'd prefer to only allow that syntax for upcasting.

For downcasting, I still like my earlier proposal. I think it's best for this to be explicit, and fine if it's a bit verbose. The panic/revert option is let y: u8 = x.downcast().unwrap().

pub trait IntDowncast<T> {
     fn downcast_truncate(self) -> T // or `truncate()`?
     fn downcast_saturate(self) -> T
     fn downcast(self) -> Option<T>
}

We could add downcast_unchecked(); we'd have to document that it's actually a no-op on evm, and could result in other data being overwritten if it's used in packed storage/mem writing. Maybe a case for unsafe?

contract Foo {
  point: Point<u128, u128> // should be packed into one slot
  ...
  let new_y: u256 = ...
  point.y = new_y.downcast_unchecked() // might overwrite point.x if `new_y` doesn't fit in u128

[sbillig]

Nitpick: truncate to u8 is PUSH1 0xff; AND = 6, safe case is... 28 for the happy path? DUP1; PUSH1 0xff; GT; PUSH <revert code offset>; JUMPI; PUSH1 0xff; AND. We shouldn't put that behind simple syntax like as, IMO. Not sure how we should handle math ops on smaller int sizes; "safe" by default is pretty expensive for math-heavy code of course.

[cburgdorf]

Hey @sbillig somehow I skipped over your comment where you had already proposed something (which is kinda embarrassing as the thread isn't that long haha)

I think I'd prefer to only allow that syntax for upcasting.

My gut feeling says it would be nice to have as for up and down casts and just always be runtime checked, but allow developers to write (more verbose) highly efficient code where it truly matters. However, I don't feel strongly about it and I think making the checked downcast slightly more verbose (let y: u8 = x.downcast().unwrap()) is fine too.

I'll start implementing your proposal. Just to confirm the API:

• as for lossless casts only
• .downcast() -> Option<T>
• .downcast_truncate() -> T
• .downcast_saturate() -> T
• .downcast_unchecked() -> T (potentially using unsafe in the future)