From 4303842668f7ab63c29e638287eb5fe076e4249e Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Mon, 25 Nov 2024 18:32:37 +0100 Subject: [PATCH] Update SOAR-0013.md Co-authored-by: Si Beaumont --- .../Documentation.docc/Proposals/SOAR-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md index 44832c25..b2f1e94f 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -29,7 +29,7 @@ Introduce a new naming strategy as an opt-in feature, instructing the generator The purpose of Swift OpenAPI Generator is to generate Swift code from OpenAPI documents. As part of that process, names specified in the OpenAPI document have to be converted to names in Swift code - and there are many ways to do that. We call these "naming strategies" in this proposal. -When Swift OpenAPI Generator 0.1.0 went open-source in May 2023, it had a simple naming strategy that produced relatively conventional Swift identifiers from OpenAPI names, however when tested on a large test corpus of around 3000 OpenAPI documents, it produced an unacceptably high number of non-compiling packages due to naming conflicts. +When Swift OpenAPI Generator 0.1.0 went open-source in May 2023, it had a simple naming strategy that produced relatively conventional Swift identifiers from OpenAPI names. However, when tested on a large test corpus of around 3000 OpenAPI documents, it produced an unacceptably high number of non-compiling packages due to naming conflicts. The root cause of conflicts are the different allowed character sets for OpenAPI names and Swift identifiers. OpenAPI has a more flexible allowed character set than Swift identifiers.