0

Is there a stable way to convert rust enum types to strings (and from strings to enum types) without the use of std or fmt?

The reason I am asking is because std appears to account for and 'bloat' the final binary size by around 33% (using cargo bloat) - leaving me with an executable almost 1MB in size for some very simple code.

Note I've already done all cargo.toml profile.release optimizations as outlined here: https://rustwasm.github.io/docs/book/reference/code-size.html

vitaut
  • 49,672
  • 25
  • 199
  • 336
user1709076
  • 2,538
  • 9
  • 38
  • 59

1 Answers1

0

Maybe this is silly but I've just took out std/fmt and used impl on the enum and did the same thing. binary size hasn't decreased yet but I haven't removed all std / fmt from all dependencies yet. Makes me feel silly for using std / fmt in the first place since it's the same amount of work either way. I think the only difference is if my MYType enum were used inside the &format! macro I'd just need to call .to_string()

pub enum MyType {A, B, /*etc...*/ }

impl MyEnumType 
{
   pub fn print(&self)
   {
      match &self 
      {
         MyEnumType::A => web_sys::console::log_1("a"),
         MyEnumType::B => web_sys::console::log_1("b"),
         /*etc... */ 
      }
   }

   pub fn from_str(input: &String) -> Result<MyEnumType, String> 
   {
      match input.as_str() 
      {
        "A" => Ok(MyEnumType::A),
        "a" => Ok(MyEnumType::A),
        "B" => Ok(MyEnumType::B),
        "b" => Ok(MyEnumType::B),
        /* etc*/ 
         _  => Err("bad string".to_string()),
      }
    }

    pub fn to_string(&self) -> String 
    {
      match &self 
      {         
        MyEnumType::A => "a".to_string(),   
        MyEnumType::B => "b".to_string(),   
        /* etc ... */
      }
    }
  }
user1709076
  • 2,538
  • 9
  • 38
  • 59
  • 1
    You can reduce allocations by using `str` instead of `String` whenever possible: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4ed3fd4cd258e6eef8b29f2970f5d818) – kmdreko May 10 '23 at 18:39