Skip to content

[docs] Describe the Curiously Recursive Inlinable Switch Pattern #22643

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 1 commit into from
Feb 19, 2019

Conversation

jrose-apple
Copy link
Contributor

Adds a section to the Standard Library Programmer's Manual for resilience, along with the first entry about CRISP.

https://twitter.com/AirspeedSwift/status/1020449828717785089

https://twitter.com/UINT_MIN/status/1020503397357760512

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

Copy link
Contributor

@stephentyrone stephentyrone left a comment

Choose a reason for hiding this comment

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

Thanks for writing this up!

Copy link
Member

@milseman milseman left a comment

Choose a reason for hiding this comment

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

LGTM!


Maintaining ABI compatibility with previously released versions of the standard library makes things more complicated. This section details some of the extra rules to remember and patterns to use.

### The Curiously Recurring Inlinable Switch Pattern (CRISP)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
### The Curiously Recurring Inlinable Switch Pattern (CRISP)
### The Curiously Recursive Inlinable Switch Pattern (CRISP)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a reference to the Curiously Recurring Template Pattern, but maybe it doesn't need to be.

Copy link
Contributor

Choose a reason for hiding this comment

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

Either name is fine by me, but you've used the "Curiously Recursive Inlinable Switch Pattern" elsewhere (in the final paragraph of the section; and in the commit/PR title).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ooh, whoops, thanks! Okay then.

}
```

Because `_roundSlowPath(_:)` isn't inlinable, the version of `round(_:)` that gets called at run time will always be the version implemented in the standard library dylib. And since FloatingPointRoundingRule is *also* defined in the standard library, we know it'll never be out of sync with this version of `round(_:)`.
Copy link
Contributor

@moiseev moiseev Feb 15, 2019

Choose a reason for hiding this comment

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

Suggested change
Because `_roundSlowPath(_:)` isn't inlinable, the version of `round(_:)` that gets called at run time will always be the version implemented in the standard library dylib. And since FloatingPointRoundingRule is *also* defined in the standard library, we know it'll never be out of sync with this version of `round(_:)`.
Because `_roundSlowPath(_:)` isn't inlinable, the version of `round(_:)` that gets called at run time will always be the version implemented in the standard library dylib. And since `FloatingPointRoundingRule` is *also* defined in the standard library, we know it'll never be out of sync with this version of `round(_:)`.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Heh. My personal style is to not codefont type names, but I should defer to whatever the document is already doing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like the document agrees with me ("AnyObject", "Strings").

@jrose-apple jrose-apple force-pushed the americans-call-it-chip branch from 19f3212 to 2c1201f Compare February 16, 2019 03:23
@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test and merge

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test Linux

@jrose-apple jrose-apple merged commit ef04b24 into swiftlang:master Feb 19, 2019
@jrose-apple jrose-apple deleted the americans-call-it-chip branch February 19, 2019 18:33
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.

5 participants