Skip to content
Permalink
main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
This commit changes all 536 remaining lists.swift.org links to their corresponding forums.swift.org URLs.

- `0012-add-noescape-to-public-library-api.md` – I changed this link because it pointed to a only marginally related discussion, not the actual pitch for SE-0012:
  > [Swift Evolution Discussion Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009270.html)

- In some instances it was possible to simplify the links because the forums combines the weekly mailing list archives into a single thread.
  Examples:
  - `0033-import-objc-constants.md` – these two links can be combined into one:
    > Swift-evolution thread: [Original E-Mail](https://forums.swift.org/t/pitch-import-objective-c-constants-as-enums/1114), [Replies](https://forums.swift.org/t/pitch-import-objective-c-constants-as-enums)
  - `0085-package-manager-command-name.md` – these two links became the same thread in Discourse:
    > [Swift Build Review Thread](https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160509/000438.html)
    >
    > [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016931.html)

- I changed some links to point to the top of the respective pitch/review thread, not some post in the middle. Presumably, this was done previously to capture the majority of the discussion in Mailman’s week-based archives, but Discourse has thankfully combined the weekly threads. (I only did this for links that obviously pointed to entire pitch/review discussions, not links that specifically link to a point to highlight a point made in that post.)

  List of these changes:
  - `0045-scan-takewhile-dropwhile`:
    > Swift-evolution thread:
    > [Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011923.html)
  - `0070-optional-requirements.md`:
    > * [Is there an underlying reason why optional protocol requirements need @objc?](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011854.html)
  - `0078-rotate-algorithm.md`:
    > [Swift-evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002213.html)
  - `0079-upgrade-self-from-weak-to-strong.md`:
    > - [Allowing `guard let self = self else { … }` for weakly captured self in a closure.](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009023.html)
  - `0180-string-index-overhaul.md`:
    > Swift-evolution thread: [Pitch: String Index Overhaul](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036874.html)
  - `0189-restrict-cross-module-struct-initializers.md`:
    > * [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171120/041478.html)
  - `0190-target-environment-platform-condition.md`:
    > * [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041695.html)

- Deleted commented-out vestiges from the proposal template, both to clean up and to remove the last vestiges of lists.swift.org links, like this one:

  > ```
  > <!--
  > *During the review process, add the following fields as needed:*
  >
  > * Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/), [Additional Commentary](https://lists.swift.org/pipermail/swift-evolution/)
  > * Bugs: [SR-NNNN](https://bugs.swift.org/browse/SR-NNNN), [SR-MMMM](https://bugs.swift.org/browse/SR-MMMM)
  > * Previous Revision: [1](https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md)
  > * Previous Proposal: [SE-XXXX](XXXX-filename.md)
  > -->
  > ```

  File list:
  - `0153-compensate-for-the-inconsistency-of-nscopyings-behaviour`
  - `0189-restrict-cross-module-struct-initializers.md`
  - `0192-non-exhaustive-enums.md`
  - `0198-playground-quicklook-api-revamp.md`
10 contributors

Users who have contributed to this file

@lattner @benrimmington @jrose-apple @erica @ole @krilnon @jessesquires @DougGregor @austinzheng @addisonleong

Add initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

Introduction

Just as users can create Unsafe[Mutable]Pointers from Ints and UInts, they should be able to create Ints and UInts from Unsafe[Mutable]Pointers. This will allow users to call C functions with intptr_t and uintptr_t parameters, and will allow users to perform more advanced pointer arithmetic than is allowed by UnsafePointers.

Swift Evolution Discussion, Review

Motivation

Swift currently lacks the ability to perform many complex operations on pointers, such as checking pointer alignment, tagging pointers, or XORing pointers (for working with XOR linked lists, for example). As a systems programming language, Swift ought to be able to solve these problems natively and concisely.

Additionally, since some C functions take intptr_t and uintptr_t parameters, Swift currently has no ability to call these functions directly. Users must wrap calls to these functions in C code.

Proposed solution

Initializers will be added to Int and UInt to convert from UnsafePointer, UnsafeMutablePointer, and OpaquePointer.

Currently, the only workaround which can solve these problems is to write any code that requires pointer arithmetic in C. Writing this code in Swift will be no safer than it is in C, as this is a fundamentally unsafe operation. However, it will be cleaner in that users will not be forced to write C code.

Detailed design

The initializers will be implemented using the built-in ptrtoint_Word function.

extension UInt {
  init<T>(bitPattern: UnsafePointer<T>) {
    self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }

  init<T>(bitPattern: UnsafeMutablePointer<T>) {
    self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }

  init(bitPattern: OpaquePointer) {
    self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }
}

extension Int {
  init<T>(bitPattern: UnsafePointer<T>) {
    self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }

  init<T>(bitPattern: UnsafeMutablePointer<T>) {
    self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }

  init(bitPattern: OpaquePointer) {
    self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
  }
}

As an example, these initializers will allow the user to get the next address of an XOR linked list in Swift.

struct XORLinkedList<T> {
  let address: UnsafePointer<T>

  ...

  func successor(_ predecessor: XORLinkedList<T>) -> XORLinkedList<T> {
    let next = UInt(bitPattern: address) ^ UInt(bitPattern: predecessor.address)
    return XorLinkedList(UnsafePointer<T>(bitPattern: next))
  }
}

Impact on existing code

There is no impact on existing code.

Alternatives considered

Three alternatives were considered.

The first alternative was to add an intValue function to Unsafe[Mutable]Pointer. This alternative was rejected because it is preferred that type conversions be implemented as initializers where possible.

The next alternative was to add functions to Unsafe[Mutable]Pointer which covered the identified pointer arithmetic cases. This alternative was rejected because it either would have required us to imagine every use-case of pointer arithmetic and write functions for them, which is an impossible task, or it would have required adding a full suite of arithmetic and bitwise operators to Unsafe[Mutable]Pointer. Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splitting Unsafe[Mutable]Pointer into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic. Additionally, the implementations of these operations would have probably converted the pointers to integers, perform a single operation, and then convert them back. When chaining operations, this would create a lot of unnecessary conversions.

The last alternative was to forgo these initializers and force users to write all their complicated pointer code in C. This alternative was rejected because it makes Swift less useful as a systems programming language.

Changes from revision 1

  • The proposal was amended post-acceptance to include OpaquePointer. Originally it only included UnsafePointer and UnsafeMutablePointer.