Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Use names of children as a source for current object naming

Open
#856 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust

Research direction

Begin with the oneOf enum-generation path that currently emits Variant0 and Variant1; compare it with the oneOf-only case described in the issue. Use the provided OpenAPI examples, especially StateChangeCauseView, to check that child titles produce Result and Error while unnamed children retain a fallback name. Done means generated Rust variants are more human-readable without breaking existing naming.

Written by the indexing model from the issue text.

Description

typify2

Hi! So, I have this spec:

Spec with oneOf and additional properties
{
    "openapi": "3.0.0",
    "info": {
        "title": "My API",
        "version": "1.0.0"
    },
    "paths": {
        "/my_request": {
            "post": {
                "operationId": "my_request",
                "requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/JsonRpcResponse_for_Result_and_Error"
                            }
                        }
                    },
                    "required": true
                },
                "responses": {
                    "200": {
                        "description": "",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "string"
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "components": {
        "schemas": {
            "JsonRpcResponse_for_Result_and_Error": {
                "oneOf": [
                    {
                        "properties": {
                            "result": {
                                "type": "string"
                            }
                        },
                        "required": [
                            "result"
                        ],
                        "type": "object",
                        "title": "Result"
                    },
                    {
                        "properties": {
                            "error": {
                                "type": "string"
                            }
                        },
                        "required": [
                            "error"
                        ],
                        "type": "object",
                        "title": "Error"
                    }
                ],
                "properties": {
                    "id": {
                        "type": "string"
                    }
                },
                "required": [
                    "id"
                ],
                "title": "JsonRpcResponse_for_Result_and_Error",
                "type": "object"
            }
        }
    }
}

And it produces the following code:

#[derive(:: serde :: Deserialize, :: serde :: Serialize, Clone, Debug)]
    #[serde(untagged)]
    pub enum JsonRpcResponseForResultAndError {
        Variant0 {
            id: ::std::string::String,
            result: ::std::string::String,
        },
        Variant1 {
            error: ::std::string::String,
            id: ::std::string::String,
        },
    }
      

It's not a big deal, nor it is a bug. But a suggestion for improvement. The struct generates Variant0 and Variant1 enum options. In this case, what can be generated instead is Result and Error enum options:

#[derive(:: serde :: Deserialize, :: serde :: Serialize, Clone, Debug)]
    #[serde(untagged)]
    pub enum JsonRpcResponseForResultAndError {
        Result {
            id: ::std::string::String,
            result: ::std::string::String,
        },
        Error {
            error: ::std::string::String,
            id: ::std::string::String,
        },
    }

Like it does for the following schema:

Spec with oneOf only
{
    "openapi": "3.0.0",
    "info": {
        "title": "My API",
        "version": "1.0.0"
    },
    "paths": {
        "/my_request": {
            "post": {
                "operationId": "my_request",
                "requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/JsonRpcResponse_for_Result_and_Error"
                            }
                        }
                    },
                    "required": true
                },
                "responses": {
                    "200": {
                        "description": "",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "string"
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "components": {
        "schemas": {
            "JsonRpcResponse_for_Result_and_Error": {
                "oneOf": [
                    {
                        "properties": {
                            "result": {
                                "type": "string"
                            },
                            "id": {
                                "type": "string"
                            }
                        },
                        "required": [
                            "result",
                            "id"
                        ],
                        "type": "object",
                        "title": "Result"
                    },
                    {
                        "properties": {
                            "error": {
                                "type": "string"
                            },
                            "id": {
                                "type": "string"
                            }
                        },
                        "required": [
                            "error",
                            "id"
                        ],
                        "type": "object",
                        "title": "Error"
                    }
                ],
                "title": "JsonRpcResponse_for_Result_and_Error",
                "type": "object"
            }
        }
    }
}

So I guess the change may be to use titles of object's children as a source for naming current enum Option.

I would provide a real example we are dealing with at https://github.com/near/nearcore/, which is a spec for StateChangeCauseView.
The result is kinda messy - you can see Variant10. The original type is actually a struct with enum flattened into it

I believe fixing this would provide a more human readable code and would be better for developer experience for most cases.

Dominant language
Rust
Stars
898
Forks
114
Avg merge
4h 18m
Merged PRs (30d)
14

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oxidecomputer/typify

All issues in oxidecomputer/typify

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.