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

Swift 5.9 parameter ownership modifiers #54

Open
oscbyspro opened this issue Aug 11, 2023 · 1 comment
Open

Swift 5.9 parameter ownership modifiers #54

oscbyspro opened this issue Aug 11, 2023 · 1 comment
Labels
await can't be done yet brrr such code, much wow

Comments

@oscbyspro
Copy link
Owner

oscbyspro commented Aug 11, 2023

Introduction

Swift 5.9 (SE-0377) introduces borrowing and consuming parameter ownership modifiers.

An immediate use case

I'm working on some utility methods with the following inout convention:

@inlinable public static func incrementSufficientUnsignedInteger<T>(
_ pointee: inout T, by digit: T.Element, plus bit: inout Bool, at index: inout T.Index)
where T: MutableCollection, T.Element: NBKFixedWidthInteger & NBKUnsignedInteger { ... }

These are used instead of the much more ergonomic return convention:

@inlinable public static func incrementSufficientUnsignedInteger<T>(
_ pointee: inout T, by digit: T.Element, plus bit: Bool, at index: T.Index) -> (index: T.Index, overflow: Bool)
where T: MutableCollection, T.Element: NBKFixedWidthInteger & NBKUnsignedInteger { ... }

I've tried every reasonable combination of attributes, but can't make it perform as well as the inout version. I assume this is related to parameter ownership, and that I want to consume the arguments. I'm not sure this is the solution, but I hope so:

@inlinable public static func incrementSufficientUnsignedInteger<T>(
_ pointee: inout T, by digit: consuming T.Element, plus bit: consuming Bool, at index: consuming T.Index) -> (index: T.Index, overflow: Bool)
where T: MutableCollection, T.Element: NBKFixedWidthInteger & NBKUnsignedInteger { ... }
@oscbyspro oscbyspro added await can't be done yet brrr such code, much wow labels Aug 11, 2023
@oscbyspro
Copy link
Owner Author

Hm. I'm not convinced it's a solution to the problem mentioned, but there are still other uses for it. More so with UIntXL (#33), where it is important to avoid unnecessary copy-on-writes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
await can't be done yet brrr such code, much wow
Projects
None yet
Development

No branches or pull requests

1 participant