Skip to content

[stdlib] Various documentation fixes #5723

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

Merged
merged 5 commits into from
Nov 16, 2016

Conversation

natecook1000
Copy link
Member

@natecook1000 natecook1000 commented Nov 11, 2016

This PR includes a variety of revisions to the standard library documentation:

  • Fix incorrect type in Float(_:String) examples
  • Expand discussions for ExpressibleBy____Literal protocols
  • Add notes about non-escaping unsafe pointers from closures
  • Add note about isEmpty to Collection.count discussions
  • Describe imported Bool types
  • Clean up some floating point discussions
  • Provide some additional operator documentation
  • Revise documentation for CVarArg functions
  • Fix incorrect Set method parameter descriptions
  • Clarify array bridging behavior
  • Add collection subscript complexity notes

- Fix incorrect type in Float(_:String) examples
- Expand discussions for ExpressibleBy_Literal protocols
- Add notes about non-escaping unsafe pointers from closures
- Add note about isEmpty to Collection.count discussions
- Describe imported `Bool` types
- Clean up some floating point discussions
- Provide some additional operator documentation
- Revise documentation for CVarArg functions
- Fix incorrect Set method parameter descriptions
- Clarify array bridging behavior
- Add collection subscript complexity notes
@natecook1000
Copy link
Member Author

@swift-ci Please smoke test

@natecook1000
Copy link
Member Author

@swift-ci Please smoke test

1 similar comment
@natecook1000
Copy link
Member Author

@swift-ci Please smoke test

@tkremenek
Copy link
Member

@airspeedswift OK to merge?

@natecook1000
Copy link
Member Author

@swift-ci Please smoke test

Copy link
Member

@airspeedswift airspeedswift left a comment

Choose a reason for hiding this comment

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

lgtm, few minor things

/// If the array grows larger than its capacity, it discards its current
/// storage and allocates a larger one.
/// If you add more elements to an array than it can hold with its current
/// capacity, it discards its current storage and allocates a larger one.
Copy link
Member

Choose a reason for hiding this comment

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

Something about the word storage being in the singular makes these read oddly to me.

Copy link
Member Author

Choose a reason for hiding this comment

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

I borrowed a paragraph from the type discussion that better communicates this bit.

@@ -97,6 +99,8 @@ public protocol _IndexableBase {
/// - Parameter bounds: A range of the collection's indices. The upper and
/// lower bounds of the `bounds` range must be valid indices of the
/// collection.
///
/// - Complexity: O(1)
Copy link
Member

Choose a reason for hiding this comment

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

Is this agreed/inferred from somewhere else? Wonder if there are implementations where this is desirably not the case.

Copy link
Member Author

Choose a reason for hiding this comment

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

I discussed this with Dave A—it's part of the intent of Collection and lots of other complexity guarantees depend on this being true.

///
/// let numberToFind: Int = 23
/// let numberFromString: Int? = Int("23") // Optional(23)
/// if numberToFind == numberFromString {
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if showing comparison to a literal would also help people "get" this i.e. numberFromString == 23

/// is not an `Equatable` type, this operator allows matching against `nil`.
///
/// var numbers: [Int]?
/// if nil ~= numbers {
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to encourage people to do this? I think of this ~= as kind of an implementation detail of the switch usage (esp. given it takes an _ protocol as its arg).

/// `numbers` variable as an optional array of integers. Although `Array<Int>`
/// is not an `Equatable` type, this operator allows matching against `nil`.
///
/// var numbers: [Int]?
Copy link
Member

Choose a reason for hiding this comment

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

Not a huge fan of using implicit initial value of nil in our documentation (not a huge fan of this feature of the language tbh ;)

///
/// var numbers: [Int]?
/// if numbers == nil {
/// print("No numbers to be found.")
Copy link
Member

Choose a reason for hiding this comment

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

Using an optional array in an example also makes me nervous because of the whole empty-vs-nil thing. Can we maybe use an optional scalar instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

I changed these—when conditional conformance lands we would've needed to revisit these anyway, as [Int] will be Comparable then.

/// Returns a subsequence by skipping elements while `predicate` returns
/// `true` and returning the remaining elements.
/// Returns a subsequence starting after the initial, consecutive elements
/// that satisfy the given predicate.
Copy link
Member

Choose a reason for hiding this comment

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

I feel like the original "skipping" wording was clearer regarding the possible consuming nature of this (a subsequence starting after" implies this is a "view" onto some underlying elements)

@airspeedswift
Copy link
Member

airspeedswift commented Nov 15, 2016

LGTM with these changes.

@airspeedswift
Copy link
Member

@swift-ci Please smoke test and merge

1 similar comment
@shahmishal
Copy link
Member

@swift-ci Please smoke test and merge

@thomasbarwanitz
Copy link

Thank you

@natecook1000
Copy link
Member Author

@swift-ci Please smoke test and merge

@swift-ci swift-ci merged commit 67f4ae0 into swiftlang:master Nov 16, 2016
@natecook1000 natecook1000 deleted the nc-fixes-05 branch January 5, 2017 06:46
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.

7 participants