Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify @Argument and @Option initialization paths #477

Merged
merged 2 commits into from Sep 10, 2022
Merged

Conversation

rauhul
Copy link
Contributor

@rauhul rauhul commented Aug 26, 2022

@rauhul rauhul changed the title WIP: add test coverage and fixes for #446 WIP: add test coverage and fixes for #466 Aug 26, 2022
@rauhul rauhul changed the title WIP: add test coverage and fixes for #466 [WIP] add test coverage and fixes for #466 Aug 29, 2022
@rauhul rauhul force-pushed the fix-446 branch 2 times, most recently from 5a1e4b7 to b45568b Compare September 9, 2022 04:27
@rauhul rauhul changed the title [WIP] add test coverage and fixes for #466 Unify @Argument and @Option initialization paths Sep 9, 2022
@rauhul rauhul marked this pull request as ready for review September 9, 2022 04:28
@rauhul
Copy link
Contributor Author

rauhul commented Sep 9, 2022

@swift-ci please test

Copy link
Member

@natecook1000 natecook1000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great — thanks in particular for the extra test coverage 👏🏻👏🏻👏🏻

I don't feel like we have a great way to know exactly whether APIs are being introduced / removed here. I ran the breaking changes diagnostic, and after stripping some spurious errors (it doesn't think that changing the name a generic parameter is okay), I'm still seeing these four breaks — could you take a look to see if these are real or not?

  💔 API breakage: constructor Argument.init(wrappedValue:parsing:help:completion:) has parameter 0 type change from Value to [Element]
  💔 API breakage: constructor Argument.init(wrappedValue:parsing:help:completion:transform:) has parameter 0 type change from Value to [Element]
  💔 API breakage: constructor Option.init(wrappedValue:name:parsing:help:completion:) has parameter 0 type change from [Element] to Value
  💔 API breakage: constructor Option.init(wrappedValue:name:parsing:help:completion:transform:) has parameter 0 type change from [Element] to Value

Comment on lines +5 to +6
HelpGenerationTests+AtArgument.swift
HelpGenerationTests+AtOption.swift
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ᵗʰᵃⁿᵏ ʸᵒᵘ

- Fixes #466.
- Adds initializers to ArgumentDefinition generic over a Container type.
  The Container type must conform to a new internal protocol
  ArgumentDefinitionContainer which describes functionality like default
  set of help options for the argument defined by the property wrapper,
  etc.
- Adds overloads for Optional @arguments and @options with default
  values which emit deprecation warning to guide users towards using the
  non-Optional versions.
@rauhul
Copy link
Contributor Author

rauhul commented Sep 9, 2022

@natecook1000 those are all spurious AFAICT, I reran locally to verify again.

@rauhul
Copy link
Contributor Author

rauhul commented Sep 9, 2022

@swift-ci please test

1 similar comment
@rauhul
Copy link
Contributor Author

rauhul commented Sep 10, 2022

@swift-ci please test

Copy link
Member

@natecook1000 natecook1000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

@natecook1000 natecook1000 merged commit 607021b into main Sep 10, 2022
@natecook1000 natecook1000 deleted the fix-446 branch September 10, 2022 23:40
natecook1000 added a commit that referenced this pull request Feb 29, 2024
Due to the restructuring in #477, there was ambiguity between the
unconstrained `@Option` initializer that uses a transform (but no
initial value) and the one that is constrained to the property being
optional. This marks the unconstrained version as disfavored, which
allows overload resolution to select the optional version when
appropriate.

Fixes #618.
natecook1000 added a commit that referenced this pull request Mar 5, 2024
Due to the restructuring in #477, there was ambiguity between the
unconstrained `@Option` initializer that uses a transform (but no
initial value) and the one that is constrained to the property being
optional. This marks the unconstrained version as disfavored, which
allows overload resolution to select the optional version when
appropriate.

Also fixes this for `@Argument` and improves documentation
consistency for `@Option`.

Fixes #618.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Including transform: parameter in @Argument declaration generates wrong help message for optional arguments
2 participants