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

Protocol methods shown as "Required. Default implementation provided" sound weird #400

Open
1 of 2 tasks
ktoso opened this issue Jul 25, 2022 · 1 comment
Open
1 of 2 tasks
Labels
enhancement New feature or request Improvement

Comments

@ktoso
Copy link
Member

ktoso commented Jul 25, 2022

Description

Given a protocol like

public protocol ClusterSingleton { 
  func activateSingleton() async
  // ...
}

extension ClusterSingleton {
  public func activateSingleton() async {
    // nothing by default
  }
  
  // ...
}

the methods are listed as:

Screenshot 2022-07-25 at 19 45 48

I'm wondering if the wording isn't rather sub-optimal here...

The strong required makes it look like the implementation HAS TO provide an implementation, but in fact, it does not have to -- since the default impl is provided, making his requirement optional to implement.

In Swift, all protocol requirements are "required", but it depends if they have an default impl or not if we have to implement them or not...

Checklist

  • If possible, I've reproduced the issue using the main branch of this package.
  • This issue hasn't been addressed in an existing GitHub issue.

Expected Behavior

Consider omitting the Required. bold wording from such protocol requirements when a default impl is found?

This might be more complex when the extension has where clauses, then probably ok to keep this as Required, but when the extension is always applied, such requirements can be seen as optional to implement.

Actual behavior

All requirements always get the bold Required. marker

Steps To Reproduce

No response

Swift-DocC-Render Version Information

5.7

@ktoso ktoso added enhancement New feature or request Improvement labels Jul 25, 2022
@mportiz08
Copy link
Contributor

\cc @willimholte

I agree the wording can be a little confusing for this specific scenario, even though it is technically correct—it is still required but the API itself has met that requirement with its default implementation and not strictly necessary for client code to provide their own implementation. I think it could be argued that the text could be dropped here as you point out.

Your note about the complexity of the scenario with where clauses has me wondering if the renderer could even special case something like this though since it wouldn't necessarily have details about that kind of information without parsing the declaration text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Improvement
Projects
None yet
Development

No branches or pull requests

2 participants