You're trying to make a self referential struct which is not possible in pure safe rust. There are however crates like ouroboros that wraps the necessary unsafe code for you.
"You could change your struct a bit, and keep the input stored outside"
That just moves the problem up a level.
I've written a TCL interpreter in Rust, called Molt; I'm trying to improve its memory usage. Molt parses a script, yielding a parse tree defined using an enum; and many of the elements in the tree need to reference text from the script. Plus, I need to keep the entire script. At present, the parse tree keeps the tokens as Strings, which (by the nature of TCL but for reasons I won't go into) causes a lot more duplication than you might think. I want to set things up so I have one copy of the script in memory, and the parse tree is built using slices. So no matter how you look at it, I'm going to have a struct that (utlimately) owns both the String and the slices.
This is sounding like what I'd have to do; it's a reasonable extension of what's already in the interpreter. I have a Value struct; it currently stores Strings as Rc<String> so that I can copy the value without duplicating its content. I could also have a flavor that includes a range. Copy the string, set the range. (Tokens in the parse tree are often stored as Values.
Also note that a range is two usizes, or 16 bytes. A reference will be another 8. How big are these tokens? Would something like SmallString be a viable alternative?
The problem is that this is a pretty complex topic that doesn't play well with the borrow checker. The fact that an instance of a struct may be moved at any time means that you can't store a reference to a field because that could be invalidated at any time. You need an ad hoc language feature for this, but this requires considering may things:
Does it need to work only when the borrowed type Derefs to a stable location or can it be just any type?
If only those that Derefs to a stable location do you require an unsafe trait like StableDeref or can you recognize them automatically?
If any type, how do you ensure the struct can't be moved when it borrows non-stable Deref fields? How does it integrate with the existing Pin?
How do you recognize which fields can be borrowed immutably/mutably or can't be borrowed at all (because already borrowed)?
Can you prove it is 100% safe? For example the existing self-referential structs don't play well with stacked borrows and as such they're technically unsound.
Overall it is a feature that may come in handy but nobody has yet proposed a safe abstraction for it that was accepted.
I would argue that it restores the problem to the level where it actually appears: at the point where you create something and have to decide whether to pass ownership into it or have it borrow. This is the only point where you can meaningfully attach a lifetime to something; once you've made the decision to own, you can't change your mind and borrow it deeper in the stack, because lifetime analysis is static, not dynamic.
Arc is a way of making lifetime analysis partially dynamic, at the cost of moving it to runtime -- you have to do some manual cloning. Cow is a different take on that; I'm not sure if it would work in your situation. Changing the struct to always borrow, on the other hand, is a different kind of concession: keep the static lifetime analysis, and accept that you need to change the structure of your code to prove to the compiler it's correct.
(I will break from the party line long enough to point out that it is possible to create and use self-referential structs in safe Rust, but you have to accept constraints, like that they can't be borrowed mutably or moved, and you can't create one and initialize it in a single line.)
None of these things is wrong or right in the general case. You have to decide what the correct tradeoff is for your application. Bear in mind in another language you'd just be building on top of that language's string type and garbage collector (in e.g. Java) or writing unsafe code without any compiler guidance (e.g. C++).