Skip to content

Instantly share code, notes, and snippets.

@gribozavr

gribozavr/stdlib-api-stability-issues.md Secret

Last active August 10, 2016 11:51
Show Gist options
  • Save gribozavr/37e811f12b27c6365fc88e6f9645634d to your computer and use it in GitHub Desktop.
Save gribozavr/37e811f12b27c6365fc88e6f9645634d to your computer and use it in GitHub Desktop.
Download ZIP
Open Issues Affecting Standard Library API Stability
Raw
stdlib-api-stability-issues.md

Open Issues Affecting Standard Library API Stability

This document lists the outstanding issues whose resolution could cause non-additive standard library API changes.

Low-Hanging Fruit (Difficulty: 1)

  • The global function withUnsafe[Mutable]Pointer(&x) should have an argument label “to”.

    https://bugs.swift.org/browse/SR-1937 rdar://problem/26529498.

  • UnicodeScalar.init(Int) should be failable.

    https://bugs.swift.org/browse/SR-1930 rdar://problem/24110013

  • withUnsafePointer shouldn't take its argument as inout.

    https://bugs.swift.org/browse/SR-1956 rdar://problem/25019862

  • Remove unsafeAddressOf. We are not aware of any real usecases for it. If there are any, it should be renamed to unsafeAddress(of:) to follow the guidelines.

    https://bugs.swift.org/browse/SR-1957 rdar://problem/18589289

  • [SE-0124] Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a bitPattern: label (i.e., Int.init(bitPattern:) and UInt.init(bitPattern:)).

  • Consider renaming or eliminating ManagedProtoBuffer.

    The reason why ManagedProtoBuffer exists is to give the users an extra bit of type safety inside of the closure passed to ManagedBuffer.create(). This closure receives the ManagedBuffer instance and returns the initial value that is stored in the buffer (the header part of the buffer). We are passing the ManagedBuffer as ManagedProtoBuffer to prevent the closure from reading the uninitialized value property. Maybe this extra bit of safety is not worth the API surface complexity.

    https://bugs.swift.org/browse/SR-1955 rdar://problem/26012924 rdar://problem/27118532

  • String.CharacterView.Iterator should be a custom type rather than the default, to allow performance optimizations. Audit all other collections for such opportunities.

    https://bugs.swift.org/browse/SR-1961 rdar://problem/27119937

  • String(count:, repeatedValue:) and String.append() are ambiguous without an explicit cast to Character.

    Fix by removing overloads on Character and UnicodeScalar, leaving only String.

    https://bugs.swift.org/browse/SR-1964 rdar://problem/17028332

  • [DONE] Rename the ~LiteralConvertible protocols according to the resolution of the proposal currently under review.

Moderate (Difficulty: 2)

Hard (Difficulty: 3)

Collections:

  • Figure out the role and design of Sequence and Iterator. Algorithms not marked mutating can consume a single-pass Sequence. Remove Sequence. Make Iterator be the type for single-pass sequences.

    In future Sequence.makeIterator() would be mutating, and we'd require:

    for x in &mySequence { print(x) }

    compare this to:

    for inout x in &myArray { x += 1 }

    Important.

  • Change Collection to be potentially-infinite, and introduce FiniteCollection. Do we need a separate protocol? Can we just add a QoI feature to trap early instead of executing an infinite loop? (We can add a property isKnownToBeInfinite/isKnownToBeFinite that would be checked before the whole collection is iterated.)

    Important.

  • Figure out whether RangeReplaceableCollection.replaceRange should accept a Sequence as its argument, and if so implement it.

    NTBF if we are removing Sequence.

  • Decide whether to drop the Comparable requirement on indices, and if so, do it. Consider the impact on range types. Important.

Naming:

  • Reconsider naming of term-of-art functional algorithms (map, filter, flatten, flatMap etc.) Important.

  • Rationalize the naming of the slicing operations (e.g. prefix, suffix, ...) Important.

Misc:

  • Fallout from the UnsafeRawPointer review currently underway. Important.

  • Design and implement the spaceship operator <=> as a replacement or a supplement for Comparable. Important.

Misc and less important for Swift 3.x:

  • Redesign/reimplement Strideable, fixing issues like the result type of the distance method and applicability to complex numbers, in which case it could no longer imply Comparable.

  • Fix the design of Unmanaged.

Future, Swift 4.0

  • Associative collections with custom hash/equality.

  • More static type safety for PlaygroundQuicklook payloads.

    rdar://problem/22871025

  • Decouple CustomPlaygroundQuicklookable from the standard library.

  • Swiftify the simd module. Current implementation of simd module in Swift mirrors the C API. Swift can provide a better API. (Steve Canon)

  • Range <=> NSRange bridging, including ranges of String.Index

    This will create work on the compiler side once we figure out the design.

Issues Dependent on Compiler Work (Unrated)

  • Remove the Boolean protocol.

  • CVarArgs doesn't support optional pointers.

  • Reflection: what is the design for writing and calling methods through mirrors? Would it affect the current Mirror design in a non-additive way?

  • Due to compiler bugs, some lazy collections have the wrong associated SubSequence types

  • Fallout on APIs from generics changes such as

    • adding “where” constraints on associated types
    • adding recursive constraints
    • adding the ability to nest types in generics
    • typealiases in protocols

    In particular

    • killing off Indexable and the underscored protocols
    • killing off CountableRange and CountableClosedRange
    • Many lazy collection types collapse
    • Collapse 3 Default Indices types
    • Collapse 12 Default Slice types
    • Sink custom iterator and index types into the corresponding primary types (e.g., DictionaryIterator => Dictionary.Iterator)
    • Move lazy collection wrappers into an enum "namespace" so that they don't pollute the global namespace. https://bugs.swift.org/browse/SR-1966
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment