From 71d85e9573cd4aca89c053245042395f132f199c Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Wed, 27 Nov 2024 13:15:14 +0100 Subject: [PATCH 1/6] [SOAR-0013] Idiomatic naming strategy --- .../Documentation.docc/Proposals/Proposals.md | 1 + .../Documentation.docc/Proposals/SOAR-0013.md | 156 ++++++++++++++++++ 2 files changed, 157 insertions(+) create mode 100644 Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md diff --git a/Sources/swift-openapi-generator/Documentation.docc/Proposals/Proposals.md b/Sources/swift-openapi-generator/Documentation.docc/Proposals/Proposals.md index 0bc8421e..bdaff6a5 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/Proposals.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/Proposals.md @@ -54,3 +54,4 @@ If you have any questions, tag [Honza Dvorsky](https://github.com/czechboy0) or - - - +- diff --git a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md new file mode 100644 index 00000000..a027cbe6 --- /dev/null +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -0,0 +1,156 @@ +# SOAR-0013: Idiomatic naming strategy + +Introduce an alternative naming strategy for more idiomatic Swift identifiers, including a way to provide custom name overrides. + +## Overview + +- Proposal: SOAR-0013 +- Author(s): [Honza Dvorsky](https://github.com/czechboy0), [Si Beaumont](https://github.com/simonjbeaumont) +- Status: **Awaiting Review** +- Issues: + - [apple/swift-openapi-generator#112][issuePlugin] + - [apple/swift-openapi-generator#107][issue1] + - [apple/swift-openapi-generator#503][issue2] + - [apple/swift-openapi-generator#244][issue3] + - [apple/swift-openapi-generator#405][issue4] +- Implementation: + - [apple/swift-openapi-generator#679][pr] +- New configuration options: + - `namingStrategy` + - `nameOverrides` +- Affected components: + - generator + +### Introduction + +Introduce a new naming strategy as an opt-in feature, instructing the generator to produce more conventional Swift names, and offer a way to completely customize how any OpenAPI identifier gets projected to a Swift identifier. + +### Motivation + +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. 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. + +In response to these findings, [SOAR-0001: Improved mapping of identifiers][soar0001], which shipped in 0.2.0, changed the naming strategy to avoid these conflicts, allowing hundreds of additional OpenAPI documents to be correctly handled by Swift OpenAPI Generator. This addressed all issues related to naming conflicts in the test corpus. This is the existing naming strategy today. This strategy also avoids changing the character casing, as we discovered OpenAPI documents with properties within an object schema that only differed by case. + +The way the conflicts are avoided in the naming strategy from SOAR-0001 is by turning any special characters (any characters that aren't letters, numbers, or an underscore) into words, resulting in identifiers like: + +``` +User -> User +User_1 -> User_1 +user-name -> user_hyphen_name +my.org.User -> my_period_org_period_User +``` + +Our priority was to support as many valid OpenAPI documents as possible. However, we've also [heard][issue1] [from][issue2] [adopters][issue3] [who][issue4] would prefer more idiomatic generated code and don't benefit from the defensive naming strategy. + +### Proposed solution + +We propose to introduce a second, opt-in naming strategy, which produces idiomatic Swift identifiers from arbitrary OpenAPI names, and a way to fully customize the conversion from an OpenAPI name to a Swift identifier using a string -> string map. + +For clarity, we'll refer to the existing naming strategy as the "defensive" naming strategy, and to the new proposed strategy as the "idiomatic" naming strategy. The names reflect the strengths of each strategy - the defensive strategy can handle any OpenAPI document and produce compiling Swift code, the idiomatic naming strategy produces prettier names, but does not work for all documents, and falls back to the defensive strategy when needed on a per-name basis. + +Part of the new strategy is adjusting the capitalization, and producing `UpperCamelCase` names for types, and `lowerCamelCase` names for members, as is common in hand-written Swift code. + +After attempting to produce an more idiomatic identifier, this strategy will fall back to the defensive strategy, to replace any remaining invalid symbols. + +The second feature introduced as part of this proposal is a way to provide a string -> string map to fully override only specific OpenAPI names and provide their exact Swift identifiers. This is the ultimate escape hatch when both naming strategies fail to provide the desired result for the adopter. + +> Note: Because the idiomatic naming strategy can change capitalization, in rare cases it can still generate non-compiling code from a valid OpenAPI document. We recommend using the idiomatic naming strategy and, if it produces conflicts, address them using name overrides, or switch back to the defensive naming strategy. + +#### Examples + +To get a sense for the proposed change, check out the table below that compares the existing defensive strategy against the proposed idiomatic strategy on a set of examples: + +| OpenAPI name | Defensive | Idiomatic (capitalized) | Idiomatic (non-capitalized) | +| ------------ | --------- | ------------------------ | ---------------------------- | +| `foo` | `foo` | `Foo` | `foo` | +| `Hello world` | `Hello_space_world` | `HelloWorld` | `helloWorld` | +| `My_URL_value` | `My_URL_value` | `MyURLValue` | `myURLValue` | +| `Retry-After` | `Retry_hyphen_After` | `RetryAfter` | `retryAfter` | +| `NOT_AVAILABLE` | `NOT_AVAILABLE` | `NotAvailable` | `notAvailable` | +| `version 2.0` | `version_space_2_period_0` | `Version2_0` | `version2_0` | +| `naïve café` | `naïve_space_café` | `NaïveCafé` | `naïveCafé` | +| `__user` | `__user` | `__User` | `__user` | +| `order#123` | `order_num_123` | `order_num_123` | `order_num_123` | + +Notice that in the last example, since the OpenAPI name contains the pound (`#`) character, the idiomatic naming strategy falls back to the defensive naming strategy. In all the other cases, however, the resulting names are more idiomatic Swift identifiers. + +> Tip: For more examples, check out the updated [test suite](https://github.com/czechboy0/swift-openapi-generator/blob/hd-naming-strategy-optimistic/Tests/OpenAPIGeneratorCoreTests/Extensions/Test_SwiftSafeNames.swift). + +### Detailed design + +This section goes into detail of the [draft implementation][pr] that you can already check out and try to run on your OpenAPI document. + +> Note: To enable it, you'll need to add `namingStrategy: idiomatic` to your `openapi-generator-config.yaml` file. + +#### Naming logic + +The idiomatic naming strategy (check out the current code [here][impl], look for the method `safeForSwiftCode_idiomatic`) is built around the decision to _only_ optimize for names that include the following: + +- letters +- numbers +- periods (`.`, ASCII: `0x2e`) +- dashes (`-`, ASCII: `0x2d`) +- underscores (`_`, ASCII: `0x5f`) +- spaces (` `, ASCII: `0x20`) + +> Note: We let [`Swift.String.isLetter`](https://developer.apple.com/documentation/swift/character/isletter) decide whether a character is a letter, which has the advantage of including letters in the non-ASCII range. Swift identifiers also support a [wide range](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure/#Identifiers) of alphanumeric characters. + +If the OpenAPI name includes any _other_ characters, the idiomatic naming strategy _falls back_ to the defensive naming strategy for that input string only. + +There's a second special case for handling all uppercased names, such as `NOT_AVAILABLE` - if this situation is detected, the idiomatic naming strategy turns it into `NotAvailable` for types and `notAvailable` for members. + +The best way to understand the detailed logic is to check out the [code][impl], feel free to leave comments on the pull request. + +#### Naming strategy configuration + +Since Swift OpenAPI Generator is on a stable 1.x version, we cannot change the naming strategy for everyone, as it would be considered an API break. So this new naming strategy is fully opt-in using a new configuration key called `namingStrategy`, with the following allowed values: + +- `defensive`: the existing naming strategy introduced in 0.2.0 +- `idiomatic`: the new naming strategy proposed here +- not specified: defaults to `defensive` for backwards compatibility + +Enabling this feature in the configuration file would look like this: + +```yaml +namingStrategy: idiomatic +``` + +#### Name overrides + +While the new naming strategy produces much improved Swift names, there are still cases when the adopter knows better how they'd like a specific OpenAPI name be translated to a Swift identifier. + +A good examples are the `+1` and `-1` properties in the GitHub OpenAPI document: using both strategies, the names would be `_plus_1` and `_hyphen_1`, respectively. While such names aren't too confusing, the adopter might want to customize them to, for example: `thumbsUp` and `thumbsDown`. + +Enabling this feature in the configuration file would look like this: + +```yaml +nameOverrides: + '+1': 'thumbsUp' + '-1': 'thumbsDown' +``` + +### API stability + +Both the new naming strategy and name overrides are purely additive, and require the adopter to explicitly opt-in. + +### Future directions + +With this proposal, we plan to abandon the ["naming extensions" idea][issuePlugin], as we consider the solution in this proposal to solve the name conversion problem for Swift OpenAPI Generator 1.x for all use cases. + +### Alternatives considered + +- ["Naming extensions"][issuePlugin], however that'd require the community to build and maintain custom naming strategies, and it was not clear that this feature would be possible in SwiftPM using only current features. +- Not changing anything, this was the status quo since 0.2.0, but adopters have made it clear that there is room to improve the naming strategy through the several filed issues linked at the top of the proposal, so we feel that some action here is justified. + +[soar0001]: https://swiftpackageindex.com/apple/swift-openapi-generator/documentation/swift-openapi-generator/soar-0001 +[issue1]: https://github.com/apple/swift-openapi-generator/issues/107 +[issue2]: https://github.com/apple/swift-openapi-generator/issues/503 +[issue3]: https://github.com/apple/swift-openapi-generator/issues/244 +[issue4]: https://github.com/apple/swift-openapi-generator/issues/405 +[issuePlugin]: https://github.com/apple/swift-openapi-generator/issues/112 +[pr]: https://github.com/apple/swift-openapi-generator/pull/679 +[impl]: https://github.com/czechboy0/swift-openapi-generator/blob/hd-naming-strategy-optimistic/Sources/_OpenAPIGeneratorCore/Translator/CommonTranslations/SwiftSafeNames.swift From c87190e79dfcc71b3710b4600bf062396671748d Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Wed, 27 Nov 2024 13:25:58 +0100 Subject: [PATCH 2/6] Update status --- .../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 a027cbe6..8f0b2084 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -6,7 +6,7 @@ Introduce an alternative naming strategy for more idiomatic Swift identifiers, i - Proposal: SOAR-0013 - Author(s): [Honza Dvorsky](https://github.com/czechboy0), [Si Beaumont](https://github.com/simonjbeaumont) -- Status: **Awaiting Review** +- Status: **In Review** - Issues: - [apple/swift-openapi-generator#112][issuePlugin] - [apple/swift-openapi-generator#107][issue1] From ce91c22e11f59636aeebec382311fc57d283e21a Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Thu, 28 Nov 2024 11:45:15 +0100 Subject: [PATCH 3/6] Proposal update v1.1 - improved the handling of synthesized operationIds --- .../Documentation.docc/Proposals/SOAR-0013.md | 6 ++++++ 1 file changed, 6 insertions(+) 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 8f0b2084..4a938efa 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -7,6 +7,9 @@ Introduce an alternative naming strategy for more idiomatic Swift identifiers, i - Proposal: SOAR-0013 - Author(s): [Honza Dvorsky](https://github.com/czechboy0), [Si Beaumont](https://github.com/simonjbeaumont) - Status: **In Review** +- Versions: + - v1.0 (2024-11-27): Initial version + - v1.1 (2024-11-28): Also handle "/", "{", and "}" for better synthesized operation names - Issues: - [apple/swift-openapi-generator#112][issuePlugin] - [apple/swift-openapi-generator#107][issue1] @@ -74,6 +77,7 @@ To get a sense for the proposed change, check out the table below that compares | `version 2.0` | `version_space_2_period_0` | `Version2_0` | `version2_0` | | `naïve café` | `naïve_space_café` | `NaïveCafé` | `naïveCafé` | | `__user` | `__user` | `__User` | `__user` | +| `get/pets/{petId}` _Added in v1.1_ | `get_sol_pets_sol__lcub_petId_rcub_` | `Get_pets_petId` | `get_pets_petId` | | `order#123` | `order_num_123` | `order_num_123` | `order_num_123` | Notice that in the last example, since the OpenAPI name contains the pound (`#`) character, the idiomatic naming strategy falls back to the defensive naming strategy. In all the other cases, however, the resulting names are more idiomatic Swift identifiers. @@ -96,6 +100,8 @@ The idiomatic naming strategy (check out the current code [here][impl], look for - dashes (`-`, ASCII: `0x2d`) - underscores (`_`, ASCII: `0x5f`) - spaces (` `, ASCII: `0x20`) +- slashes (`/`, ASCII: `0x2f`) _Added in v1.1_ +- curly braces (`{` and `}`, ASCII: `0x7b` and `0x7d`) _Added in v1.1_ > Note: We let [`Swift.String.isLetter`](https://developer.apple.com/documentation/swift/character/isletter) decide whether a character is a letter, which has the advantage of including letters in the non-ASCII range. Swift identifiers also support a [wide range](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure/#Identifiers) of alphanumeric characters. From e1f5e429db5c1061b5e270268966217184b22608 Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Tue, 10 Dec 2024 16:23:56 +0100 Subject: [PATCH 4/6] Version: 1.2: Updated based on feedback --- .../Documentation.docc/Proposals/SOAR-0013.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) 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 4a938efa..b67ee4b1 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -10,6 +10,7 @@ Introduce an alternative naming strategy for more idiomatic Swift identifiers, i - Versions: - v1.0 (2024-11-27): Initial version - v1.1 (2024-11-28): Also handle "/", "{", and "}" for better synthesized operation names + - v1.2 (2024-12-10): Treat "/" as a word separator and improve handling of the lowercasing of acronyms at the start of an identifier. - Issues: - [apple/swift-openapi-generator#112][issuePlugin] - [apple/swift-openapi-generator#107][issue1] @@ -57,7 +58,7 @@ For clarity, we'll refer to the existing naming strategy as the "defensive" nami Part of the new strategy is adjusting the capitalization, and producing `UpperCamelCase` names for types, and `lowerCamelCase` names for members, as is common in hand-written Swift code. -After attempting to produce an more idiomatic identifier, this strategy will fall back to the defensive strategy, to replace any remaining invalid symbols. +This strategy will fall back to the defensive strategy if it encounters any invalid symbols in the identifier. The second feature introduced as part of this proposal is a way to provide a string -> string map to fully override only specific OpenAPI names and provide their exact Swift identifiers. This is the ultimate escape hatch when both naming strategies fail to provide the desired result for the adopter. @@ -77,7 +78,8 @@ To get a sense for the proposed change, check out the table below that compares | `version 2.0` | `version_space_2_period_0` | `Version2_0` | `version2_0` | | `naïve café` | `naïve_space_café` | `NaïveCafé` | `naïveCafé` | | `__user` | `__user` | `__User` | `__user` | -| `get/pets/{petId}` _Added in v1.1_ | `get_sol_pets_sol__lcub_petId_rcub_` | `Get_pets_petId` | `get_pets_petId` | +| `get/pets/{petId}` _Changed in v1.2_ | `get_sol_pets_sol__lcub_petId_rcub_` | `GetPetsPetId` | `getPetsPetId` | +| `HTTPProxy` _Added in v1.2_ | `HTTPProxy` | `HTTPProxy` | `httpProxy` | | `order#123` | `order_num_123` | `order_num_123` | `order_num_123` | Notice that in the last example, since the OpenAPI name contains the pound (`#`) character, the idiomatic naming strategy falls back to the defensive naming strategy. In all the other cases, however, the resulting names are more idiomatic Swift identifiers. @@ -100,7 +102,7 @@ The idiomatic naming strategy (check out the current code [here][impl], look for - dashes (`-`, ASCII: `0x2d`) - underscores (`_`, ASCII: `0x5f`) - spaces (` `, ASCII: `0x20`) -- slashes (`/`, ASCII: `0x2f`) _Added in v1.1_ +- slashes (`/`, ASCII: `0x2f`) _Added in v1.1, changed meaning in 1.2_ - curly braces (`{` and `}`, ASCII: `0x7b` and `0x7d`) _Added in v1.1_ > Note: We let [`Swift.String.isLetter`](https://developer.apple.com/documentation/swift/character/isletter) decide whether a character is a letter, which has the advantage of including letters in the non-ASCII range. Swift identifiers also support a [wide range](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure/#Identifiers) of alphanumeric characters. From 73fd986e874fb94ab738b6f81627786ddc63ae60 Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Tue, 17 Dec 2024 09:42:09 +0100 Subject: [PATCH 5/6] Proposal revision v1.3 --- .../Documentation.docc/Proposals/SOAR-0013.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) 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 b67ee4b1..38b5be06 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -11,6 +11,7 @@ Introduce an alternative naming strategy for more idiomatic Swift identifiers, i - v1.0 (2024-11-27): Initial version - v1.1 (2024-11-28): Also handle "/", "{", and "}" for better synthesized operation names - v1.2 (2024-12-10): Treat "/" as a word separator and improve handling of the lowercasing of acronyms at the start of an identifier. + - v1.3 (2024-12-17): Add "+" as a word separator, clarify that defensive strategy always post-processes the output of the idiomatic strategy, clarify that content type names also change with the idiomatic strategy - Issues: - [apple/swift-openapi-generator#112][issuePlugin] - [apple/swift-openapi-generator#107][issue1] @@ -54,11 +55,13 @@ Our priority was to support as many valid OpenAPI documents as possible. However We propose to introduce a second, opt-in naming strategy, which produces idiomatic Swift identifiers from arbitrary OpenAPI names, and a way to fully customize the conversion from an OpenAPI name to a Swift identifier using a string -> string map. -For clarity, we'll refer to the existing naming strategy as the "defensive" naming strategy, and to the new proposed strategy as the "idiomatic" naming strategy. The names reflect the strengths of each strategy - the defensive strategy can handle any OpenAPI document and produce compiling Swift code, the idiomatic naming strategy produces prettier names, but does not work for all documents, and falls back to the defensive strategy when needed on a per-name basis. +For clarity, we'll refer to the existing naming strategy as the "defensive" naming strategy, and to the new proposed strategy as the "idiomatic" naming strategy. The names reflect the strengths of each strategy - the defensive strategy can handle any OpenAPI document and produce compiling Swift code, the idiomatic naming strategy produces prettier names, but does not work for all documents. Part of the new strategy is adjusting the capitalization, and producing `UpperCamelCase` names for types, and `lowerCamelCase` names for members, as is common in hand-written Swift code. -This strategy will fall back to the defensive strategy if it encounters any invalid symbols in the identifier. +This strategy will pre-process the input string, and then still apply the defensive strategy on the output, to handle any illegal characters that are no explicitly handled by the idiomatic strategy. + +The configurable naming strategy will affect not only general names from the OpenAPI document ([SOAR-0001][soar0001]), but also content type names ([SOAR-0002][soar0002]). The second feature introduced as part of this proposal is a way to provide a string -> string map to fully override only specific OpenAPI names and provide their exact Swift identifiers. This is the ultimate escape hatch when both naming strategies fail to provide the desired result for the adopter. @@ -80,9 +83,10 @@ To get a sense for the proposed change, check out the table below that compares | `__user` | `__user` | `__User` | `__user` | | `get/pets/{petId}` _Changed in v1.2_ | `get_sol_pets_sol__lcub_petId_rcub_` | `GetPetsPetId` | `getPetsPetId` | | `HTTPProxy` _Added in v1.2_ | `HTTPProxy` | `HTTPProxy` | `httpProxy` | +| `application/myformat+json` _Added in v1.3_ | `application_myformat_plus_json` | - | `applicationMyformatJson` | | `order#123` | `order_num_123` | `order_num_123` | `order_num_123` | -Notice that in the last example, since the OpenAPI name contains the pound (`#`) character, the idiomatic naming strategy falls back to the defensive naming strategy. In all the other cases, however, the resulting names are more idiomatic Swift identifiers. +Notice that in the last example, since the OpenAPI name contains the pound (`#`) character, the idiomatic naming strategy lets the defensive naming strategy handle the illegal character. In all the other cases, however, the resulting names are more idiomatic Swift identifiers. > Tip: For more examples, check out the updated [test suite](https://github.com/czechboy0/swift-openapi-generator/blob/hd-naming-strategy-optimistic/Tests/OpenAPIGeneratorCoreTests/Extensions/Test_SwiftSafeNames.swift). @@ -104,10 +108,11 @@ The idiomatic naming strategy (check out the current code [here][impl], look for - spaces (` `, ASCII: `0x20`) - slashes (`/`, ASCII: `0x2f`) _Added in v1.1, changed meaning in 1.2_ - curly braces (`{` and `}`, ASCII: `0x7b` and `0x7d`) _Added in v1.1_ +- pluses (`+`, ASCII: `0x2b`) _Added in v1.3_ > Note: We let [`Swift.String.isLetter`](https://developer.apple.com/documentation/swift/character/isletter) decide whether a character is a letter, which has the advantage of including letters in the non-ASCII range. Swift identifiers also support a [wide range](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure/#Identifiers) of alphanumeric characters. -If the OpenAPI name includes any _other_ characters, the idiomatic naming strategy _falls back_ to the defensive naming strategy for that input string only. +If the OpenAPI name includes any _other_ characters, the idiomatic naming strategy lets the defensive strategy handle those characters. There's a second special case for handling all uppercased names, such as `NOT_AVAILABLE` - if this situation is detected, the idiomatic naming strategy turns it into `NotAvailable` for types and `notAvailable` for members. @@ -155,6 +160,7 @@ With this proposal, we plan to abandon the ["naming extensions" idea][issuePlugi - Not changing anything, this was the status quo since 0.2.0, but adopters have made it clear that there is room to improve the naming strategy through the several filed issues linked at the top of the proposal, so we feel that some action here is justified. [soar0001]: https://swiftpackageindex.com/apple/swift-openapi-generator/documentation/swift-openapi-generator/soar-0001 +[soar0002]: https://swiftpackageindex.com/apple/swift-openapi-generator/documentation/swift-openapi-generator/soar-0002 [issue1]: https://github.com/apple/swift-openapi-generator/issues/107 [issue2]: https://github.com/apple/swift-openapi-generator/issues/503 [issue3]: https://github.com/apple/swift-openapi-generator/issues/244 From 64c26098eb9722dc761b493748dcc6049b3c194a Mon Sep 17 00:00:00 2001 From: Honza Dvorsky Date: Wed, 18 Dec 2024 17:19:38 +0100 Subject: [PATCH 6/6] Update status --- .../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 38b5be06..5d005788 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0013.md @@ -6,7 +6,7 @@ Introduce an alternative naming strategy for more idiomatic Swift identifiers, i - Proposal: SOAR-0013 - Author(s): [Honza Dvorsky](https://github.com/czechboy0), [Si Beaumont](https://github.com/simonjbeaumont) -- Status: **In Review** +- Status: **Implemented (1.6.0)** - Versions: - v1.0 (2024-11-27): Initial version - v1.1 (2024-11-28): Also handle "/", "{", and "}" for better synthesized operation names