Skip to content

Latest commit

 

History

History
100 lines (63 loc) · 6.55 KB

0089-rename-string-reflection-init.md

File metadata and controls

100 lines (63 loc) · 6.55 KB
Raw

Renaming String.init<T>(_: T)

Introduction

Swift's String type ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined as init<T>(_: T), is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.

Discussion threads: pre-proposal part 1, pre-proposal part 2, review thread, post-review thread

Motivation

String ships with a number of initializers which take a single unlabeled argument. These include non-failable initializers which create a String out of a Character, NSString, CharacterView, or UnicodeScalarView, initializers which build a string out of a number, and failable initializers which take a UTF8View or a UTF16View.

There are at least two possible situations in which a user may write incorrect code which nevertheless compiles successfully:

  • The user means to call one of the non-failable initializers besides the init<T>(_: T) initializer, but passes in an argument of incorrect type.
  • The user means to call one of the failable initializers, but accidentally assigns the created object to a value of non-nullable type.

In both cases the compiler silently infers the use of the init<T>(_: T) initializer in lieu of the desired initializer. This may result in code which inadvertently utilizes the expensive reflection machinery and/or produces an unintentionally lossy representation of the value.

Proposed solution

A proposed solution to this problem follows:

  • The current reflection-based String.init<T>(_: T) initializer will be renamed to String.init<T>(describing: T). This initializer will rarely be invoked directly by user code.

  • A new protocol will be introduced: LosslessStringConvertible, which refines/narrows CustomStringConvertible. This protocol will be defined as follows:

     protocol LosslessStringConvertible : CustomStringConvertible {
 	/// Instantiate an instance of the conforming type from a string representation.
 	init?(_ description: String)
 }

    Values of types that conform to LosslessStringConvertible are capable of being represented in a lossless, unambiguous manner as a string. For example, the integer value 1050 can be represented in its entirety as the string "1050". The description property for such a type must be a value-preserving representation of the original value. As such, it should be possible to attempt to create an instance of a LosslessStringConvertible conforming type from a string representation.

    A possible alternate name for this protocol is ValuePreservingStringLiteral. The core team may wish to choose this name instead, or another name that better describes the protocol's contract.

  • A new String initializer will be introduced: init<T: LosslessStringConvertible>(_ v: T) { self = v.description }. This allows the String(x) syntax to continue to be used on all values of types that can be converted to a string in a value-preserving way.

  • As a performance optimization, the implementation of the string literal interpolation syntax will be changed to prefer the unlabeled initializer when interpolating a type that is LosslessStringConvertible or that otherwise has an unlabeled String initializer, but use the String.init<T>(describing: T) initializer if not.

Standard library types to conform

The following standard library types and protocols should be changed to conform to LosslessStringConvertible.

Protocols

  • FloatingPoint: "FP types should be able to conform. There are algorithms that are guaranteed to turn IEEE floating point values into a decimal representation in a reversible way. I don’t think we care about NaN payloads, but an encoding could be created for them as well." (Chris Lattner)
  • Integer

Types

  • Bool: either "true" or "false", since these are their canonical representations.
  • Character
  • UnicodeScalar
  • String
  • String.UTF8View
  • String.UTF16View
  • String.CharacterView
  • String.UnicodeScalarView
  • StaticString

Future directions

Additional conformances to LosslessStringLiteral

Once conditional conformance of generic types to protocols is implemented, the additional protocols and types below are candidates for conformance to LosslessStringLiteral:

Protocols

  • RangeReplaceableCollection where Iterator.Element == Character
  • RangeReplaceableCollection where Iterator.Element == UnicodeScalar
  • SetAlgebra where Iterator.Element == Character
  • SetAlgebra where Iterator.Element == UnicodeScalar

Types

  • ClosedRange where Bound : LosslessStringConvertible
  • CountableClosedRange where Bound : LosslessStringConvertible
  • CountableRange where Bound : LosslessStringConvertible
  • Range where Bound : LosslessStringConvertible

Impact on existing code

This API change may impact existing code.

Code which intends to invoke init<T>(_: T) will need to be modified so that the proper initializer is called. In addition, it is possible that this change may uncover instances of the erroneous behavior described previously.

Alternatives considered

One alternative solution might be to make LosslessStringConvertible a separate protocol altogether from CustomStringConvertible and CustomDebugStringConvertible. Arguments for and against that approach can be found in this earlier version of this proposal.