Why not valid Rust as schema language?

[playdohface]

First of all: this looks very exciting!
When playing around, I couldn't help but notice that the schema definition is very close in syntax to the actual entity-struct generated from it:

model User {
    #[key]
    #[auto]
    id: Id,

    name: String,

    #[unique]
    email: String,
    
    todos: [Todo],

    moto: Option<String>,
}

becomes:

pub struct User {
    pub id: Id<User>,
    pub name: String,
    pub email: String,
    todos: HasMany<super::todo::Todo>,
    pub moto: Option<String>,
}

But there is a definitive cost to having our Entity-struct being generated code as opposed to hand-written, such as being able to #[derive(Serialize) directly on one and not the other.
I understand, and am very much in favor of not wrapping everything up in proc-macros and calling it magic, and one of my main requirements for a good ORM is the ability to correctly intuit what it will generate from given DSL code, and override when I have to, which macros make very difficult.
But I'm left wondering why we need to have a schema definition language that is not also valid Rust?

#[toasty(schema)]
pub struct User {
    #[toasty(key, auto)]
    pub id: Id<User>,
    pub name: String,
    #[toasty(unique)]
    pub email: String,
    todos: HasMany<Todo>,
    pub moto: Option<String>,
}

#[toasty(schema)]
pub struct Todo {
    #[toasty(key, auto)]
    pub id: Id<Todo>,
    #[toasty(foreign_key)]
    pub user_id: Id<User>,
    #[toasty(relation(key = user_id, references = id))]
    user: BelongsTo<User>,
    pub title: String,
}

In my opinion, this is as (if not more) ergonomical to read and write as the separate schema and contains all the information (I think the foreign_key annotation is even redundant on Todo here).
And then we can use the CLI to unlock all the impls and migrations for us, in ordinary and readable Rust that gets checked into version control, and perhaps can even be open to modification.
I think I've just described my dream ORM - the toasty vision seems very close already. 🏆

I am genuinely curious to learn why separating the schema definition from the Rust code would be preferable to this approach.

[JJPuck]

We've developed a very similar ORM in house but have leaned more on this approach using derive macros to generate the relevant code. Schemas are just annotated rust types and a derive macro. I'm biased, because I wrote it but I also prefer being able to define and work with my types directly rather than have to interface with a DSL.

The definition looks like this

#[derive(ExternalDocument, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct User {
    #[key]
    pub id: DocumentId,
    #[unique]
    username: String,
    #[serde(skip)]
    position: Position,
    user_type: ForeignKey<DocumentId, UserType>,
    organisation: String,
    last_modified: EpochTime,
}