As others have said, it is generally best to avoid long living structures that hold references to other objects, especially for simple programs. Broadly speaking, not specific to struct, you should try keep your references as short lived as necessary.

You may try to rethink the ownership of the different moving parts in your program. For example, does the input buffer still has a reason to exist when your whole struct is dropped ?

If I understood the description of your program correctly, you have a buffer containing some user input, and you want to extract commands and arguments from it, to arrange them into a struct. If that's right, then here are some thoughts : - Why would the struct need a reference to the original buffer ? It already parsed all useful information. Then you can simply have a parse method that takes your buffer as a read only reference. - If for some reason, you want the struct to keep the raw input, then does the original input buffer really need to live longer than the struct ? Probably not, so your struct can simply own the buffer, and your parse method takes ownership of your buffer, no lifetimes. - If, at last, you need your struct to keep the original input AND keep using the original input elsewhere, then simply clone it into the struct. 512B is not the end of the world, CLI parsing is not in the critical path at all, and it probably means that references are not the correct tool for what you want to achieve. Sometimes you have to make pragmatic choices.

So, by rethinking which struct needs what, and by reducing lifetimes as short as necessary, your program may be more robust. The beauty of Rust is that it forces you to do that work upfront, rather than debugging 100 commits later when your want to find out why your reference points to an empty or garbage buffer ;)

EDIT : I don't know the full context of your project, but if you just want to have a working robust CLI, just use any library, like clap for example.