Showing preview only (9,932K chars total). Download the full file or copy to clipboard to get everything.
Repository: swiftlang/swift-evolution
Branch: main
Commit: dc4fb1737b23
Files: 571
Total size: 9.4 MB
Directory structure:
gitextract_f7lua7kp/
├── .gitattributes
├── .gitignore
├── .nojekyll
├── 404.html
├── CONTRIBUTING.md
├── LICENSE.txt
├── README.md
├── commonly_proposed.md
├── policies/
│ ├── 0001-platform-support-tiers.md
│ └── templates/
│ └── xxxx-policy-template.md
├── process.md
├── proposal-templates/
│ ├── 0000-swift-template.md
│ ├── 0000-swift-testing-template.md
│ └── 0000-swiftpm-template.md
├── proposals/
│ ├── 0001-keywords-as-argument-labels.md
│ ├── 0002-remove-currying.md
│ ├── 0003-remove-var-parameters.md
│ ├── 0004-remove-pre-post-inc-decrement.md
│ ├── 0005-objective-c-name-translation.md
│ ├── 0006-apply-api-guidelines-to-the-standard-library.md
│ ├── 0007-remove-c-style-for-loops.md
│ ├── 0008-lazy-flatmap-for-optionals.md
│ ├── 0009-require-self-for-accessing-instance-members.md
│ ├── 0010-add-staticstring-unicodescalarview.md
│ ├── 0011-replace-typealias-associated.md
│ ├── 0012-add-noescape-to-public-library-api.md
│ ├── 0013-remove-partial-application-super.md
│ ├── 0014-constrained-AnySequence.md
│ ├── 0015-tuple-comparison-operators.md
│ ├── 0016-initializers-for-converting-unsafe-pointers-to-ints.md
│ ├── 0017-convert-unmanaged-to-use-unsafepointer.md
│ ├── 0018-flexible-memberwise-initialization.md
│ ├── 0019-package-manager-testing.md
│ ├── 0020-if-swift-version.md
│ ├── 0021-generalized-naming.md
│ ├── 0022-objc-selectors.md
│ ├── 0023-api-guidelines.md
│ ├── 0024-optional-value-setter.md
│ ├── 0025-scoped-access-level.md
│ ├── 0026-abstract-classes-and-methods.md
│ ├── 0027-string-from-code-units.md
│ ├── 0028-modernizing-debug-identifiers.md
│ ├── 0029-remove-implicit-tuple-splat.md
│ ├── 0030-property-behavior-decls.md
│ ├── 0031-adjusting-inout-declarations.md
│ ├── 0032-sequencetype-find.md
│ ├── 0033-import-objc-constants.md
│ ├── 0034-disambiguating-line.md
│ ├── 0035-limit-inout-capture.md
│ ├── 0036-enum-dot.md
│ ├── 0037-clarify-comments-and-operators.md
│ ├── 0038-swiftpm-c-language-targets.md
│ ├── 0039-playgroundliterals.md
│ ├── 0040-attributecolons.md
│ ├── 0041-conversion-protocol-conventions.md
│ ├── 0042-flatten-method-types.md
│ ├── 0043-declare-variables-in-case-labels-with-multiple-patterns.md
│ ├── 0044-import-as-member.md
│ ├── 0045-scan-takewhile-dropwhile.md
│ ├── 0046-first-label.md
│ ├── 0047-nonvoid-warn.md
│ ├── 0048-generic-typealias.md
│ ├── 0049-noescape-autoclosure-type-attrs.md
│ ├── 0050-floating-point-stride.md
│ ├── 0051-stride-semantics.md
│ ├── 0052-iterator-post-nil-guarantee.md
│ ├── 0053-remove-let-from-function-parameters.md
│ ├── 0054-abolish-iuo.md
│ ├── 0055-optional-unsafe-pointers.md
│ ├── 0056-trailing-closures-in-guard.md
│ ├── 0057-importing-objc-generics.md
│ ├── 0058-objectivecbridgeable.md
│ ├── 0059-updated-set-apis.md
│ ├── 0060-defaulted-parameter-order.md
│ ├── 0061-autoreleasepool-signature.md
│ ├── 0062-objc-keypaths.md
│ ├── 0063-swiftpm-system-module-search-paths.md
│ ├── 0064-property-selectors.md
│ ├── 0065-collections-move-indices.md
│ ├── 0066-standardize-function-type-syntax.md
│ ├── 0067-floating-point-protocols.md
│ ├── 0068-universal-self.md
│ ├── 0069-swift-mutability-for-foundation.md
│ ├── 0070-optional-requirements.md
│ ├── 0071-member-keywords.md
│ ├── 0072-eliminate-implicit-bridging-conversions.md
│ ├── 0073-noescape-once.md
│ ├── 0074-binary-search.md
│ ├── 0075-import-test.md
│ ├── 0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md
│ ├── 0077-operator-precedence.md
│ ├── 0078-rotate-algorithm.md
│ ├── 0079-upgrade-self-from-weak-to-strong.md
│ ├── 0080-failable-numeric-initializers.md
│ ├── 0081-move-where-expression.md
│ ├── 0082-swiftpm-package-edit.md
│ ├── 0083-remove-bridging-from-dynamic-casts.md
│ ├── 0084-trailing-commas.md
│ ├── 0085-package-manager-command-name.md
│ ├── 0086-drop-foundation-ns.md
│ ├── 0087-lazy-attribute.md
│ ├── 0088-libdispatch-for-swift3.md
│ ├── 0089-rename-string-reflection-init.md
│ ├── 0090-remove-dot-self.md
│ ├── 0091-improving-operators-in-protocols.md
│ ├── 0092-typealiases-in-protocols.md
│ ├── 0093-slice-base.md
│ ├── 0094-sequence-function.md
│ ├── 0095-any-as-existential.md
│ ├── 0096-dynamictype.md
│ ├── 0097-negative-attributes.md
│ ├── 0098-didset-capitalization.md
│ ├── 0099-conditionclauses.md
│ ├── 0100-add-sequence-based-init-and-merge-to-dictionary.md
│ ├── 0101-standardizing-sizeof-naming.md
│ ├── 0102-noreturn-bottom-type.md
│ ├── 0103-make-noescape-default.md
│ ├── 0104-improved-integers.md
│ ├── 0105-remove-where-from-forin-loops.md
│ ├── 0106-rename-osx-to-macos.md
│ ├── 0107-unsaferawpointer.md
│ ├── 0108-remove-assoctype-inference.md
│ ├── 0109-remove-boolean.md
│ ├── 0110-distinguish-single-tuple-arg.md
│ ├── 0111-remove-arg-label-type-significance.md
│ ├── 0112-nserror-bridging.md
│ ├── 0113-rounding-functions-on-floatingpoint.md
│ ├── 0114-buffer-naming.md
│ ├── 0115-literal-syntax-protocols.md
│ ├── 0116-id-as-any.md
│ ├── 0117-non-public-subclassable-by-default.md
│ ├── 0118-closure-parameter-names-and-labels.md
│ ├── 0119-extensions-access-modifiers.md
│ ├── 0120-revise-partition-method.md
│ ├── 0121-remove-optional-comparison-operators.md
│ ├── 0122-use-colons-for-subscript-type-declarations.md
│ ├── 0123-disallow-value-to-optional-coercion-in-operator-arguments.md
│ ├── 0124-bitpattern-label-for-int-initializer-objectidentfier.md
│ ├── 0125-remove-nonobjectivecbase.md
│ ├── 0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md
│ ├── 0127-cleaning-up-stdlib-ptr-buffer.md
│ ├── 0128-unicodescalar-failable-initializer.md
│ ├── 0129-package-manager-test-naming-conventions.md
│ ├── 0130-string-initializers-cleanup.md
│ ├── 0131-anyhashable.md
│ ├── 0132-sequence-end-ops.md
│ ├── 0133-rename-flatten-to-joined.md
│ ├── 0134-rename-string-properties.md
│ ├── 0135-package-manager-support-for-differentiating-packages-by-swift-version.md
│ ├── 0136-memory-layout-of-values.md
│ ├── 0137-avoiding-lock-in.md
│ ├── 0138-unsaferawbufferpointer.md
│ ├── 0139-bridge-nsnumber-and-nsvalue.md
│ ├── 0140-bridge-optional-to-nsnull.md
│ ├── 0141-available-by-swift-version.md
│ ├── 0142-associated-types-constraints.md
│ ├── 0143-conditional-conformances.md
│ ├── 0144-allow-single-dollar-sign-as-valid-identifier.md
│ ├── 0145-package-manager-version-pinning.md
│ ├── 0146-package-manager-product-definitions.md
│ ├── 0147-move-unsafe-initialize-from.md
│ ├── 0148-generic-subscripts.md
│ ├── 0149-package-manager-top-of-tree.md
│ ├── 0150-package-manager-branch-support.md
│ ├── 0151-package-manager-swift-language-compatibility-version.md
│ ├── 0152-package-manager-tools-version.md
│ ├── 0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
│ ├── 0154-dictionary-key-and-value-collections.md
│ ├── 0155-normalize-enum-case-representation.md
│ ├── 0156-subclass-existentials.md
│ ├── 0157-recursive-protocol-constraints.md
│ ├── 0158-package-manager-manifest-api-redesign.md
│ ├── 0159-fix-private-access-levels.md
│ ├── 0160-objc-inference.md
│ ├── 0161-key-paths.md
│ ├── 0162-package-manager-custom-target-layouts.md
│ ├── 0163-string-revision-1.md
│ ├── 0164-remove-final-support-in-protocol-extensions.md
│ ├── 0165-dict.md
│ ├── 0166-swift-archival-serialization.md
│ ├── 0167-swift-encoders.md
│ ├── 0168-multi-line-string-literals.md
│ ├── 0169-improve-interaction-between-private-declarations-and-extensions.md
│ ├── 0170-nsnumber_bridge.md
│ ├── 0171-reduce-with-inout.md
│ ├── 0172-one-sided-ranges.md
│ ├── 0173-swap-indices.md
│ ├── 0174-filter-range-replaceable.md
│ ├── 0175-package-manager-revised-dependency-resolution.md
│ ├── 0176-enforce-exclusive-access-to-memory.md
│ ├── 0177-add-clamped-to-method.md
│ ├── 0178-character-unicode-view.md
│ ├── 0179-swift-run-command.md
│ ├── 0180-string-index-overhaul.md
│ ├── 0181-package-manager-cpp-language-version.md
│ ├── 0182-newline-escape-in-strings.md
│ ├── 0183-substring-affordances.md
│ ├── 0184-unsafe-pointers-add-missing.md
│ ├── 0185-synthesize-equatable-hashable.md
│ ├── 0186-remove-ownership-keyword-support-in-protocols.md
│ ├── 0187-introduce-filtermap.md
│ ├── 0188-stdlib-index-types-hashable.md
│ ├── 0189-restrict-cross-module-struct-initializers.md
│ ├── 0190-target-environment-platform-condition.md
│ ├── 0191-eliminate-indexdistance.md
│ ├── 0192-non-exhaustive-enums.md
│ ├── 0193-cross-module-inlining-and-specialization.md
│ ├── 0194-derived-collection-of-enum-cases.md
│ ├── 0195-dynamic-member-lookup.md
│ ├── 0196-diagnostic-directives.md
│ ├── 0197-remove-where.md
│ ├── 0198-playground-quicklook-api-revamp.md
│ ├── 0199-bool-toggle.md
│ ├── 0200-raw-string-escaping.md
│ ├── 0201-package-manager-local-dependencies.md
│ ├── 0202-random-unification.md
│ ├── 0203-rename-sequence-elements-equal.md
│ ├── 0204-add-last-methods.md
│ ├── 0205-withUnsafePointer-for-lets.md
│ ├── 0206-hashable-enhancements.md
│ ├── 0207-containsOnly.md
│ ├── 0208-package-manager-system-library-targets.md
│ ├── 0209-package-manager-swift-lang-version-update.md
│ ├── 0210-key-path-offset.md
│ ├── 0211-unicode-scalar-properties.md
│ ├── 0212-compiler-version-directive.md
│ ├── 0213-literal-init-via-coercion.md
│ ├── 0214-DictionaryLiteral.md
│ ├── 0215-conform-never-to-hashable-and-equatable.md
│ ├── 0216-dynamic-callable.md
│ ├── 0217-bangbang.md
│ ├── 0218-introduce-compact-map-values.md
│ ├── 0219-package-manager-dependency-mirroring.md
│ ├── 0220-count-where.md
│ ├── 0221-character-properties.md
│ ├── 0222-lazy-compactmap-sequence.md
│ ├── 0223-array-uninitialized-initializer.md
│ ├── 0224-ifswift-lessthan-operator.md
│ ├── 0225-binaryinteger-iseven-isodd-ismultiple.md
│ ├── 0226-package-manager-target-based-dep-resolution.md
│ ├── 0227-identity-keypath.md
│ ├── 0228-fix-expressiblebystringinterpolation.md
│ ├── 0229-simd.md
│ ├── 0230-flatten-optional-try.md
│ ├── 0231-optional-iteration.md
│ ├── 0232-remove-customization-points.md
│ ├── 0233-additive-arithmetic-protocol.md
│ ├── 0234-remove-sequence-subsequence.md
│ ├── 0235-add-result.md
│ ├── 0236-package-manager-platform-deployment-settings.md
│ ├── 0237-contiguous-collection.md
│ ├── 0238-package-manager-build-settings.md
│ ├── 0239-codable-range.md
│ ├── 0240-ordered-collection-diffing.md
│ ├── 0241-string-index-explicit-encoding-offset.md
│ ├── 0242-default-values-memberwise.md
│ ├── 0243-codepoint-and-character-literals.md
│ ├── 0244-opaque-result-types.md
│ ├── 0245-array-uninitialized-initializer.md
│ ├── 0246-mathable.md
│ ├── 0247-contiguous-strings.md
│ ├── 0248-string-gaps-missing-apis.md
│ ├── 0249-key-path-literal-function-expressions.md
│ ├── 0250-swift-style-guide-and-formatter.md
│ ├── 0251-simd-additions.md
│ ├── 0252-keypath-dynamic-member-lookup.md
│ ├── 0253-callable.md
│ ├── 0254-static-subscripts.md
│ ├── 0255-omit-return.md
│ ├── 0256-contiguous-collection.md
│ ├── 0257-elide-comma.md
│ ├── 0258-property-wrappers.md
│ ├── 0259-approximately-equal.md
│ ├── 0260-library-evolution.md
│ ├── 0261-identifiable.md
│ ├── 0262-demangle.md
│ ├── 0263-string-uninitialized-initializer.md
│ ├── 0264-stdlib-preview-package.md
│ ├── 0265-offset-indexing-and-slicing.md
│ ├── 0266-synthesized-comparable-for-enumerations.md
│ ├── 0267-where-on-contextually-generic.md
│ ├── 0268-didset-semantics.md
│ ├── 0269-implicit-self-explicit-capture.md
│ ├── 0270-rangeset-and-collection-operations.md
│ ├── 0271-package-manager-resources.md
│ ├── 0272-swiftpm-binary-dependencies.md
│ ├── 0273-swiftpm-conditional-target-dependencies.md
│ ├── 0274-magic-file.md
│ ├── 0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md
│ ├── 0276-multi-pattern-catch-clauses.md
│ ├── 0277-float16.md
│ ├── 0278-package-manager-localized-resources.md
│ ├── 0279-multiple-trailing-closures.md
│ ├── 0280-enum-cases-as-protocol-witnesses.md
│ ├── 0281-main-attribute.md
│ ├── 0282-atomics.md
│ ├── 0283-tuples-are-equatable-comparable-hashable.md
│ ├── 0284-multiple-variadic-parameters.md
│ ├── 0285-ease-pound-file-transition.md
│ ├── 0286-forward-scan-trailing-closures.md
│ ├── 0287-implicit-member-chains.md
│ ├── 0288-binaryinteger-ispower.md
│ ├── 0289-result-builders.md
│ ├── 0290-negative-availability.md
│ ├── 0291-package-collections.md
│ ├── 0292-package-registry-service.md
│ ├── 0293-extend-property-wrappers-to-function-and-closure-parameters.md
│ ├── 0294-package-executable-targets.md
│ ├── 0295-codable-synthesis-for-enums-with-associated-values.md
│ ├── 0296-async-await.md
│ ├── 0297-concurrency-objc.md
│ ├── 0298-asyncsequence.md
│ ├── 0299-extend-generic-static-member-lookup.md
│ ├── 0300-continuation.md
│ ├── 0301-package-editing-commands.md
│ ├── 0302-concurrent-value-and-concurrent-closures.md
│ ├── 0303-swiftpm-extensible-build-tools.md
│ ├── 0304-structured-concurrency.md
│ ├── 0305-swiftpm-binary-target-improvements.md
│ ├── 0306-actors.md
│ ├── 0307-allow-interchangeable-use-of-double-cgfloat-types.md
│ ├── 0308-postfix-if-config-expressions.md
│ ├── 0309-unlock-existential-types-for-all-protocols.md
│ ├── 0310-effectful-readonly-properties.md
│ ├── 0311-task-locals.md
│ ├── 0312-indexed-and-enumerated-zip-collections.md
│ ├── 0313-actor-isolation-control.md
│ ├── 0314-async-stream.md
│ ├── 0315-placeholder-types.md
│ ├── 0316-global-actors.md
│ ├── 0317-async-let.md
│ ├── 0318-package-creation.md
│ ├── 0319-never-identifiable.md
│ ├── 0320-codingkeyrepresentable.md
│ ├── 0321-package-registry-publish.md
│ ├── 0322-temporary-buffers.md
│ ├── 0323-async-main-semantics.md
│ ├── 0324-c-lang-pointer-arg-conversion.md
│ ├── 0325-swiftpm-additional-plugin-apis.md
│ ├── 0326-extending-multi-statement-closure-inference.md
│ ├── 0327-actor-initializers.md
│ ├── 0328-structural-opaque-result-types.md
│ ├── 0329-clock-instant-duration.md
│ ├── 0330-collection-conditionals.md
│ ├── 0331-remove-sendable-from-unsafepointer.md
│ ├── 0332-swiftpm-command-plugins.md
│ ├── 0333-with-memory-rebound.md
│ ├── 0334-pointer-usability-improvements.md
│ ├── 0335-existential-any.md
│ ├── 0336-distributed-actor-isolation.md
│ ├── 0337-support-incremental-migration-to-concurrency-checking.md
│ ├── 0338-clarify-execution-non-actor-async.md
│ ├── 0339-module-aliasing-for-disambiguation.md
│ ├── 0340-swift-noasync.md
│ ├── 0341-opaque-parameters.md
│ ├── 0342-static-link-runtime-libraries-by-default-on-supported-platforms.md
│ ├── 0343-top-level-concurrency.md
│ ├── 0344-distributed-actor-runtime.md
│ ├── 0345-if-let-shorthand.md
│ ├── 0346-light-weight-same-type-syntax.md
│ ├── 0347-type-inference-from-default-exprs.md
│ ├── 0348-buildpartialblock.md
│ ├── 0349-unaligned-loads-and-stores.md
│ ├── 0350-regex-type-overview.md
│ ├── 0351-regex-builder.md
│ ├── 0352-implicit-open-existentials.md
│ ├── 0353-constrained-existential-types.md
│ ├── 0354-regex-literals.md
│ ├── 0355-regex-syntax-run-time-construction.md
│ ├── 0356-swift-snippets.md
│ ├── 0357-regex-string-processing-algorithms.md
│ ├── 0358-primary-associated-types-in-stdlib.md
│ ├── 0359-build-time-constant-values.md
│ ├── 0360-opaque-result-types-with-availability.md
│ ├── 0361-bound-generic-extensions.md
│ ├── 0362-piecemeal-future-features.md
│ ├── 0363-unicode-for-string-processing.md
│ ├── 0364-retroactive-conformance-warning.md
│ ├── 0365-implicit-self-weak-capture.md
│ ├── 0366-move-function.md
│ ├── 0367-conditional-attributes.md
│ ├── 0368-staticbigint.md
│ ├── 0369-add-customdebugdescription-conformance-to-anykeypath.md
│ ├── 0370-pointer-family-initialization-improvements.md
│ ├── 0371-isolated-synchronous-deinit.md
│ ├── 0372-document-sorting-as-stable.md
│ ├── 0373-vars-without-limits-in-result-builders.md
│ ├── 0374-clock-sleep-for.md
│ ├── 0375-opening-existential-optional.md
│ ├── 0376-function-back-deployment.md
│ ├── 0377-parameter-ownership-modifiers.md
│ ├── 0378-package-registry-auth.md
│ ├── 0379-opt-in-reflection-metadata.md
│ ├── 0380-if-switch-expressions.md
│ ├── 0381-task-group-discard-results.md
│ ├── 0382-expression-macros.md
│ ├── 0383-deprecate-uiapplicationmain-and-nsapplicationmain.md
│ ├── 0384-importing-forward-declared-objc-interfaces-and-protocols.md
│ ├── 0385-custom-reflection-metadata.md
│ ├── 0386-package-access-modifier.md
│ ├── 0387-cross-compilation-destinations.md
│ ├── 0388-async-stream-factory.md
│ ├── 0389-attached-macros.md
│ ├── 0390-noncopyable-structs-and-enums.md
│ ├── 0391-package-registry-publish.md
│ ├── 0392-custom-actor-executors.md
│ ├── 0393-parameter-packs.md
│ ├── 0394-swiftpm-expression-macros.md
│ ├── 0395-observability.md
│ ├── 0396-never-codable.md
│ ├── 0397-freestanding-declaration-macros.md
│ ├── 0398-variadic-types.md
│ ├── 0399-tuple-of-value-pack-expansion.md
│ ├── 0400-init-accessors.md
│ ├── 0401-remove-property-wrapper-isolation.md
│ ├── 0402-extension-macros.md
│ ├── 0403-swiftpm-mixed-language-targets.md
│ ├── 0404-nested-protocols.md
│ ├── 0405-string-validating-initializers.md
│ ├── 0406-async-stream-backpressure.md
│ ├── 0407-member-macro-conformances.md
│ ├── 0408-pack-iteration.md
│ ├── 0409-access-level-on-imports.md
│ ├── 0410-atomics.md
│ ├── 0411-isolated-default-values.md
│ ├── 0412-strict-concurrency-for-global-variables.md
│ ├── 0413-typed-throws.md
│ ├── 0414-region-based-isolation.md
│ ├── 0415-function-body-macros.md
│ ├── 0416-keypath-function-subtyping.md
│ ├── 0417-task-executor-preference.md
│ ├── 0418-inferring-sendable-for-methods.md
│ ├── 0419-backtrace-api.md
│ ├── 0420-inheritance-of-actor-isolation.md
│ ├── 0421-generalize-async-sequence.md
│ ├── 0422-caller-side-default-argument-macro-expression.md
│ ├── 0423-dynamic-actor-isolation.md
│ ├── 0424-custom-isolation-checking-for-serialexecutor.md
│ ├── 0425-int128.md
│ ├── 0426-bitwise-copyable.md
│ ├── 0427-noncopyable-generics.md
│ ├── 0428-resolve-distributed-actor-protocols.md
│ ├── 0429-partial-consumption.md
│ ├── 0430-transferring-parameters-and-results.md
│ ├── 0431-isolated-any-functions.md
│ ├── 0432-noncopyable-switch.md
│ ├── 0433-mutex.md
│ ├── 0434-global-actor-isolated-types-usability.md
│ ├── 0435-swiftpm-per-target-swift-language-version-setting.md
│ ├── 0436-objc-implementation.md
│ ├── 0437-noncopyable-stdlib-primitives.md
│ ├── 0438-metatype-keypath.md
│ ├── 0439-trailing-comma-lists.md
│ ├── 0440-debug-description-macro.md
│ ├── 0441-formalize-language-mode-terminology.md
│ ├── 0442-allow-taskgroup-childtaskresult-type-to-be-inferred.md
│ ├── 0443-warning-control-flags.md
│ ├── 0444-member-import-visibility.md
│ ├── 0445-string-index-printing.md
│ ├── 0446-non-escapable.md
│ ├── 0447-span-access-shared-contiguous-storage.md
│ ├── 0448-regex-lookbehind-assertions.md
│ ├── 0449-nonisolated-for-global-actor-cutoff.md
│ ├── 0450-swiftpm-package-traits.md
│ ├── 0451-escaped-identifiers.md
│ ├── 0452-integer-generic-parameters.md
│ ├── 0453-vector.md
│ ├── 0454-memory-allocator.md
│ ├── 0455-swiftpm-testable-build-setting.md
│ ├── 0456-stdlib-span-properties.md
│ ├── 0457-duration-attosecond-represenation.md
│ ├── 0458-strict-memory-safety.md
│ ├── 0459-enumerated-collection.md
│ ├── 0460-specialized.md
│ ├── 0461-async-function-isolation.md
│ ├── 0462-task-priority-escalation-apis.md
│ ├── 0463-sendable-completion-handlers.md
│ ├── 0464-utf8span-safe-utf8-processing.md
│ ├── 0465-nonescapable-stdlib-primitives.md
│ ├── 0466-control-default-actor-isolation.md
│ ├── 0467-MutableSpan.md
│ ├── 0468-async-stream-continuation-hashable-conformance.md
│ ├── 0469-task-names.md
│ ├── 0470-isolated-conformances.md
│ ├── 0471-SerialExecutor-isIsolated.md
│ ├── 0471-is-isolated-flow.graffle
│ ├── 0472-task-start-synchronously-on-caller-context.md
│ ├── 0473-clock-epochs.md
│ ├── 0474-yielding-accessors.md
│ ├── 0475-observed.md
│ ├── 0476-abi-attr.md
│ ├── 0477-default-interpolation-values.md
│ ├── 0478-default-isolation-typealias.md
│ ├── 0479-method-and-initializer-keypaths.md
│ ├── 0480-swiftpm-warning-control.md
│ ├── 0481-weak-let.md
│ ├── 0482-swiftpm-static-library-binary-target-non-apple-platforms.md
│ ├── 0483-inline-array-sugar.md
│ ├── 0484-allow-additional-args-to-dynamicmemberlookup-subscripts.md
│ ├── 0485-outputspan.md
│ ├── 0486-adoption-tooling-for-swift-features.md
│ ├── 0487-extensible-enums.md
│ ├── 0488-extracting.md
│ ├── 0489-codable-error-printing.md
│ ├── 0490-environment-constrained-shared-libraries.md
│ ├── 0491-module-selectors.md
│ ├── 0492-section-control.md
│ ├── 0493-defer-async.md
│ ├── 0494-add-is-identical-methods.md
│ ├── 0495-cdecl.md
│ ├── 0496-inline-always.md
│ ├── 0497-definition-visibility.md
│ ├── 0498-runtime-demangle.md
│ ├── 0499-support-non-copyable-simple-protocols.md
│ ├── 0500-package-manager-templates.md
│ ├── 0501-swiftpm-html-coverage-report.md
│ ├── 0502-exclude-private-from-memberwise-init.md
│ ├── 0503-suppressed-associated-types.md
│ ├── 0504-task-cancellation-shields.md
│ ├── 0505-delayed-enqueuing.md
│ ├── 0506-advanced-observation-tracking.md
│ ├── 0507-borrow-accessors.md
│ ├── 0508-array-expression-trailing-closures.md
│ ├── 0509-swift-sboms-via-swiftpm.md
│ ├── 0510-dictionary-mapvalues-with-keys.md
│ ├── 0511-swiftpm-add-target-plugin.md
│ ├── 0512-withlockifavailable-cannot-spuriously-fail.md
│ ├── 0513-commandline-executablepath.md
│ ├── 0514-hashable-conformance-for-dictionarykeys-collectionofone-emptycollection.md
│ ├── 0515-noncopyable-reduce.md
│ ├── 0516-borrowing-sequence.md
│ ├── 0517-uniquebox.md
│ ├── 0518-tilde-sendable.md
│ ├── 0519-borrow-inout-types.md
│ ├── 0520-discardableresult-task-initializers.md
│ ├── 0521-improved-optional-opaque-and-any.md
│ ├── 0522-source-warning-control.md
│ └── testing/
│ ├── 0001-refactor-bug-inits.md
│ ├── 0002-json-abi.md
│ ├── 0003-make-serialized-trait-api.md
│ ├── 0004-constrain-the-granularity-of-test-time-limit-durations.md
│ ├── 0005-ranged-confirmations.md
│ ├── 0006-return-errors-from-expect-throws.md
│ ├── 0007-test-scoping-traits.md
│ ├── 0008-exit-tests.md
│ ├── 0009-attachments.md
│ ├── 0010-evaluate-condition.md
│ ├── 0011-issue-handling-traits.md
│ ├── 0012-exit-test-value-capturing.md
│ ├── 0013-issue-severity-warning.md
│ ├── 0014-image-attachments-in-swift-testing-apple-platforms.md
│ ├── 0015-image-attachments-in-swift-testing-windows.md
│ ├── 0016-test-cancellation.md
│ ├── 0017-image-attachment-consolidation.md
│ ├── 0018-conditionally-saving-attachments.md
│ ├── 0019-include-tags-bugs-and-timeline-in-event-stream.md
│ ├── 0020-sourcelocation-filepath.md
│ └── 0021-targeted-interoperability-swift-testing-and-xctest.md
├── releases/
│ ├── swift-2_2.md
│ ├── swift-3_0.md
│ ├── swift-4_0.md
│ └── swift-5_0.md
└── visions/
├── approachable-concurrency.md
├── embedded-swift.md
├── macros.md
├── memory-safety.md
├── networking.md
├── swift-testing.md
├── using-c++-from-swift.md
├── using-swift-from-c++.md
└── webassembly.md
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitattributes
================================================
*.md linguist-detectable=true
*.md linguist-documentation=false
================================================
FILE: .gitignore
================================================
# Temporary files.
*~
# Xcode user data.
xcuserdata
# Finder metadata
.DS_Store
# Built site content.
/_site
================================================
FILE: .nojekyll
================================================
================================================
FILE: 404.html
================================================
<!DOCTYPE html>
<meta charset="utf-8">
<noscript>
<meta http-equiv="Refresh" content="0; URL=https://www.swift.org/swift-evolution/">
</noscript>
<script>
location.replace('https://www.swift.org/swift-evolution/' + location.hash)
</script>
<title>Swift Evolution</title>
================================================
FILE: CONTRIBUTING.md
================================================
# Welcome to the Swift community!
Contributions to Swift are welcomed and encouraged! Please see the [Contributing to Swift guide](https://www.swift.org/contributing/) and check out the [structure of the community](https://www.swift.org/community/#community-structure).
To be a truly great community, Swift needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.
To give clarity of what is expected of our members, Swift has adopted the code of conduct defined by the Contributor Covenant. This document is used across many open source communities, and we think it articulates our values well. For more, see the [Code of Conduct](https://www.swift.org/code-of-conduct/).
## Contributing to Swift Evolution
This repository is not your standard codebase. It houses Swift evolution proposals and related process documents, mostly composed of markdown and text files. Pull requests that make minor editorial and administrative changes are always welcome, including fixing typos and grammar mistakes, repairing links, and maintaining document and repository metadata. Other pull requests must follow the [Swift evolution process](process.md):
- New proposals and substantive changes to existing proposals should be [pitched on the evolution forums](https://forums.swift.org/c/evolution/pitches/5) before a PR is opened here.
- Substantive changes to existing proposals require the permission of the proposal authors.
- Substantive changes to existing proposals require the approval of the appropriate evolution workgroup if the proposal is in an Active Review, Accepted, or Rejected state.
- New vision documents and substantive changes to existing vision documents require the approval of the appropriate evolution workgroup.
- Substantive changes to the evolution process require the approval of the Core Team.
- Conversations about the substance of a proposal should be held in an appropriate forums thread rather than in PR comments. This centralizes the discussion and allows more of the community to participate.
================================================
FILE: LICENSE.txt
================================================
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
## Runtime Library Exception to the Apache 2.0 License: ##
As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result,
you may redistribute such product without providing attribution as would
otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.
================================================
FILE: README.md
================================================
# Swift Evolution
<https://www.swift.org/swift-evolution/>
This repository tracks the ongoing evolution of the Swift programming language, standard library, and package manager.
## Goals and Release Notes
* [Swift Language focus areas heading into 2025](https://forums.swift.org/t/swift-language-focus-areas-heading-into-2025/76611)
* [CHANGELOG](https://github.com/apple/swift/blob/main/CHANGELOG.md)
| Version | Announced | Released |
| :-------- | :----------------------------------------------------------------------- | :----------------------------------------------------------- |
| Swift 6.3 | [2025-10-24](https://forums.swift.org/t/swift-6-3-release-process/82843) | |
| Swift 6.2 | [2025-03-08](https://forums.swift.org/t/swift-6-2-release-process/78371) | [2025-09-15](https://www.swift.org/blog/swift-6.2-released/) |
| Swift 6.1 | [2024-10-17](https://forums.swift.org/t/swift-6-1-release-process/75442) | [2025-03-31](https://www.swift.org/blog/swift-6.1-released/) |
| Swift 6.0 | [2024-02-22](https://forums.swift.org/t/swift-6-0-release-process/70220) | [2024-09-17](https://www.swift.org/blog/announcing-swift-6/) |
| Swift 5.10 | [2023-08-23](https://forums.swift.org/t/swift-5-10-release-process/66911) | [2024-03-05](https://www.swift.org/blog/swift-5.10-released/) |
| Swift 5.9 | [2023-03-06](https://forums.swift.org/t/swift-5-9-release-process/63557) | [2023-09-18](https://www.swift.org/blog/swift-5.9-released/) |
| Swift 5.8 | [2022-11-19](https://forums.swift.org/t/swift-5-8-release-process/61540) | [2023-03-30](https://www.swift.org/blog/swift-5.8-released/) |
| Swift 5.7 | [2022-03-29](https://forums.swift.org/t/swift-5-7-release-process/56316) | [2022-09-12](https://www.swift.org/blog/swift-5.7-released/) |
| Swift 5.6 | [2021-11-10](https://forums.swift.org/t/swift-5-6-release-process/53412) | [2022-03-14](https://www.swift.org/blog/swift-5.6-released/) |
| Swift 5.5 | [2021-03-12](https://forums.swift.org/t/swift-5-5-release-process/45644) | [2021-09-20](https://www.swift.org/blog/swift-5.5-released/) |
| Swift 5.4 | [2020-11-11](https://forums.swift.org/t/swift-5-4-release-process/41936) | [2021-04-26](https://www.swift.org/blog/swift-5.4-released/) |
| Swift 5.3 | [2020-03-25](https://www.swift.org/blog/5.3-release-process/) | [2020-09-16](https://www.swift.org/blog/swift-5.3-released/) |
| Swift 5.2 | [2019-09-24](https://www.swift.org/blog/5.2-release-process/) | [2020-03-24](https://www.swift.org/blog/swift-5.2-released/) |
| Swift 5.1 | [2019-02-18](https://www.swift.org/blog/5.1-release-process/) | [2019-09-20](https://www.swift.org/blog/swift-5.1-released/) |
| Swift 5.0 | [2018-09-25](https://www.swift.org/blog/5.0-release-process/) | [2019-03-25](https://www.swift.org/blog/swift-5-released/) |
| Swift 4.2 | [2018-02-28](https://www.swift.org/blog/4.2-release-process/) | [2018-09-17](https://www.swift.org/blog/swift-4.2-released/) |
| Swift 4.1 | [2017-10-17](https://www.swift.org/blog/swift-4.1-release-process/) | [2018-03-29](https://www.swift.org/blog/swift-4.1-released/) |
| Swift 4.0 | [2017-02-16](https://www.swift.org/blog/swift-4.0-release-process/) | [2017-09-19](https://www.swift.org/blog/swift-4.0-released/) |
| Swift 3.1 | [2016-12-09](https://www.swift.org/blog/swift-3.1-release-process/) | [2017-03-27](https://www.swift.org/blog/swift-3.1-released/) |
| Swift 3.0 | [2016-05-06](https://www.swift.org/blog/swift-3.0-release-process/) | [2016-09-13](https://www.swift.org/blog/swift-3.0-released/) |
| Swift 2.2 | [2016-01-05](https://www.swift.org/blog/swift-2.2-release-process/) | [2016-03-21](https://www.swift.org/blog/swift-2.2-released/) |
================================================
FILE: commonly_proposed.md
================================================
# Commonly Rejected Changes
This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted. If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had. In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".
Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.
Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and JavaScript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).
## Basic Syntax and Operators
* [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.
* [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature. Semicolons at the end of the line should be handled by a linter, not by the compiler.
* [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported. Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports. This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.
* [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values. Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.
## Strings, Characters, and Collection Types
* Change `Array<T>` subscript access to return `T?` or `T!` instead of `T`: The current array behavior is [intentional](https://forums.swift.org/t/proposal-add-safe-subquence-access-via-subscript-for-colloctiontype/516/7), as it accurately reflects the fact that out-of-bounds array access is a logic error. Changing the current behavior would slow `Array` accesses to an unacceptable degree. Changing the unlabeled array subscript to return an optional has come up [multiple](https://forums.swift.org/t/proposal-add-safe-subquence-access-via-subscript-for-colloctiontype/516/5) times before and is very unlikely to be accepted.
## Control Flow, Closures, Optional Binding, and Error Handling
* [Replace `continue` keyword with synonyms from other scripting languages (e.g. next, skip, advance, etc)](https://forums.swift.org/t/replace-continue-keyword/764/2): Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal.
* [Remove support for `default:` in `switch` and just use `case _:`](https://forums.swift.org/t/remove-default-case-in-switch-case/360/4): `default` is widely used, `case _` is too magical, and `default` is widely precedented in many C family languages.
* [Rename `guard` to `unless`](https://forums.swift.org/t/rename-guard-to-unless/934/7): It is a common request that `guard` be renamed `unless`. People requesting this change argue that `guard` is simply a logically inverted `if` statement, and therefore `unless` is a more obvious keyword. However, such requests stem from a fundamental misunderstanding of the functionality provided by `guard`. Unlike `if`, `guard` *enforces* that the code within its curly braces provides an early exit from the codepath. In other words, a `guard` block **must** `return`, `throw`, `break`, `continue` or call a function that does not return, such as `fatalError()`. This differs from `if` quite significantly, and therefore the parallels assumed between `guard` and `if` are not valid.
* [Infer `return` for omitted `guard` body](https://forums.swift.org/t/inferred-return-for-guard-statement/12099/11): It has been proposed many times to allow omission of the `guard` body for the sake of brevity. However, a core principle of Swift is to make control flow explicit and visible. For example, the `try` keyword exists solely to indicate to the human reader where thrown errors can happen. Implicit returns would violate this principle, favoring terseness over clarity in a way that isn't typical of Swift. Furthermore, there are many ways of exiting the scope other than `return` (loops may want `break` or `continue`), and not every function has an obvious default value to return.
* [Change closure literal syntax](https://forums.swift.org/t/streamlining-closures/487/3): Closure syntax in Swift has been carefully debated internally, and aspects of the design have strong motivations. It is unlikely that we'll find something better, and any proposals to change it should have a very detailed understanding of the Swift grammar.
* [Use pattern-matching in `if let` instead of optional-unwrapping](https://forums.swift.org/t/obsoleting-if-let/1301/4): We actually tried this and got a lot of negative feedback, for several reasons: (1) Most developers don't think about things in "pattern matching" terms, they think about "destructuring". (2) The vastly most common use case for `if let` is actually for optional matching, and this change made the common case more awkward. (3) This change increases the learning curve of Swift, changing pattern matching from being a concept that can be learned late to something that must be confronted early. (4) The current design of `if case` unifies "pattern matching" around the `case` keyword. (5) If a developer unfamiliar with `if case` runs into one in some code, they can successfully search for it in a search engine or Stack Overflow.
* [Remove or deprecate the force-unwrap operator `!`](https://forums.swift.org/t/moving-toward-deprecating-force-unwrap-from-swift/43455/82): Force-unwrap and force-try are legitimately useful parts of the language, and not just for source stability reasons. Therefore, proposals to deprecate or remove the force-unwrap operator (or `try!`), even in a mode enabled via compiler flag, will not be considered by the core team. Whether the Swift compiler should gain a more general "linting" capability to guide coding style remains a possible topic of discussion.
* [Replace the `do`/`try`/`repeat` keywords with C++-style syntax](https://forums.swift.org/t/use-standard-syntax-instead-of-do-and-repeat/791/2): Swift's error handling approach is carefully designed to make it obvious to maintainers of code when a call can "throw" an error. It is intentionally designed to be syntactically similar in some ways, but different in other key ways, to exception handling in other languages. Its design is a careful balance that favors maintainers of code that uses errors, to make sure someone reading the code understands what can throw. Before proposing a change to this system, please read the [Error Handling Rationale and Proposal](https://github.com/swiftlang/swift/blob/main/docs/ErrorHandlingRationale.md) in full to understand why the current design is the way it is, and be ready to explain why your changes would be worth unbalancing this design.
## Miscellaneous
* [Use garbage collection (GC) instead of automatic reference counting (ARC)](https://forums.swift.org/t/what-about-garbage-collection/1360): Mark-and-sweep garbage collection is a well-known technique used in many popular and widely used languages (e.g., Java and JavaScript) and it has the advantage of automatically collecting reference cycles that ARC requires the programmer to reason about. That said, garbage collection has a [large number of disadvantages](https://forums.swift.org/t/what-about-garbage-collection/1360/6) and using it would prevent Swift from successfully targeting a number of systems programming domains. For example, real-time systems (video or audio processing), deeply embedded controllers, and most kernels find GC to be generally unsuitable. Further, GC is only efficient when given 3–4× more memory to work with than the process is using at any time, and this tradeoff is not acceptable for Swift.
* [Disjunctions (logical ORs) in type constraints](https://forums.swift.org/t/returned-for-revision-se-0095-replace-protocol-p1-p2-syntax-with-any-p1-p2/2855): These include anonymous union-like types (e.g. `(Int | String)` for a type that can be inhabited by either an integer or a string). "[This type of constraint is] something that the type system cannot and should not support."
================================================
FILE: policies/0001-platform-support-tiers.md
================================================
# Swift Platform Support Tiers
* Policy: [SP-0001](0001-platform-support-tiers.md)
* Authors: [Platform Steering Group](https://forums.swift.org/g/platform-steering-group)
* Review Manager: Alastair Houghton
* Status: **Accepted**
* Review: ([rfc](https://forums.swift.org/t/sp-001-platform-support-levels/84420))
## Introduction
The Swift programming language has evolved into a versatile and powerful tool
for developers across a wide range of platforms. As the ecosystem continues to
grow, it is essential to establish a clear and forward-looking policy for
platform support. This policy has two main goals:
1. To establish common terminology and definitions for platform support.
2. To document a process for platforms to become officially supported in Swift.
## Understanding Platforms in the Swift Ecosystem
The term "platform" carries multiple interpretations. For our purposes, a
platform represents the confluence of operating system, architecture, and
environment where Swift code executes. Each platform is identified using a
version-stripped LLVM `Triple`—a precise technical identifier that captures the
essential characteristics of a host environment (e.g.,
`x86_64-unknown-windows-msvc`).
## The Anatomy of a `Triple`
At its core, a `Triple` comprises 11 distinct elements arranged in a specific
pattern:
```
[architecture][sub-architecture][extensions][endian]-[vendor]-[kernel/OS][version]-[libc/environment][abi][version]-[object format]
```
This naming convention might initially appear complex, but it offers remarkable
precision. When a public entity isn't associated with a toolchain, the
placeholder `unknown` is used for the vendor field. Similarly, bare-metal
environments—those without an operating system—employ `none` as their OS/kernel
designation.
While many of these fields may be elided, for use in Swift, the vendor and OS
fields are always included, even if they are placeholder values.
Consider these illustrative examples:
- `armv7eb-unknown-linux-uclibceabihf-coff`: A Linux system running on ARMv7 in big-endian mode, with the µClibc library and PE/COFF object format.
- `aarch64-unknown-windows-msvc-macho`: Windows NT on the ARM64 architecture using the MSVC runtime with Mach-O object format.
- `riscv64gcv-apple-ios14-macabi`: An iOS 14 environment running on a RISC-V processor with specific ISA extensions.
This nomenclature creates a shared language for discussing platform capabilities
and constraints—an essential foundation for our support framework.
## Distributions within Platforms
A platform and distribution, while related, serve distinct roles in the Swift
ecosystem. A platform refers to the broader combination of Operating System,
architecture, and environment where Swift code executes and establishes the
foundational compatibility and functionality of Swift.
A distribution, on the other hand, represents a specific implementation or
variant within a platform. For example, while Linux as a platform is supported,
individual distributions such as Ubuntu, Fedora, or Amazon Linux require
additional work to ensure that Swift integrates seamlessly. This includes
addressing distribution-specific configurations, dependencies, and conventions.
Distributions are treated similarly to platforms in that they require a
designated owner. This owner is responsible for ensuring that Swift functions
properly on the distribution, adheres to the distribution's standards, and
remains a responsible citizen within that ecosystem. By assigning ownership, the
Swift community ensures that each distribution receives the attention and
stewardship necessary to maintain a high-quality experience for developers.
## Platform Stewardship
The health of each platform depends on active stewardship. Every platform in the
Swift ecosystem requires a designated owner who reviews platform-specific
changes and manages release activities. Platforms without active owners enter a
dormant state, reverting to exploratory status until new leadership emerges.
This ownership model ensures that platform support remains intentional rather
than accidental—each supported environment has an advocate invested in its
success.
The Platform Steering Group will regularly review the list of supported
platforms against the tier criteria below. While the Platform Steering Group
reserves the right to update the list or the tier criteria at any time, it is
expected that most such changes will be aligned with the Swift release cycle.
## A Tiered Approach to Platform Support
Swift's platform support strategy employs three distinct tiers, each
representing a different level of maturity. The requirements for each tier build
upon those of the previous tier.
### Tier 1: "Supported" Platforms
These are Swift's most mature environments, where the language must consistently
build successfully and pass comprehensive test suites. Swift on these platforms
offers the strongest guarantees of stability and performance.
Platforms that are in Tier 1 should:
- [ ] Digitally sign their release artifacts.
- [ ] Include a Software Bill of Materials (SBOM).
- [ ] Include at a minimum the following Swift libraries:
- [ ] Swift Standard Library
- [ ] Swift Supplemental Libraries
- [ ] Swift Core Libraries
- [ ] Swift Testing Frameworks (if applicable)
(See [the Swift Runtime Libraries
document](https://github.com/swiftlang/swift/blob/main/Runtimes/Readme.md#layering)
in [the Swift repository](https://github.com/swiftlang/swift) for the list of definitions.)
- [ ] Where it makes sense, include the following Swift packages:
- [ ] Foundation
- [ ] Dispatch
- [ ] XCTest
- [ ] Swift Testing
N.B. The Platform Steering Group will determine to what extent
these packages are required; additionally, the Platform Steering
Group may add to or remove items from this list on a case-by-case
basis, as it considers appropriate for the platform under
consideration.
- [ ] Maintain a three-version window of support, including:
- [ ] At least one stable release.
- [ ] The next planned release.
- [ ] The development branch (`main`).
- [ ] Have a clear, documented, story for debugging, to allow users to set up
an environment where their products can be executed on a device or
simulator and be debugged.
- [ ] Have testing in CI, including PR testing.
New platforms should expect that their PR tests will not
initially be required to pass to merge changes, but the intent
is that in the longer term they will be made mandatory. This is
so that it is possible to accumulate experience with new
platforms' PR tests in order to establish that they are not
flaky and do not pose problems that will block forward progress.
Core Team will have sole discretion as to which platforms' PR
tests must pass in order to merge.
- [ ] Ship SDKs as regular release from [swift.org](https://swift.org)
- [ ] Ensure that instructions needed to get started on the platform
are publicly available, ideally on or linked to from
[swift.org](https://swift.org).
An important aspect of Tier 1 platforms is that maintenance of support
of these platforms is the collective responsibility of the Swift
project as a whole, rather than falling entirely on the platform
owner. This means:
- Contributions should not be accepted if they break a Tier 1 platform.
- If a Tier 1 platform does break, whoever is responsible for the code
that is breaking must work with the platform owner on some kind of
resolution, which may mean backing out the relevant changes.
- New features should aim to function on all Tier 1
platforms, subject to the availability of appropriate supporting
functionality on each platform.
- There is a presumption that a release of Swift will be blocked if a
Tier 1 platform is currently broken. This is not a hard and fast
rule, and can be overridden if it is in the interests of the Swift
project as a whole.
### Tier 1: "Supported" Toolchain Hosts
Each toolchain host is an expensive addition to the testing matrix.
In addition to the requirements above, a toolchain host platform should:
- [ ] Have CI coverage for the toolchain, including PR testing.
- [ ] Offer toolchain distributions from
[swift.org](https://swift.org) as an official source, though
other distributions may also be available.
- [ ] Include the following toolchain components:
- [ ] Swift compiler (`swiftc`).
- [ ] C/C++ compiler (`clang`, `clang++`).
- [ ] Assembler (LLVM integrated assembler, built into `clang`).
- [ ] Linker (_typically_ `lld`).
- [ ] Debugger (`lldb`).
- [ ] Swift Package Manager (SwiftPM).
- [ ] Language Server (`sourcekit-lsp`).
- [ ] Debug Adapter (`lldb-dap`).
- [ ] Where possible, include the following additional components:
- [ ] DocC (`docc`)
- [ ] Swiftly (`swiftly`)
As with the list of packages above, the Platform Steering Group
reserves the right to decide to what extent these are optional for a
given platform, as well as the right to add or remove items from this
list on a case-by-case basis.
- [ ] Code-sign individual tools as appropriate for the platform.
Note that the bar for accepting a platform as a toolchain host is somewhat
higher than the bar for accepting a non-toolchain-host platform.
### Tier 2: "Experimental" Platforms
Experimental platforms occupy the middle ground—they must maintain the ability
to build but may experience occasional test failures. These platforms
represent Swift's expanding frontier.
Platforms in this tier should:
- [ ] Ensure that dependencies beyond the platform SDK can build from source.
- [ ] Provide provenance information to validate the software supply chain.
- [ ] Include at a minimum the following Swift libraries:
- [ ] Swift Standard Library
- [ ] Swift Supplemental Libraries
- [ ] Swift Core Libraries
- [ ] Swift Testing Frameworks (if applicable)
(See [the Swift Runtime Libraries
document](https://github.com/swiftlang/swift/blob/main/Runtimes/Readme.md#layering)
in [the Swift repository](https://github.com/swiftlang/swift) for the list of definitions.)
- [ ] Maintain at least a two-version window of support, including
- [ ] The next planned release.
- [ ] The development branch (`main`).
Unlike Tier 1, the Swift project does not assume collective
responsibility for experimental platforms. Platform owners should
work with individual contributors to keep their platform in a
buildable state.
### Tier 3: "Exploratory" Platforms
At the boundary of Swift's reach are exploratory platforms.
Exploratory status offers an entry point for platforms taking their
first steps into the Swift ecosystem.
Platforms in this tier should:
- [ ] Support reproducible builds without requiring external
patches, though there is no requirement that these build completely
or consistently.
- [ ] Maintain support in the current development branch (`main`).
The Swift Project does not assume collective responsibility for
exploratory platforms. Platform owners are responsible for keeping
their platform in a buildable state.
## Platform Inclusion Process and Promotion
Adding platform support begins with a formal request to the Platform Steering
Group, accompanied by a platform owner nomination. This structured yet
accessible approach balances Swift's need for stability with its aspiration for
growth.
The request should include:
- [ ] The preferred name of the platform.
- [ ] The name and contact details of the platform owner.
- [ ] The support tier into which the platform should be placed.
- [ ] Instructions to build Swift for the platform, assuming someone
is starting from scratch, including any requirements for the
build system.
- [ ] A list of tier requirements that are currently _not_ met by the
platform, including an explanation as to _why_ they are not met
and what the proposal is to meet them, if any.
- [ ] Whether there has been any discussion about provisioning of CI
resources, and if so a copy of or link to that discussion. This
is particularly relevant for a Tier 1 platform request.
Note that it is _not_ the case that a platform _must_ meet every
requirement of the requested tier in order to be placed into that
tier. The Platform Steering Group will consider each case on its
merits, and will make a decision based on the information at hand as
well as the overall benefit to the Swift Project. It should be
emphasized that the Platform Steering Group reserves the right to
consider factors other than those listed here when making decisions
about official platform support.
The same process should be used to request a promotion to a higher
tier.
## Existing Platforms and Demotion
The following existing platforms are in Tier 1 regardless of any
text in this document:
- All Apple platforms (macOS, iOS and so on).
- Linux
- Windows
The Platform Steering Group reserves the right to demote any
platform to a lower tier, but regards demotion as a last resort
and will by preference work with platform owners to maintain
support appropriate for their platform's existing tier.
Note that if your platform is one of the above special cases, and
there is some requirement in this document that is not being met, it
is expected that either there is a very good reason for the
requirement not being met, or that there is some plan to meet it in
future.
(Note: we intentionally do not list specific architectures,
distributions or SKUs above. More precise details of what we consider
supported will be published on [swift.org](https://swift.org).)
================================================
FILE: policies/templates/xxxx-policy-template.md
================================================
# Policy name
* Policy: [SP-NNNN](NNNN-filename.md)
* Authors: [Author 1](https://github.com/swiftdev), [Author 2](https://github.com/swiftdev)
* Review Manager: TBD
* Status: **Request for Comments** or **Accepted**
* Review: ([rfc](https://forums.swift.org/...))
When filling out this template, you should delete or replace all of
the text except for the section headers and the header fields above.
For example, you should delete everything from this paragraph down to
the Introduction section below.
As a policy author, you should fill out all of the header fields
except `Review Manager`. The review manager will set that field and
change others as part of initiating the review.
## Introduction
A short description of the purpose of the proposed policy.
## Detail
From this point on, you can use whatever headings make most sense for
your policy.
================================================
FILE: process.md
================================================
# Swift Evolution Process
Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier.
Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process.
This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.
## Scope
The Swift evolution process applies to all design changes to specific aspects of the Swift project.
This includes the Swift language, its standard library and certain other core libraries, and the interfaces of core tools such as the Swift package manager.
The complete list is given [below](#evolution-areas).
The evolution process applies only to the design of features.
Neither the implementation of the feature nor the user documentation for it require evolution review.
Implementation and documentation work in the Swift project is open-source and subject to the normal code review process; see [Contributing to Swift](https://www.swift.org/contributing/).
Changes such as bug fixes, optimizations, and diagnostic improvements can be contributed at any time.
Implementation review is generally completely independent from the design review performed by the Swift evolution process.
However, there is one important exception: patches that would change a design covered by the evolution process should not be merged without the approval of the appropriate evolution workgroup.
This may include fixing bugs, if the bug allows additional things to be expressed or changes the user-visible behavior of a feature.
Bugs in features that have not yet been officially released can be freely fixed.
Implementors should check with the appropriate evolution workgroup if they're uncertain what to do.
The evolution process does not cover the design of experimental features, which can be added, changed, or removed at any time using the normal code review process.
Implementations should take steps to prevent the accidental use of experimental features, such as by enabling them only when an explicitly experimental command line flag is passed to the tool.
Features should not be allowed to remain perpetually experimental; a feature with no clear path for development into an official feature should be removed.
The evolution process does not cover everything that is important for writing Swift code.
The design of tools such as IDEs, debuggers, profilers, and documentation generators is outside of the scope of the evolution process.
The Core Team may empower workgroups to guide or offer recommendations for the development of these tools, but that guidance is not reviewed, and recommendations for tools developed outside of the Swift project are not binding.
## Goals
The Swift evolution process aims to leverage the collective ideas, insights, and experience of the Swift community to improve the Swift development experience.
Its two primary goals are:
* Engage the wider Swift community in the ongoing evolution of Swift, and
* Maintain the vision and conceptual coherence of Swift.
There is a natural tension between these two goals.
Open evolution processes are, by nature, chaotic.
Yet, maintaining a coherent vision for something as complicated as a programming language requires some level of coordination.
The Swift evolution process aims to strike a balance that best serves the Swift community as a whole.
## Evolution workgroups
The [Core Team](https://www.swift.org/community/#core-team) is responsible for the strategic direction of Swift.
As part of this, it identifies areas of the Swift project that should be covered by the evolution process.
Anything not so identified is not covered by the evolution process.
The Core Team may elect to delegate evolution authority over a specific area to a particular [steering group or workgroup](https://www.swift.org/community/).
Otherwise, that evolution authority remains with the Core Team. The group that exercises evolution authority over an area is called its *evolution workgroup*.
Evolution workgroups are responsible for deciding the details of how the evolution process applies to their evolution areas, within the guidelines laid out in the following section.
If a proposal touches on multiple evolution areas, all affected evolution workgroups work together to decide and carry out the details of the evolution process for the proposal.
Steering groups and the Core Team oversee the evolution decisions of any evolution workgroups organized beneath them.
They review any substantial changes to the review process and have the right to override evolution decisions as they see fit.
## Evolution review
The evolution process consists of two key steps:
1. the creation of a *proposal document* that describes the proposal, usually developed and discussed in a [forums thread][forums] called a *pitch*; and
2. an *open review* of the proposal by the community at large, after which the evolution workgroup decides what to do with it.
Every substantial design change in an area covered by the evolution process must go through these two steps and be accepted by the appropriate evolution workgroup before it can be released.
Evolution workgroups may decide that a [change is minor enough to not need review](#summary-acceptance). They may also [reject a proposal without review](#summary-rejection).
The exact details of the review process are decided by the appropriate evolution workgroup for an evolution area.
However, there is a baseline expectation of what constitutes a proper review for all parts of the Swift project.
Currently, all evolution areas use *full evolution review* for all proposals.
In this process, the pitch and open review are separate and explicit steps.
The proposal is developed in a pitch thread until the author is satisfied with it and the workgroup believes it is ready for review.
The workgroup then creates a new thread for the open review of that specific version of the proposal.
After the review is complete, the workgroup either decides to accept it, reject it, or ask for revisions.
If the proposal is revised in a substantially new way that has not been adequately discussed, the revised proposal must then undergo another round of open review.
This may continue until the workgroup is ready to make a final decision.
The review process for an evolution area is described in the [Evolution Areas](#evolution-areas) section below.
This includes:
- where pitches and open reviews are conducted on the [forums][forums] and
- any additional requirements that proposals must satisfy to be considered.
Substantial changes to the review process for an evolution area must be approved by the Core Team or (if applicable) the steering group that has oversight over the workgroup.
This document should also be updated to reflect the changes, and workgroups are encouraged to propose them as a PR.
### Summary acceptance
Evolution workgroups may decide that certain design changes are sufficiently obvious to accept without a proposal document or open review.
This is generally only appropriate for small adjustments to recently-accepted proposals where the workgroup feels that there is no reasonable objection or alternative to the proposed change.
Examples include:
- adding a method to a particular type which was overlooked in a proposal that added that method to several similar types;
- forbidding an unsafe or nonsensical use of a new feature; or
- gating a change behind an upcoming feature flag after it was discovered to cause significant source-compatibility problems.
Such changes should still generally be announced in the release notes when they are made.
Evolution workgroups should be circumspect about approving changes this way, and in close cases, they should err on the side of conducting a normal review.
### Summary rejection
Evolution workgroups may also reject proposals without review if the workgroup believes that there's no possibility that further development or review of the proposal would lead to it being accepted.
This should only be done when there's consensus within the workgroup, but it can be appropriate if, for example, the workgroup feels that the proposal is simply out of keeping with its overall design direction for the evolution area.
The workgroup should clearly communicate its decision and the reasons why in any threads discussing the proposal.
## Participation
Everyone in the Swift community is welcome to propose, discuss, and review ideas in any evolution area.
### Reviewing a proposal
You can provide feedback on a proposal in either the pitch phase or open review.
If you have limited time to participate in Swift evolution, you should focus on reading and providing feedback on proposals during their open review.
To participate in proposal review, you watch for proposal review threads in the appropriate section of the [forums][].
The forums software allows you to receive notifications whenever a thread is created in a specific category: click on the category, then click on the bell icon in the upper right to see your options.
You can also configure the forums to send you these notifications by email if you'd like.
You should make an effort to read and understand the proposal document before providing feedback.
However, you do not have to have read the review thread, and it's okay to leave the same feedback as someone else.
The evolution workgroup may provide specific guidance about what they're looking for in review feedback, but in general, good feedback includes things like:
- asking for clarification about what the document is trying to say
- evaluations of specific aspects of the proposal, rather than just broad sentiments
- examples of how you'd actually use the proposed change / how you don't think you'd be able to use it
You can leave review feedback either publicly, by making a reply in the review thread, or privately, by sending a message directly to the review manager as laid out in the initial post of the review thread.
If you leave feedback publicly, other community members may respond to you, but you are not obliged to engage with them; it's fine to leave your feedback and move on.
In either case, the review manager may ask you for clarification so that they can more accurately represent your opinion to the rest of the workgroup.
Please understand that open review is not a vote.
The evolution workgroup is going to make a decision using its judgment of what's best for the project based on the information it has available to it.
Simple statements of being for or against a proposal doesn't typically add much to the conversation.
In contrast, a detailed argument that you don't think you'll be able to use the proposal because of a specific technical flaw is much more likely to be convincing.
To participate in the pitch phase, you watch for pitch threads in the appropriate section of the [forums][].
Pitch discussions are usually informal, open-ended discussions about the problem at hand and how the author is trying to solve it.
Participating in a pitch thread can be a very powerful way of shaping the idea before it ever proceeds to review, but it can also require a much more substantial time commitment.
Good pitch feedback includes anything that would be appropriate as review feedback (above), plus:
- evaluations of alternative approaches that you've used
- suggestions for how to improve the proposal document (if the author's started writing one)
### Making a proposal
The exact details of making a proposal may vary between evolution areas; read the [descriptions of the different areas](#evolution-areas) for more information.
1. You should start by checking to see if your idea's already being discussed.
The [Swift forums][forums] have a search function that you can use to look for existing threads.
Some evolution areas also maintain a list of commonly rejected proposals, which you can find linked from the appropriate section of this document.
If the idea has come up before, but it hasn't been rejected, the discussion died down a long time ago, and you think you have something new to add, you are welcome to start a new pitch.
2. You *pitch* an idea by creating a thread to discuss it in a specific section of the forums.
This is usually an informal, open-ended discussion about the problem you're trying to solve and your ideas about how to solve it.
You do not need to have written a formal proposal at this point.
If your search found any relevant prior threads, please link to them in your new pitch.
3. When you've developed a solid idea of what you want to propose, you write a formal *proposal document*.
You should follow the appropriate template document for the evolution area you're working in.
The template may describe additional requirements, like having a prototype implementation ready; this varies from area to area.
Be sure to update the pitch thread whenever you make significant changes to the proposal.
4. You signal that you think your proposal is ready for review by creating a non-[draft][draft-pr] pull request to add it to the appropriate directory in the [evolution repository][swift-evolution-repo].
5. The evolution workgroup will appoint a *review manager* to oversee your proposal.
The review manager should get in touch within a few weeks to relay any additional feedback from the workgroup.
When they agree that your proposal is ready, they'll create a dedicated thread for the open review in the appropriate section of the forums.
This thread will be kept open for a period of at least ten days, covering at minimum two consecutive weekends.
If you need to make revisions to your proposal during the review, the review period may need to be extended to give adequate review time to the change.
6. After the review period ends, the evolution workgroup will decide what to do with your proposal.
Possible outcomes include accepting it, outright rejecting it, or asking you to revise it, with the expectation of putting the revised proposal through another round of pitch or review.
As a proposal author, you have a responsibility to try to respond to questions during the pitch and open review.
Especially during the pitch phase, keep in mind that questions about your proposal often identify places where you can improve your proposal document to be clearer.
You should also try to engage with feedback and make an effort to understand other people's criticisms.
If they've identified a real flaw, you should thank them and revise the proposal accordingly.
If they're misunderstanding your proposal, you can probably improve the document to clarify the point of confusion.
If, after a reasonable discussion, you find that you simply disagree with them about the design, that's okay.
Your objective should be to make the best case for your proposal that you can, both to the community at large and to the evolution workgroup.
If the workgroup agrees with your side of the argument, they will accept your proposal even if you haven't achieved perfect consensus in the community.
You may find it helpful, however, to write up the disagreement in the proposal document, perhaps as part of the motivation or in the Alternatives Considered section.
Ultimately, open review is not a vote.
The role of evolution reviewers is to provide feedback on the proposal, including arguments for or against it.
The evolution workgroup will then consider these arguments and decide what is best for the Swift project.
Neither the raw number of people making arguments on either side, nor the ferocity of their arguments, is a meaningful input to that decision.
## Proposals, roadmaps, and visions
There are three kinds of documents commonly used in the evolution process.
* An evolution *proposal* describes a specific proposed change in detail.
All substantial design changes are advanced as proposals which will be discussed in the community and given a formal open review.
* An evolution *roadmap* describes a concrete plan for how a complex change will be broken into separate proposals that can be individually pitched and reviewed.
Considering large changes in small pieces allows the community to provide more focused feedback about each part of the change.
A roadmap makes this organization easier for community members to understand.
Roadmaps are planning documents that do not need to be reviewed.
* An evolution *vision* describes a high-level design for a broad topic (for example, string processing or concurrency).
A vision creates a baseline of understanding in the community for future conversations on that topic, setting goals and laying out a possible program of work.
Visions must be approved by the appropriate evolution workgroup. This approval is an endorsement of the vision's basic ideas, but not of any of its concrete proposals, which must still be separately developed and reviewed.
## Evolution areas
### Language and standard library evolution
The [Language Steering Group][language-steering-group] has authority over:
- the features of the Swift language,
- the public interface of the Swift standard library,
- the language configuration options of the Swift compiler, and
- the language configuration options of [Swift package manager][spm] manifest files.
Language and standard library proposals use full evolution review.
They are pitched in the [Evolution > Pitches][forums-pitches] section of the Swift forums and reviewed in the [Evolution > Proposal Reviews][forums-reviews] section.
The LSG requires language and standard library proposals to have a prototype implementation before they can be reviewed.
This implementation doesn't have to be fully professional and ready to release, but it at least has to be a viable proof of concept and in a state that can be used by reviewers.
Language and standard library proposal documents should use the [Swift proposal template](proposal-templates/0000-swift-template.md).
They use the "SE" prefix and can be found in the [`proposals` directory](proposals/) of the Swift evolution repository.
The LSG maintains a list of [commonly rejected proposals](commonly_proposed.md).
### Package manager evolution
The [Ecosystem Steering Group][ecosystem-steering-group] has authority over all aspects of the [Swift package manager][spm] and its manifest files except language configuration.
Package manager proposals use full evolution review.
Proposals are pitched in the [Evolution > Pitches][forums-pitches] section of the Swift forums and reviewed in the [Evolution > Proposal Reviews][forums-reviews] section.
Package manager proposal documents should be based on the [package manager proposal template](proposal-templates/0000-swiftpm-template.md).
For historical reasons, they also use the "SE" prefix and can be found in the [`proposals` directory](proposals/) of the Swift evolution repository.
### Testing evolution
The [Testing Workgroup][testing-workgroup] has authority over the evolution of the [Swift Testing](https://github.com/swiftlang/swift-testing) and [Corelibs XCTest](https://github.com/swiftlang/swift-corelibs-xctest) projects.
Testing proposals use full evolution review.
They are pitched in the [Evolution > Pitches][forums-pitches] section of the Swift forums and reviewed in the [Evolution > Proposal Reviews][forums-reviews] section.
Testing proposals should use the [testing proposal template](proposal-templates/0000-swift-testing-template.md).
They use the "ST" prefix and can be found in the [`proposals/testing` directory](proposals/testing/) of the Swift evolution repository.
## Focus areas for Swift releases
Each major Swift release is focused on a [specific set of goals](README.md) described early in the release cycle.
These focus areas don't necessarily mean that unrelated proposals won't be considered, but if the evolution workgroup decides that your proposal doesn't fit with the focus areas of the current release, they may ask you to hold it until a later release.
If you are worried that an idea might out of scope for the current release, please contact a representative of the appropriate evolution workgroup for guidance.
<details>
<summary>Information mostly of interest to evolution workgroups</summary>
## Proposal documents
Proposal documents should generally not be renamed once they've been added to the repository.
It's okay to change the name of the proposal in the text, but the filename should remain stable.
To simplify automated "scraping" of proposal documents, all proposal documents (and therefore proposal templates) should start with the following basic structure and use standard fields:
```text
# Name of proposal
* Field1: value
* Field2: value
The remainder of the document has no specific requirements.
```
Standard fields include:
* `Proposal`:
exactly `[prefix-number](filename.md)`, where `prefix` is the appropriate document prefix (such as `SE` for language and SPM proposals), `number` is the sequence number of this proposal within that prefix, and `filename.md` is the filename of this proposal document.
Required in all proposal documents.
* `Author` or `Authors`:
a comma-separated list of authors.
Required in all proposal documents.
Usually, author names will link to their github profiles, but that is not required.
The plural name `Authors` should be used if and only if there are multiple authors in the list.
Authors should only list other people as co-authors with their explicit consent.
* `Review Manager` or `Review Managers`:
a comma-separated list of review managers.
Required in all proposal documents that use full evolution review.
Usually, these will be links to their github profiles, but that is not required.
The plural name `Review Managers` should be used if and only if there are multiple review managers in the list.
* `Status`:
one of the [proposal states](#proposal-states), bolded using `**`.
Required in all proposal documents.
* `Vision`:
a link to a vision document which encompasses this proposal.
Optional.
* `Roadmap`:
a link to a roadmap document or thread which encompasses this proposal.
Optional.
* `Bug`:
a link to a bug related to this proposal.
Optional.
* `Implementation`:
a comma-separated list of links to implementation pull requests for this proposal.
Optional.
* `Previous Proposal`:
a link to a previous proposal (with a different document number) addressing the same idea.
This field is rare because proposals are usually revised rather than replaced.
Optional.
* `Previous Revision` or `Previous Revisions`:
a space-separated list of permalinks to previous revisions of this proposal document.
Optional.
The link text should be a number, starting with 1.
Only "official" revisions need to be listed, such as those used for different open reviews.
The plural name `Previous Revisions` should be used if and only if there are multiple revisions in the list.
Usually, there will be a previous revision for each additional review in the `Review` field, but sometimes multiple reviews are conducted on the same text in order to focus on different aspects of the proposal.
* `Review`:
a space-separated list of parenthesized links to different forums threads about this proposal.
Link text can be free-form but is encouraged to match the [standard grammar](#standard-review-links) whenever applicable.
Required in all new proposal documents.
These standard fields should be provided in this order. Other fields can be added between `Status` and `Review`.
The following header fields are used only in specific evolution areas:
* `Upcoming Feature Flag`: an identifier in backticks.
Used for language proposals where some or all of the content in the proposal is enabled only when a particular upcoming feature is enabled.
## Proposal states
```mermaid
flowchart LR
%% <https://mermaid-js.github.io/>
%% Nodes:
1{{"Awaiting<br/>review"}}
2{{"Scheduled<br>for review"}}
3{"Active<br/>review"}
4["Returned<br/>for revision"]
5(["Withdrawn"])
6(["Rejected"])
7_8["Accepted<br/>(with revisions)"]
9[["Previewing"]]
10(["Implemented"])
%% Links:
1 ==> 3 ==> 7_8 ==> 10
1 -.-> 2 -.-> 3 -.-> 4 -.-> 5 & 1
3 -.-> 6
7_8 -.-> 9 -.-> 10
```
A given proposal can be in one of several states:
* **Awaiting review**:
The proposal is awaiting review.
Once known, the dates for the actual review will be placed in the proposal document.
When the review period begins, the review manager will update the state to *Active review*.
* **Scheduled for review (...)**:
The public review of the proposal in the [Swift forums][proposal-reviews]
has been scheduled for the specified date range.
* **Active review (...)**:
The proposal is undergoing public review in the [Swift forums][proposal-reviews].
The review will continue through the specified date range.
* **Returned for revision**:
The proposal has been returned from review for additional revision to the current draft.
* **Withdrawn**:
The proposal has been withdrawn by the original submitter.
* **Rejected**:
The proposal has been considered and rejected.
* **Accepted**:
The proposal has been accepted and is either awaiting implementation or is actively being implemented.
* **Accepted with revisions**:
The proposal has been accepted, contingent upon the inclusion of one or more revisions.
* **Previewing**:
The proposal has been accepted and is available for preview in the [Standard Library Preview package][preview-package].
* **Implemented (Swift X.Y)**:
The proposal has been implemented (for the specified version of Swift).
If the proposal's implementation spans multiple version numbers, write the version number for which the implementation will be complete.
## Standard review links
While links in the `Review:` header field can have any text, they are encouraged to use standardized text matching the following grammar whenever that describes the target of the link with sufficient clarity:
```text
review-label:
ordinal? standard-review-label
# An ordinal should be provided if and only if there are multiple
# links of the same kind in the review field.
ordinal:
'first'
'second'
'third'
'fourth'
...
standard-review-label:
'pitch'
'review'
'revision'
'acceptance' ('with' 'modifications')?
'rejection'
'returned for revision'
```
This grammar assumes a single space between adjacent tokens.
## Review announcement
When a proposal enters full evolution review, a new topic will be posted to the appropriate section of the Swift forums using the appropriate announcement template below.
---
<details>
<summary>Language and standard library</summary>
Hello Swift community,
The review of "\<\<PROPOSAL NAME>>" begins now and runs through \<\<REVIEW END DATE>>. The proposal is available here:
> https://linkToProposal
Reviews are an important part of the Swift evolution process.
All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager.
When emailing the review manager directly, please keep the proposal link at the top of the message.
##### Trying it out
If you'd like to try this proposal out, you can [download a toolchain supporting it here]().
You will need to add `-enable-experimental-feature FLAGNAME` to your build flags.
\<\<Review managers should revise this section as necessary, or they can delete it if a toolchain is considered unnecessary for this proposal.\>\>
##### What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
> <https://github.com/swiftlang/swift-evolution/blob/main/process.md>
Thank you,
\<\<REVIEW MANAGER NAME>>
Review Manager
</details>
<details>
<summary>Testing</summary>
Hello Swift community,
The review of "\<\<PROPOSAL NAME>>" begins now and runs through \<\<REVIEW END DATE>>.
The proposal is available here:
> https://linkToProposal
Reviews are an important part of the Swift evolution process.
All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager.
When emailing the review manager directly, please keep the proposal link at the top of the message.
##### Trying it out
To try this feature out, add a dependency to the `main` branch of `swift-testing` to your package:
```swift
dependencies: [
...
.package(url: "https://github.com/swiftlang/swift-testing.git", branch: "main"),
]
```
Then, add a target dependency to your test target:
```swift
.testTarget(
...
dependencies: [
...
.product(name: "Testing", package: "swift-testing"),
]
```
Finally, import Swift Testing using `@_spi(Experimental) import Testing`.
##### What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift Testing?
* Does this proposal fit well with the feel and direction of Swift Testing?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review?
A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
> https://github.com/swiftlang/swift-evolution/blob/main/process.md
Thank you,
\<\<REVIEW MANAGER NAME>>
Review Manager
</details>
</details>
[forums]: https://forums.swift.org/
[forums-pitches]: https://forums.swift.org/c/evolution/pitches/5
[forums-reviews]: https://forums.swift.org/c/evolution/proposal-reviews/21
[forums-notifications]: https://meta.discourse.org/t/understanding-the-notifications-menu-in-discourse/3059
[spm]: https://www.swift.org/package-manager/
[swift-evolution-repo]: https://github.com/swiftlang/swift-evolution "Swift evolution repository"
[swift-evolution-staging]: https://github.com/swiftlang/swift-evolution-staging "Swift evolution staging repository"
[proposal-reviews]: https://forums.swift.org/c/evolution/proposal-reviews "'Proposal reviews' subcategory of the Swift forums"
[status-page]: https://www.swift.org/swift-evolution
[preview-package]: https://github.com/apple/swift-standard-library-preview/
[language-steering-group]: https://www.swift.org/language-steering-group
[platform-steering-group]: https://www.swift.org/platform-steering-group
[ecosystem-steering-group]: https://www.swift.org/ecosystem-steering-group
[testing-workgroup]: https://www.swift.org/testing-workgroup "Testing Workgroup page on Swift.org"
[swift-template]: proposal-templates/0000-swift-template.md "Swift proposal template"
[swiftpm-template]: proposal-templates/0000-swiftpm-template.md "Swift Package Manager proposal template"
[swift-testing-template]: proposal-templates/0000-swift-testing-template.md "Swift Testing proposal template"
[draft-pr]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
================================================
FILE: proposal-templates/0000-swift-template.md
================================================
# Feature name
* Proposal: [SE-NNNN](NNNN-filename.md)
* Authors: [Author 1](https://github.com/swiftdev), [Author 2](https://github.com/swiftdev)
* Review Manager: TBD
* Status: **Awaiting implementation** or **Awaiting review**
* Vision: *if applicable* [Vision Name](https://github.com/swiftlang/swift-evolution/visions/NNNNN.md)
* Roadmap: *if applicable* [Roadmap Name](https://forums.swift.org/...)
* Bug: *if applicable* [swiftlang/swift#NNNNN](https://github.com/swiftlang/swift/issues/NNNNN)
* Implementation: [swiftlang/swift#NNNNN](https://github.com/swiftlang/swift/pull/NNNNN) or [swiftlang/swift-evolution-staging#NNNNN](https://github.com/swiftlang/swift-evolution-staging/pull/NNNNN)
* Upcoming Feature Flag: *if applicable* `MyFeatureName`
* Previous Proposal: *if applicable* [SE-XXXX](XXXX-filename.md)
* Previous Revision: *if applicable* [1](https://github.com/swiftlang/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md)
* Review: ([pitch](https://forums.swift.org/...))
When filling out this template, you should delete or replace all of
the text except for the section headers and the header fields above.
For example, you should delete everything from this paragraph down to
the Introduction section below.
As a proposal author, you should fill out all of the header fields
except `Review Manager`. The review manager will set that field and
change several others as part of initiating the review. Delete any
header fields marked *if applicable* that are not applicable to your
proposal.
When sharing a link to the proposal while it is still a PR, be sure
to share a live link to the proposal, not an exact commit, so that
readers will always see the latest version when you make changes.
On GitHub, you can find this link by browsing the PR branch: from the
PR page, click the "username wants to merge ... from username:my-branch-name"
link and find the proposal file in that branch.
`Status` should reflect the current implementation status while the
proposal is still a PR. The proposal cannot be reviewed until an
implementation is available, but early readers should see the correct
status.
`Vision` should link to the [vision document](https://forums.swift.org/t/the-role-of-vision-documents-in-swift-evolution/62101)
for this proposal, if it is part of a vision. Most proposals are not
part of a vision. If a vision has been written but not yet accepted,
link to the discussion thread for the vision.
`Roadmap` should link to the discussion thread for the roadmap for
this proposal, if applicable. When a complex feature is broken down
into several closely-related proposals to make evolution review easier
and more focused, it's helpful to make a forum post explaining what's
going on and detailing how the proposals are expected to be submitted
to review. That post is called a "roadmap". Most proposals don't need
roadmaps, but if this proposal was part of one, this field should link
to it.
`Bug` should be used when this proposal is fixing a bug with significant
discussion in the bug report. It is not necessary to link bugs that do
not contain significant discussion or that merely duplicate discussion
linked somewhere else. Do not link bugs from private bug trackers.
`Implementation` should link to the PR(s) implementing the feature.
If the proposal has not been implemented yet, or if it simply codifies
existing behavior, just say that. If the implementation has already
been committed to the main branch (as an experimental feature), say
that and specify the experimental feature flag. If the implementation
is spread across multiple PRs, just link to the most important ones.
`Upcoming Feature Flag` should be the feature name used to identify this
feature under [SE-0362](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0362-piecemeal-future-features.md#proposals-define-their-own-feature-identifier).
Not all proposals need an upcoming feature flag. You should think about
whether one would be useful for your proposal as part of filling this
field out.
`Previous Proposal` should be used when there is a specific line of
succession between this proposal and another proposal. For example,
this proposal might have been removed from a previous proposal so
that it can be reviewed separately, or this proposal might supersede
a previous proposal in some way that was felt to exceed the scope of
a "revision". Include text briefly explaining the relationship,
such as "Supersedes SE-1234" or "Extracted from SE-01234". If possible,
link to a post explaining the relationship, such as a review decision
that asked for part of the proposal to be split off. Otherwise, you
can just link to the previous proposal.
`Previous Revision` should be added after a major substantive revision
of a proposal that has undergone review. It links to the previously
reviewed revision. It is not necessary to add or update this field
after minor editorial changes.
`Review` is a history of all discussion threads about this proposal,
in chronological order. Use these standardized link names: `pitch`
`review` `revision` `acceptance` `rejection`. If there are multiple
such threads, spell the ordinal out: `first pitch` `second review` etc.
## Summary of changes
Briefly describe what this proposal would change about Swift so that readers
can decide whether it's relevant to them. **Use no more than 50 words (the
length of this paragraph).** This text should be appropriate for out-of-context
display in proposal lists; it doesn't need to flow into the next section.
Example (based on SE-0228):
> Redesigns the `ExpressibleByStringInterpolation` protocol to improve its
> performance and clarity, and to allow custom string interpolations to use
> stricter types, multiple arguments, and argument labels.
## Motivation
Describe the problems that this proposal seeks to address. If the
problem is that some common pattern is currently hard to express, show
how one can currently get a similar effect and describe its
drawbacks. If it's completely new functionality that cannot be
emulated, motivate why this new functionality would help Swift
developers create better Swift code.
If you need to provide technical background, summarize past work in this area,
justify the seriousness of the problem, or just generally clear your throat
before getting into the thick of things, this is usually the place to do it.
## Proposed solution
Describe your solution to the problem. Provide examples and describe
how they work. Show how your solution is better than current
workarounds: is it cleaner, safer, or more efficient?
This section doesn't have to be comprehensive. Focus on the most
important parts of the proposal and make arguments about why the
proposal is better than the status quo.
## Detailed design
Describe the design of the solution in detail. If it involves new
syntax in the language, show the additions and changes to the Swift
grammar. If it's a new API, show the full API and its documentation
comments detailing what it does. The detail in this section should be
sufficient for someone who is *not* one of the authors to be able to
reasonably implement the feature.
## Source compatibility
Describe the impact of this proposal on source compatibility. As a
general rule, all else being equal, Swift code that worked in previous
releases of the tools should work in new releases. That means both that
it should continue to build and that it should continue to behave
dynamically the same as it did before. Changes that cannot satisfy
this must be opt-in, generally by requiring a new language mode.
This is not an absolute guarantee, and the Language Workgroup will
consider intentional compatibility breaks if their negative impact
can be shown to be small and the current behavior is causing
substantial problems in practice.
For proposals that affect parsing, consider whether existing valid
code might parse differently under the proposal. Does the proposal
reserve new keywords that can no longer be used as identifiers?
For proposals that affect type checking, consider whether existing valid
code might type-check differently under the proposal. Does it add new
conversions that might make more overload candidates viable? Does it
change how names are looked up in existing code? Does it make
type-checking more expensive in ways that might run into implementation
limits more often?
For proposals that affect the standard library, consider the impact on
existing clients. If clients provide a similar API, will type-checking
find the right one? If the feature overloads an existing API, is it
problematic that existing users of that API might start resolving to
the new API?
## ABI compatibility
Describe the impact on ABI compatibility. As a general rule, the ABI
of existing code must not change between tools releases or language
modes. This rule does not apply as often as source compatibility, but
it is much stricter, and the Language Workgroup generally cannot allow
exceptions.
The ABI encompasses all aspects of how code is generated for the
language, how that code interacts with other code that has been
compiled separately, and how that code interacts with the Swift
runtime library. Most ABI changes center around interactions with
specific declarations. Proposals that do not affect how code is
generated to interact with an external declaration usually do not
have ABI impact.
For proposals that affect general code generation rules, consider
the impact on code that's already been compiled. Does the proposal
affect declarations that haven't explicitly adopted it, and if so,
does it change ABI details such as symbol names or conventions
around their use? Will existing code change its dynamic behavior
when running against a new version of the language runtime or
standard library? Conversely, will code compiled in the new way
continue to run on old versions of the language runtime or standard
library?
For proposals that affect the standard library, consider the impact
on any existing declarations. As above, does the proposal change symbol
names, conventions, or dynamic behavior? Will newly-compiled code work
on old library versions, and will new library versions work with
previously-compiled code?
This section will often end up very short. A proposal that just
adds a new standard library feature, for example, will usually
say either "This proposal is purely an extension of the ABI of the
standard library and does not change any existing features" or
"This proposal is purely an extension of the standard library which
can be implemented without any ABI support" (whichever applies).
Nonetheless, it is important to demonstrate that you've considered
the ABI implications.
If the design of the feature was significantly constrained by
the need to maintain ABI compatibility, this section is a reasonable
place to discuss that.
## Implications on adoption
The compatibility sections above are focused on the direct impact
of the proposal on existing code. In this section, describe issues
that intentional adopters of the proposal should be aware of.
For proposals that add features to the language or standard library,
consider whether the features require ABI support. Will adopters need
a new version of the library or language runtime? Be conservative: if
you're hoping to support back-deployment, but you can't guarantee it
at the time of review, just say that the feature requires a new
version.
Consider also the impact on library adopters of those features. Can
adopting this feature in a library break source or ABI compatibility
for users of the library? If a library adopts the feature, can it
be *un*-adopted later without breaking source or ABI compatibility?
Will package authors be able to selectively adopt this feature depending
on the tools version available, or will it require bumping the minimum
tools version required by the package?
If there are no concerns to raise in this section, leave it in with
text like "This feature can be freely adopted and un-adopted in source
code with no deployment constraints and without affecting source or ABI
compatibility."
## Future directions
Describe any interesting proposals that could build on this proposal
in the future. This is especially important when these future
directions inform the design of the proposal, for example by making
sure an attribute encodes enough information to be used for other
purposes.
The rest of the proposal should generally not talk about future
directions except by referring to this section. It is important
not to confuse reviewers about what is covered by this specific
proposal. If there's a larger vision that needs to be explained
in order to understand this proposal, consider starting a discussion
thread on the forums to capture your broader thoughts.
Avoid making affirmative statements in this section, such as "we
will" or even "we should". Describe the proposals neutrally as
possibilities to be considered in the future.
Consider whether any of these future directions should really just
be part of the current proposal. It's important to make focused,
self-contained proposals that can be incrementally implemented and
reviewed, but it's also good when proposals feel "complete" rather
than leaving significant gaps in their design. For example, when
[SE-0193](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md)
introduced the `@inlinable` attribute, it also included the
`@usableFromInline` attribute so that declarations used in inlinable
functions didn't have to be `public`. This was a relatively small
addition to the proposal which avoided creating a serious usability
problem for many adopters of `@inlinable`.
## Alternatives considered
Describe alternative approaches to addressing the same problem.
This is an important part of most proposal documents. Reviewers
are often familiar with other approaches prior to review and may
have reasons to prefer them. This section is your first opportunity
to try to convince them that your approach is the right one, and
even if you don't fully succeed, you can help set the terms of the
conversation and make the review a much more productive exchange
of ideas.
You should be fair about other proposals, but you do not have to
be neutral; after all, you are specifically proposing something
else. Describe any advantages these alternatives might have, but
also be sure to explain the disadvantages that led you to prefer
the approach in this proposal.
You should update this section during the pitch phase to discuss
any particularly interesting alternatives raised by the community.
You do not need to list every idea raised during the pitch, just
the ones you think raise points that are worth discussing. Of course,
if you decide the alternative is more compelling than what's in
the current proposal, you should change the main proposal; be sure
to then discuss your previous proposal in this section and explain
why the new idea is better.
## Acknowledgments
If significant changes or improvements suggested by members of the
community were incorporated into the proposal as it developed, take a
moment here to thank them for their contributions. Swift evolution is a
collaborative process, and everyone's input should receive recognition!
Generally, you should not acknowledge anyone who is listed as a
co-author or as the review manager.
================================================
FILE: proposal-templates/0000-swift-testing-template.md
================================================
# Swift Testing Feature name
* Proposal: [ST-NNNN](NNNN-filename.md)
* Authors: [Author 1](https://github.com/author1), [Author 2](https://github.com/author2)
* Review Manager: TBD
* Status: **Awaiting implementation** or **Awaiting review**
* Bug: _if applicable_ [swiftlang/swift-testing#NNNNN](https://github.com/swiftlang/swift-testing/issues/NNNNN)
* Implementation: [swiftlang/swift-testing#NNNNN](https://github.com/swiftlang/swift-testing/pull/NNNNN)
* Previous Proposal: _if applicable_ [ST-XXXX](XXXX-filename.md)
* Previous Revision: _if applicable_ [1](https://github.com/swiftlang/swift-evolution/blob/...commit-ID.../proposals/testing/NNNN-filename.md)
* Review: ([pitch](https://forums.swift.org/...))
When filling out this template, you should delete or replace all of the text
except for the section headers and the header fields above. For example, you
should delete everything from this paragraph down to the Introduction section
below.
As a proposal author, you should fill out all of the header fields except
`Review Manager`. The review manager will set that field and change several
others as part of initiating the review. Delete any header fields marked _if
applicable_ that are not applicable to your proposal.
When sharing a link to the proposal while it is still a PR, be sure to share a
live link to the proposal, not an exact commit, so that readers will always see
the latest version when you make changes. On GitHub, you can find this link by
browsing the PR branch: from the PR page, click the "username wants to merge ...
from username:my-branch-name" link and find the proposal file in that branch.
`Status` should reflect the current implementation status while the proposal is
still a PR. The proposal cannot be reviewed until an implementation is available,
but early readers should see the correct status.
`Bug` should be used when this proposal is fixing a bug with significant
discussion in the bug report. It is not necessary to link bugs that do not
contain significant discussion or that merely duplicate discussion linked
somewhere else. Do not link bugs from private bug trackers.
`Implementation` should link to the PR(s) implementing the feature. If the
proposal has not been implemented yet, or if it simply codifies existing
behavior, just say that. If the implementation has already been committed to the
main branch (as an experimental feature or SPI), mention that. If the
implementation is spread across multiple PRs, just link to the most important
ones.
`Previous Proposal` should be used when there is a specific line of succession
between this proposal and another proposal. For example, this proposal might
have been removed from a previous proposal so that it can be reviewed separately,
or this proposal might supersede a previous proposal in some way that was felt
to exceed the scope of a "revision". Include text briefly explaining the
relationship, such as "Supersedes ST-1234" or "Extracted from ST-01234". If
possible, link to a post explaining the relationship, such as a review decision
that asked for part of the proposal to be split off. Otherwise, you can just
link to the previous proposal.
`Previous Revision` should be added after a major substantive revision of a
proposal that has undergone review. It links to the previously reviewed revision.
It is not necessary to add or update this field after minor editorial changes.
`Review` is a history of all discussion threads about this proposal, in
chronological order. Use these standardized link names: `pitch` `review`
`revision` `acceptance` `rejection`. If there are multiple such threads, spell
the ordinal out: `first pitch` `second review` etc.
## Introduction
A short description of what the feature is. Try to keep it to a single-paragraph
"elevator pitch" so the reader understands what problem this proposal is
addressing.
## Motivation
Describe the problems that this proposal seeks to address. If the problem is
that some common pattern is currently hard to express, show how one can
currently get a similar effect and describe its drawbacks. If it's completely
new functionality that cannot be emulated, motivate why this new functionality
would help Swift developers test their code more effectively.
## Proposed solution
Describe your solution to the problem. Provide examples and describe how they
work. Show how your solution is better than current workarounds: is it cleaner,
safer, or more efficient?
This section doesn't have to be comprehensive. Focus on the most important parts
of the proposal and make arguments about why the proposal is better than the
status quo.
## Detailed design
Describe the design of the solution in detail. If it includes new API, show the
full API and its documentation comments detailing what it does. If it involves
new macro logic, describe the behavior changes and include a succinct example of
the additions or modifications to the macro expansion code. The detail in this
section should be sufficient for someone who is *not* one of the authors to be
able to reasonably implement the feature.
## Source compatibility
Describe the impact of this proposal on source compatibility. As a general rule,
all else being equal, test code that worked in previous releases of the testing
library should work in new releases. That means both that it should continue to
build and that it should continue to behave dynamically the same as it did
before.
This is not an absolute guarantee, and the testing library administrators will
consider intentional compatibility breaks if their negative impact can be shown
to be small and the current behavior is causing substantial problems in practice.
For proposals that affect testing library API, consider the impact on existing
clients. If clients provide a similar API, will type-checking find the right one?
If the feature overloads an existing API, is it problematic that existing users
of that API might start resolving to the new API?
## Integration with supporting tools
In this section, describe how this proposal affects tools which integrate with
the testing library. Some features depend on supporting tools gaining awareness
of the new feature for users to realize new benefits. Other features do not
strictly require integration but bring improvement opportunities which are worth
considering. Use this section to discuss any impact on tools.
This section does need not to include details of how this proposal may be
integrated with _specific_ tools, but it should consider the general ways that
tools might support this feature and note any accompanying SPI intended for
tools which are included in the implementation. Note that tools may evolve
independently and have differing release schedules than the testing library, so
special care should be taken to ensure compatibility across versions according
to the needs of each tool.
## Future directions
Describe any interesting proposals that could build on this proposal in the
future. This is especially important when these future directions inform the
design of the proposal, for example by making sure an interface meant for tools
integration can be extended to include additional information.
The rest of the proposal should generally not talk about future directions
except by referring to this section. It is important not to confuse reviewers
about what is covered by this specific proposal. If there's a larger vision that
needs to be explained in order to understand this proposal, consider starting a
discussion thread on the forums to capture your broader thoughts.
Avoid making affirmative statements in this section, such as "we will" or even
"we should". Describe the proposals neutrally as possibilities to be considered
in the future.
Consider whether any of these future directions should really just be part of
the current proposal. It's important to make focused, self-contained proposals
that can be incrementally implemented and reviewed, but it's also good when
proposals feel "complete" rather than leaving significant gaps in their design.
An an example from the Swift project, when
[SE-0193](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md)
introduced the `@inlinable` attribute, it also included the `@usableFromInline`
attribute so that declarations used in inlinable functions didn't have to be
`public`. This was a relatively small addition to the proposal which avoided
creating a serious usability problem for many adopters of `@inlinable`.
## Alternatives considered
Describe alternative approaches to addressing the same problem. This is an
important part of most proposal documents. Reviewers are often familiar with
other approaches prior to review and may have reasons to prefer them. This
section is your first opportunity to try to convince them that your approach is
the right one, and even if you don't fully succeed, you can help set the terms
of the conversation and make the review a much more productive exchange of ideas.
You should be fair about other proposals, but you do not have to be neutral;
after all, you are specifically proposing something else. Describe any
advantages these alternatives might have, but also be sure to explain the
disadvantages that led you to prefer the approach in this proposal.
You should update this section during the pitch phase to discuss any
particularly interesting alternatives raised by the community. You do not need
to list every idea raised during the pitch, just the ones you think raise points
that are worth discussing. Of course, if you decide the alternative is more
compelling than what's in the current proposal, you should change the main
proposal; be sure to then discuss your previous proposal in this section and
explain why the new idea is better.
## Acknowledgments
If significant changes or improvements suggested by members of the community
were incorporated into the proposal as it developed, take a moment here to thank
them for their contributions. This is a collaborative process, and everyone's
input should receive recognition!
Generally, you should not acknowledge anyone who is listed as a co-author or as
the review manager.
================================================
FILE: proposal-templates/0000-swiftpm-template.md
================================================
# Package Manager Feature name
* Proposal: [SE-NNNN](NNNN-filename.md)
* Authors: [Author 1](https://github.com/swiftdev), [Author 2](https://github.com/swiftdev)
* Review Manager: TBD
* Status: **Awaiting implementation**
*During the review process, add the following fields as needed:*
* Implementation: [swiftlang/swift-package-manager#NNNNN](https://github.com/swiftlang/swift-package-manager/pull/NNNNN)
* Decision Notes: [Rationale](https://forums.swift.org/), [Additional Commentary](https://forums.swift.org/)
* 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/swiftlang/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md)
* Previous Proposal: [SE-XXXX](XXXX-filename.md)
## Introduction
A short description of what the feature is. Try to keep it to a single-paragraph
"elevator pitch" so the reader understands what problem this proposal is
addressing.
Swift-evolution thread: [Discussion thread topic for that
proposal](https://forums.swift.org/)
## Motivation
Describe the problems that this proposal seeks to address. If the problem is
that some functionality is currently hard to use, show how it is currently used
and describe its drawbacks. If it's completely new functionality that cannot be
emulated, motivate why this new functionality would help Swift developers create
better Swift packages.
## Proposed solution
Describe your solution to the problem. Provide examples and describe how they
work. Show how your solution is better than current workarounds: is it cleaner,
easier, or more efficient?
## Detailed design
Describe the design of the solution in detail. If it involves adding or
modifying functionality in the package manager, explain how the package manager
behaves in different scenarios and with existing features. If it's a new API in
the `Package.swift` manifest, show the full API and its documentation comments
detailing what it does. The detail in this section should be sufficient for
someone who is *not* one of the author of the proposal to be able to reasonably
implement the feature.
## Security
Does this change have any impact on security, safety, or privacy?
## Impact on existing packages
Explain if and how this proposal will affect the behavior of existing packages.
If there will be impact, is it possible to gate the changes on the tools version
of the package manifest?
## Alternatives considered
Describe alternative approaches to addressing the same problem, and
why you chose this approach instead.
================================================
FILE: proposals/0001-keywords-as-argument-labels.md
================================================
# Allow (most) keywords as argument labels
* Proposal: [SE-0001](0001-keywords-as-argument-labels.md)
* Author: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 2.2)**
* Bug: [SR-344](https://bugs.swift.org/browse/SR-344)
## Introduction
Argument labels are an important part of the interface of a Swift function, describing what particular arguments to the function do and improving readability. Sometimes, the most natural label for an argument coincides with a language keyword, such as `in`, `repeat`, or `defer`. Such keywords should be allowed as argument labels, allowing better expression of these interfaces.
## Motivation
In some functions, the best argument label for a particular parameter
happens to coincide with a language keyword. For example, consider a
module-scope function that finds the index of a particular value in a
collection. A natural name for this would be `indexOf(_:in:)`:
indexOf(value, in: collection)
However, because `in` is a keyword, one would actually have to use backticks to escape the `in`, e.g.:
indexOf(value, `in`: collection)
When defining new APIs in Swift, authors will tend to pick other
non-keyword words (e.g., `within` for this example), even if they
aren't ideal. However, this issue also comes up when importing
Objective-C APIs under the "omit needless words" heuristics, requiring
escaping to use those APIs. For example:
event.touchesMatching([.Began, .Moved], `in`: view)
NSXPCInterface(`protocol`: SomeProtocolType.Protocol)
## Proposed solution
Allow the use of all keywords except `inout`, `var`, and `let` as argument labels. This affects the grammar in three places:
* Call expressions, such as the examples above. Here, we have no grammatic ambiguities, because "<keyword> \`:\`" does not appear in any grammar production within a parenthesized expression list. This is, by far, the most important case.
* Function/subscript/initializer declarations: aside from the three exclusions above, there is no ambiguity here because the keyword will always be followed by an identifier, ‘:’, or ‘_’. For example:
```swift
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>
```
Keywords that introduce or modify a parameter—-currently just
"inout", "let", and "var"—-will need to retain their former
meanings. If we invent an API that uses such keywords, they will still
need to be back-ticked:
```swift
func addParameter(name: String, `inout`: Bool)
```
* Function types: these are actually easier than #2, because the parameter name is always followed by a ‘:’:
```swift
(NSTouchPhase, in: NSView?) -> Set<NSTouch>
(String, inout: Bool) -> Void
```
## Impact on existing code
This functionality is strictly additive, and does not break any existing
code: it only makes some previously ill-formed code well-formed, and
does not change the behavior of any well-formed code.
## Alternatives considered
The primary alternative here is to do nothing: Swift APIs will
continue to avoid keywords for argument labels, even when they are the
most natural word for the label, and imported APIs will either
continue to use backticks or will need to be renamed. This alternative
leaves a large number of imported APIs (nearly 200) requiring either
some level of renaming of the API or backticks at the call site.
A second alternative is to focus on `in` itself, which is by far the
most common keyword argument in imported APIs. In a brief survey of
imported APIs, `in` accounted for 90% of the conflicts with existing
keywords. Moreover, the keyword `in` is only used in two places in the
Swift grammar--for loops and closures--so it could be made
context-sensitive. However, this solution is somewhat more complicated
(because it requires more context-sensitive keyword parsing) and less
general.
================================================
FILE: proposals/0002-remove-currying.md
================================================
# Removing currying `func` declaration syntax
* Proposal: [SE-0002](0002-remove-currying.md)
* Author: [Joe Groff](https://github.com/jckarter)
* Status: **Implemented (Swift 3.0)**
* Implementation: [apple/swift@983a674](https://github.com/apple/swift/commit/983a674e0ca35a85532d70a3eb61e71a6d024108)
## Introduction
Curried function declaration syntax `func foo(x: Int)(y: Int)` is of limited
usefulness and creates a lot of language and implementation complexity. We
should remove it.
## Motivation
The presence of curried function syntax has knock-on effects, complicating
other language features:
- The presence of currying invites confusion over keyword rules and the
declaration name of functions. We've argued several times over whether
curried arguments represent a continuation of the function's arguments, begin
the argument list of a new function, or deserve to follow different rules
altogether.
- It has subtle interactions with 'var' and 'inout' argument
annotations. A curried function with 'inout' parameters anywhere other than
its first clause cannot be partially applied without surprising semantic
restrictions, limiting its usefulness. With 'var' parameters, there's the
question of at what level the 'var' gets bound; many users expect it at the
outermost partial application, but we currently bind at the innermost partial
application.
The idioms of the standard library, Cocoa, and most third-party code don't
really make ML-style argument currying of free functions profitable. In
Cocoa and the standard library, most things are methods, where we can still get
useful partial application via `self.method` and maybe someday `.map { f($0)
}` as well. The curried function design also predates the design of the
keyword argument model. We have plans to move away
from the arguments-are-a-single-tuple model too (which is already belied by
things like `@autoclosure` and `inout`), which pushes us even further away from
the ML argument model.
Many users have observed the uselessness of our currying feature, and asked for
Scala-style `f(_, 1)` freeform partial application as an alternative. The fact
that even functionally-oriented users don't see much value in our currying
feature makes me feel like we might be better off without it. It definitely fails
the "would we add it if we didn't have it already" test.
## Detailed design
We remove support for multiple argument patterns in `func` declarations,
reducing the grammar for `func-signature` to allow only one `argument` clause.
For migration purposes, existing code that uses currying declaration syntax
can be transformed to explicitly return a closure instead:
```swift
// Before:
func curried(x: Int)(y: String) -> Float {
return Float(x) + Float(y)!
}
// After:
func curried(x: Int) -> (String) -> Float {
return {(y: String) -> Float in
return Float(x) + Float(y)!
}
}
```
I don't propose changing the semantics of methods, which formally remain
functions of type `Self -> Args -> Return`.
## Impact on existing code
This is removing a language feature, so will obviously break existing code
that uses the feature. We feel that currying is of sufficiently marginal
utility, runs against the grain of emerging language practice, and there's a
reasonable automatic migration, so the impact is acceptable in order to
simplify the language.
## Alternatives considered
The alternative would be to preserve currying as-is, which as discussed above,
is not ideal. Although I don't propose taking any immediate action, future
alternative designs to provide similar functionality in a more idiomatic way
include:
- Scala-like ad-hoc partial application syntax, such that something like
`foo(_, bar: 2)` would be shorthand for `{ x in foo(x, bar: 2) }`. This
has the benefit of arguably being more readable with our keyword-argument-
oriented API design, and also more flexible than traditional currying,
which requires argument order to be preconsidered by the API designer.
- Method and/or operator slicing syntax. We have `self.method` to partially
bind a method to its `self` parameter, and could potentially add
`.method(argument)` to partially bind a method to its non-self arguments,
which would be especially useful for higher-order methods like `map`
and `filter`. Haskell-like `(2+)`/`(+2)` syntax for partially applying
operators might also be nice.
================================================
FILE: proposals/0003-remove-var-parameters.md
================================================
# Removing `var` from Function Parameters
* Proposal: [SE-0003](0003-remove-var-parameters.md)
* Author: [Ashley Garland](https://github.com/bitjammer)
* Review Manager: [Joe Pamer](https://github.com/jopamer)
* Status: **Implemented (Swift 3.0)**
* Decision Notes: [Rationale](https://forums.swift.org/t/se-0003-removing-var-from-function-parameters-and-pattern-matching/1230)
* Implementation: [apple/swift@8a5ed40](https://github.com/apple/swift/commit/8a5ed405bf1f92ec3fc97fa46e52528d2e8d67d9)
## Note
This proposal underwent some major changes from its original form. See
the end of this document for historical information and why this
proposal changed.
## Introduction
There has been some confusion of semantics when a function parameter is
marked as `inout` compared to `var`. Both give a mutable local copy of a
value but parameters marked `inout` are automatically written back.
Function parameters are immutable by default:
```swift
func foo(i: Int) {
i += 1 // illegal
}
func foo(var i: Int) {
i += 1 // OK, but the caller cannot observe this mutation.
}
```
Here, the *local copy* of `x` mutates but the write does not propagate back to
the original value that was passed, so the caller can never observe the change
directly. For that to happen to value types, you have to mark the parameter
with `inout`:
```swift
func doSomethingWithVar(var i: Int) {
i = 2 // This will NOT have an effect on the caller's Int that was passed, but i can be modified locally
}
func doSomethingWithInout(inout i: Int) {
i = 2 // This will have an effect on the caller's Int that was passed.
}
var x = 1
print(x) // 1
doSomethingWithVar(x)
print(x) // 1
doSomethingWithInout(&x)
print(x) // 2
```
## Motivation
Using `var` annotations on function parameters have limited utility,
optimizing for a line of code at the cost of confusion with `inout`,
which has the semantics most people expect. To emphasize the fact these
values are unique copies and don't have the write-back semantics of
`inout`, we should not allow `var` here.
In summary, the problems that motivate this change are:
- `var` is often confused with `inout` in function parameters.
- `var` is often confused to make value types have reference semantics.
- Function parameters are not refutable patterns like in *if-*,
*while-*, *guard-*, *for-in-*, and *case* statements.
## Design
This is a trivial change to the parser. In Swift 2.2, a deprecation
warning will be emitted while in Swift 3 it will become an error.
## Impact on existing code
As a purely mechanical migration away from these uses of `var`, a temporary
variable can be immediately introduced that shadows the immutable copy in all of
the above uses. For example:
```swift
func foo(i: Int) {
var i = i
}
```
However, shadowing is not necessarily an ideal fix and may indicate an
anti-pattern. We expect users of Swift to rethink some of their existing
code where these are used but it is not strictly necessary to react to
this language change.
## Alternatives considered
This proposal originally included removal of `var` bindings for all
refutable patterns as well as function parameters.
[Original SE-0003 Proposal](https://github.com/swiftlang/swift-evolution/blob/8cd734260bc60d6d49dbfb48de5632e63bf200cc/proposals/0003-remove-var-parameters-patterns.md)
Removal of `var` from refutable patterns was reconsidered due to the
burden it placed on valid mutation patterns already in use in Swift 2
code. You can view the discussion on the swift-evolution mailing list
here:
[Initial Discussion of Reconsideration](https://forums.swift.org/t/reconsidering-se-0003-removing-var-from-function-parameters-and-pattern-matching/1159)
The rationale for a final conclusion was also sent to the
swift-evolution list, which you can view here:
[Note on Revision of the Proposal](https://forums.swift.org/t/se-0003-removing-var-from-function-parameters-and-pattern-matching/1230)
================================================
FILE: proposals/0004-remove-pre-post-inc-decrement.md
================================================
# Remove the `++` and `--` operators
* Proposal: [SE-0004](0004-remove-pre-post-inc-decrement.md)
* Author: [Chris Lattner](https://github.com/lattner)
* Status: **Implemented (Swift 3.0)**
* Implementation: [apple/swift@8e12008](https://github.com/apple/swift/commit/8e12008d2b34a605f8766310f53d5668f3d50955)
## Introduction
The increment/decrement operators in Swift were added very early in the
development of Swift, as a carry-over from C. These were added without much
consideration, and haven't been thought about much since then. This document
provides a fresh look at them, and ultimately recommends we just remove them
entirely, since they are confusing and not carrying their weight.
As a quick refresher, there are four operators in this family:
```swift
let a = ++x // pre-increment - returns input value after mutation
let b = x++ // post-increment - returns copy of input value before mutation
let c = --x // pre-decrement - returns input value after mutation
let d = x-- // post-decrement - returns copy of input value before mutation
```
However, the result value of these operators are frequently ignored.
## Advantages of These Operators
The primary advantage of these operators is their expressive capability. They
are shorthand for (e.g.) `x += 1` on a numeric type, or `x.advance()` on an
iterator-like value. When the return value is needed, the Swift `+=` operator
cannot be used in-line, since (unlike C) it returns `Void`.
The second advantage of Swift supporting this family of operators is continuity
with C, and other common languages in the extended C family (C++, Objective-C,
Java, C#, Javascript, etc). People coming to Swift from these other languages
may reasonably expect these operators to exist. That said, there are also
popular languages which have kept the majority of C operators but dropped these
(e.g. Python).
## Disadvantages of These Operators
1. These operators increase the burden to learn Swift as a first programming
language - or any other case where you don't already know these operators from a
different language.
2. Their expressive advantage is minimal - `x++` is not much shorter
than `x += 1`.
3. Swift already deviates from C in that the `=`, `+=` and other assignment-like
operations returns `Void` (for a number of reasons). These operators are
inconsistent with that model.
4. Swift has powerful features that eliminate many of the common reasons you'd
use `++i` in a C-style for loop in other languages, so these are relatively
infrequently used in well-written Swift code. These features include
the `for-in` loop, ranges, `enumerate`, `map`, etc.
5. Code that actually uses the result value of these operators is often
confusing and subtle to a reader/maintainer of code. They encourage "overly
tricky" code which may be cute, but difficult to understand.
6. While Swift has well defined order of evaluation, any code that depended on
it (like `foo(++a, a++)`) would be undesirable even if it was well-defined.
7. These operators are applicable to relatively few types: integer and floating
point scalars, and iterator-like concepts. They do not apply to complex numbers,
matrices, etc.
Finally, these fail the metric of "if we didn't already have these, would we add
them to Swift 3?"
## Proposed Approach
We should just drop these operators entirely. In terms of roll-out, we should
deprecate them in the Spring Swift 2.x release (with a nice Fixit hint to cover
common cases), and remove them completely in Swift 3.
## Alternatives considered
Simplest alternative: we could keep them. More interesting to consider, we could
change these operators to return Void. This solves some of the problems above,
but introduces a new question: once the result is gone, the difference between
the prefix and postfix form also vanishes. Given that, we would have to pick
between these unfortunate choices:
1) Keep both `x++` and `++x` in the language, even though they do the same
thing.
2) Drop one of `x++` or `++x`. C++ programmers generally prefer the prefix
forms, but everyone else generally prefers the postfix forms. Dropping either
one would be a significant deviation from C.
Despite considering these options carefully, they still don't justify the
complexity that the operators add to Swift.
================================================
FILE: proposals/0005-objective-c-name-translation.md
================================================
# Better Translation of Objective-C APIs Into Swift
* Proposal: [SE-0005](0005-objective-c-name-translation.md)
* Authors: [Doug Gregor](https://github.com/DougGregor), [Dave Abrahams](https://github.com/dabrahams)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.0)**
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0005-better-translation-of-objective-c-apis-into-swift/1668)
## Reviewer notes
This review is part of a group of three related reviews, running
concurrently:
* [SE-0023 API Design Guidelines](0023-api-guidelines.md)
([Review](https://forums.swift.org/t/review-se-0023-api-design-guidelines/1162))
* [SE-0006 Apply API Guidelines to the Standard Library](0006-apply-api-guidelines-to-the-standard-library.md)
([Review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163))
* [SE-0005 Better Translation of Objective-C APIs Into Swift](0005-objective-c-name-translation.md)
([Review](https://forums.swift.org/t/review-se-0005-better-translation-of-objective-c-apis-into-swift/1164))
These reviews are running concurrently because they interact strongly
(e.g., an API change in the standard library will correspond to a
particular guideline, or an importer rule implements a particular
guideline, etc.). Because of these interactions, and to keep
discussion manageable, we ask that you:
* **Please get a basic understanding of all three documents** before
posting review commentary
* **Please post your review of each individual document in response to
its review announcement**. It's okay (and encouraged) to make
cross-references between the documents in your review where it helps
you make a point.
## Introduction
This proposal describes how we can improve Swift's "Clang Importer", which is responsible for mapping C and Objective-C APIs into Swift, to translate the names of Objective-C functions, types, methods, properties, etc. into names that more closely align with the [Swift API Design Guidelines][api-design-guidelines] being developed as part of Swift 3. Our approach focuses on the differences between the Objective-C [Coding Guidelines for Cocoa][objc-cocoa-guidelines] and the Swift API Design Guidelines, using some simple linguistic analysis to aid the automatic translation from Objective-C names to more "Swifty" names.
The results of this transformation can be seen in the [Swift 3 API Guidelines Review](https://github.com/apple/swift-3-api-guidelines-review) repository, which contains Swift projections of Objective-C APIs in Swift 2 ([`swift-2` branch](https://github.com/apple/swift-3-api-guidelines-review/tree/swift-2)) and Swift 3 ([`swift-3` branch](https://github.com/apple/swift-3-api-guidelines-review/tree/swift-3)) along with partially-migrated sample code. One can also see the overall changes by [comparing the two branches](https://github.com/apple/swift-3-api-guidelines-review/compare/swift-2...swift-3).
## Motivation
The Objective-C [Coding Guidelines for Cocoa][objc-cocoa-guidelines]
provide a framework for creating clear, consistent APIs in
Objective-C, where they work extraordinarily well. However, Swift is a
different language: in particular, it is strongly typed and provides
type inference, generics, and overloading. As a result, Objective-C
APIs that feel right in Objective-C can feel wordy when used in
Swift. For example:
```swift
let content = listItemView.text.stringByTrimmingCharactersInSet(
NSCharacterSet.whitespaceAndNewlineCharacterSet())
```
The APIs used here follow the Objective-C guidelines. A more "Swifty"
version of the same code might instead look like this:
```swift
let content = listItemView.text.trimming(.whitespaceAndNewlines)
```
The latter example more closely adheres to the [Swift API Design
Guidelines][api-design-guidelines], in particular, omitting "needless"
words that restate the types already enforced by the compiler (view,
string, character set, etc.). The goal of this proposal is to make
imported Objective-C feel more "Swifty", providing a more fluid
experience for Swift programmers using Objective-C APIs.
The solution in this proposal applies equally to the Objective-C
frameworks (e.g., all of Cocoa and Cocoa Touch) and any Objective-C
APIs that are available to Swift in mix-and-match projects. Note that
the [Swift core libraries][core-libraries]
reimplement the APIs of Objective-C frameworks, so any API changes to
those frameworks (Foundation, XCTest, etc.) will be reflected in the
Swift 3 implementations of the core libraries.
## Proposed solution
The proposed solution involves identifying the differences between the
Objective-C [Coding Guidelines for Cocoa][objc-cocoa-guidelines] and
the [Swift API Design Guidelines][api-design-guidelines] to build a
set of transformations that map from the former to the latter based on
the guidelines themselves and other observed conventions in
Objective-C. This is an extension of other heuristics in the Clang
importer that translate names, e.g., the mapping of global enum
constants into Swift's cases (which strips common prefixes from the
enum constant names) and the mapping from Objective-C factory methods
(e.g., `+[NSNumber numberWithBool:]`) to Swift initializers
(`NSNumber(bool: true)`).
The heuristics described in this proposal will require iteration,
tuning, and experimentation across a large body of Objective-C APIs to
get right. Moreover, it will not be perfect: some APIs will
undoubtedly end up being less clear in Swift following this
translation than they had been before. Therefore, the goal is to make
the vast majority of imported Objective-C APIs feel more "Swifty", and
allow the authors of Objective-C APIs that end up being less clear to
address those problems on a per-API basis via annotation within the
Objective-C headers.
The proposed solution involves several related changes to the Clang importer:
1. **Generalize the applicability of the `swift_name` attribute**: The
Clang `swift_name` attribute currently allows limited renaming of enum
cases and factory methods. It should be generalized to allow arbitrary
renaming of any C or Objective-C entity when it is imported into
Swift, allowing authors of C or Objective-C APIs more fine-grained
control over the process.
2. **Prune redundant type names**: The Objective-C Coding Guidelines
for Cocoa require that the method describe each argument. When
those descriptions restate the type of the corresponding parameter,
the name conflicts with the
[omit needless words](https://swift.org/documentation/api-design-guidelines#omit-needless-words)
guideline for Swift APIs. Therefore, we prune these type names
during import.
3. **Add default arguments**: In cases where the Objective-C API strongly hints at the need for a default argument, infer the default argument when importing the API. For example, an option-set parameter can be defaulted to `[]`.
4. **Add first argument labels**: If the first parameter of a method
is defaulted,
[it should have an argument label](https://swift.org/documentation/api-design-guidelines#first-argument-label). Determine
a first argument label for that method.
5. **Prepend "is" to Boolean properties**:
[Boolean properties should read as assertions on the receiver](https://swift.org/documentation/api-design-guidelines#boolean-assertions),
but the Objective-C Coding Guidelines for Cocoa
[prohibit the use of "is" on properties](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE). Import
such properties with "is" prepended.
6. **Lowercase values**: The Swift API Design Guidelines have non-type
declarations lowercased. Lowercase non-prefixed values whenever they
are imported, including enumerators (whether they end up in Swift as
enum cases or option sets) and any other properties/functions (e.g., a
property named `URLHandler` will be lowercased to `urlHandler`).
7. **Adopt Comparable to classes that implement** `compare(_:) -> NSComparisonResult`: The objective-c classes that implement compare all have declared a capability of being compared in an ordered manner. `Comparable` formalizes this declaration into an implementable operator by the import process.
To get a sense of what these transformations do, consider a portion of
the imported `UIBezierPath` API in Swift 2:
```swift
class UIBezierPath : NSObject, NSCopying, NSCoding {
convenience init(ovalInRect: CGRect)
func moveToPoint(_: CGPoint)
func addLineToPoint(_: CGPoint)
func addCurveToPoint(_: CGPoint, controlPoint1: CGPoint, controlPoint2: CGPoint)
func addQuadCurveToPoint(_: CGPoint, controlPoint: CGPoint)
func appendPath(_: UIBezierPath)
func bezierPathByReversingPath() -> UIBezierPath
func applyTransform(_: CGAffineTransform)
var empty: Bool { get }
func containsPoint(_: CGPoint) -> Bool
func fillWithBlendMode(_: CGBlendMode, alpha: CGFloat)
func strokeWithBlendMode(_: CGBlendMode, alpha: CGFloat)
func copyWithZone(_: NSZone) -> AnyObject
func encodeWithCoder(_: NSCoder)
}
```
And the same API imported under our current, experimental implementation of this proposal:
```swift
class UIBezierPath : NSObject, NSCopying, NSCoding {
convenience init(ovalIn rect: CGRect)
func move(to point: CGPoint)
func addLine(to point: CGPoint)
func addCurve(to endPoint: CGPoint, controlPoint1 controlPoint1: CGPoint, controlPoint2 controlPoint2: CGPoint)
func addQuadCurve(to endPoint: CGPoint, controlPoint controlPoint: CGPoint)
func append(_ bezierPath: UIBezierPath)
func reversing() -> UIBezierPath
func apply(_ transform: CGAffineTransform)
var isEmpty: Bool { get }
func contains(_ point: CGPoint) -> Bool
func fill(_ blendMode: CGBlendMode, alpha alpha: CGFloat)
func stroke(_ blendMode: CGBlendMode, alpha alpha: CGFloat)
func copy(with zone: NSZone = nil) -> AnyObject
func encode(with aCoder: NSCoder)
}
```
In the latter case, a number of words that restated type information
in the original APIs have been pruned. The result is closer to
following the Swift API Design Guidelines. For example, this shows
that Swift developers can now copy any object conforming to the
NSCopying with a simple call to `foo.copy()` instead of calling
`foo.copyWithZone(nil)`.
## Implementation Experience
An experimental implementation of this proposal is available in the
main Swift repository. There are a set of compiler flags that one can
use to see the results of applying this proposal to imported
Objective-C APIs (e.g., via the script in
`utils/omit-needless-words.py`) and to Swift code itself. The flags
are:
* `-enable-omit-needless-words`: this flag enables most of the changes
to the Clang importer (bullets 1, 2, 4, and 5 in the prior
section). It is currently suitable only for printing the Swift
interface to Objective-C modules (e.g., via `swift-ide-test`) in the
Swift master branch and [Swift 2.2 branch][swift-2_2-branch], and is enabled on the [Swift 3 API Guidelines branch][swift-3-api-guidelines-branch].
* `-enable-infer-default-arguments`: this flag enables inference of
default arguments in the Clang importer (bullet 3 in the prior
section).
* `-swift3-migration`: only available on the [Swift 2.2
branch][swift-2_2-branch], this flag performs basic migration from
Swift 2 names to the Swift 3 names via Fix-Its. Tied together with
other compiler flags (e.g., `-fixit-code`, `-fixit-all`) and a
script to collect and apply Fix-Its (in
`utils/apply-fixit-edits.py`), this flag provides a rudimentary
migrator that lets us see how Swift code would look under the
proposed changes, updating both declarations and use sites.
To actually get the "Swift 3 experience" of compiling code using these
names, one can use the [Swift 3 API Guidelines
branch][swift-3-api-guidelines-branch], which enables these features
by default along with the changes to the standard library.
## Detailed design
This section details the experimental implementation of rules 2-5 in prose. The actual implementation is available in the Swift source tree, mostly in the `omitNeedlessWords` functions of [lib/Basic/StringExtras.cpp](https://github.com/apple/swift/blob/master/lib/Basic/StringExtras.cpp).
The descriptions in this section are described in terms of the incoming Objective-C API. For example, Objective-C method names are "selectors", e.g., `startWithQueue:completionHandler:` is a selector with two selector pieces, `startWithQueue` and `completionHandler`. A direct mapping of this name into Swift would produce `startWithQueue(_:completionHandler:)`.
### Prune redundant type names
Objective-C API names often contain names of parameter and/or result
types that would be omitted in a Swift API. The following rules are
designed to identify and remove these
words. [[Omit Needless Words](https://swift.org/documentation/api-design-guidelines#omit-needless-words)]
#### Identifying type names
The matching process described below searches in a selector piece for
a suffix of a string called the **type name**, which is defined as follows:
* For most Objective-C types, the *type name* is the name under which
Swift imports the type, ignoring nullability. For example,
|Objective-C type | *Type Name* |
|-----------------------|--------------------------------------------|
|`float` |`Float` |
|`nullable NSString` |`String` |
|`UIDocument` |`UIDocument` |
|`nullable UIDocument` |`UIDocument` |
|`NSInteger` |`NSInteger` |
|`NSUInteger` |`NSUInteger` |
|`CGFloat` |`CGFloat` |
* When the Objective-C type is a block, the *type name* is "`Block`."
* When the Objective-C type is a pointer- or reference-to-function,
the *type name* is "`Function`."
* When the Objective-C type is a typedef other than `NSInteger`,
`NSUInteger`, or `CGFloat` (which follow the first rule above), the
*type name* is that of the underlying type. For example, when the
Objective-C type is `UILayoutPriority`, which is a typedef for
`float`, we try to match the string
"`Float`". [[Compensate for Weak Type Information](https://swift.org/documentation/api-design-guidelines#weak-type-information)]
#### Matching
In order to prune a redundant type name from a selector piece, we
need to match a substring of the selector that identifies the type.
A couple of basic rules govern all matches:
* **Matches begin and end at word boundaries** in both type names and
selector pieces. Word boundaries occur at the beginning and end of
a string, and before every capital letter.
Treating every capital letter as the beginning of a word allows us
to match uppercased acronyms without maintaining a special lists of
acronyms or prefixes:
<pre>
func documentFor<b>URL</b>(_: NS<b>URL</b>) -> NSDocument?
</pre>
while preventing partial-word mismatches:
<pre>
var thumbnailPre<b>view</b> : UI<b>View</b> // not matched
</pre>
* **Matched text extends to the end of the type name**. Because we
accept a match for *any suffix* of the type name, this code:
<pre>
func constraintEqualTo<b>Anchor</b>(anchor: NSLayout<b>Anchor</b>) -> NSLayoutConstraint?
</pre>
can be pruned as follows:
<pre>
func constraintEqualTo(anchor: NSLayoutAnchor) -> NSLayoutConstraint?
</pre>
Conveniently, matching by suffix also means that module prefixes
such as `NS` do not prevent matching or pruning.
Matches are a sequence of one or more of the following:
* **Basic matches**
* Any substring of the selector piece matches an identical
substring of the type name, e.g., `String` in `appendString`
matches `String` in `NSString`:
<pre>
func append<b>String</b>(_: NS<b>String</b>)
</pre>
* `Index` in the selector piece matches `Int` in the type name:
<pre>
func characterAt<b>Index</b>(_: <b>Int</b>) -> unichar
</pre>
* **Collection matches**
* `Indexes` or `Indices` in the selector piece matches `IndexSet` in
the type name:
<pre>
func removeObjectsAt<b>Indexes</b>(_: NS<b>IndexSet</b>)
</pre>
* A plural noun in the selector piece matches a collection type name
if the noun's singular form matches the name of the collection's
element type:
<pre>
func arrange<b>Objects</b>(_: <b>[</b>Any<b>Object]</b>) -> [AnyObject]
</pre>
* **Special suffix matches**
* The empty string in the selector piece matches `Type` or `_t` in the type name:
<pre>
func writableTypesFor<b>SaveOperation</b>(_: NS<b>SaveOperation</b><i>Type</i>) -> [String]
func objectFor<b>Key</b>(_: <b>Key</b><i>Type</i>) -> AnyObject
func startWith<b>Queue</b>(_: dispatch_<b>queue</b><i>_t</i>, completionHandler: MKMapSnapshotCompletionhandler)
</pre>
* The empty string in the selector piece matches *one or more digits
followed by "D"* in the type name:
<pre>
func pointFor<b>Coordinate</b>(_: CLLocation<b>Coordinate</b><i>2D</i>) -> NSPoint
</pre>
In the examples above, the italic text is effectively skipped, so the
bold part of the selector piece can be matched and pruned.
#### Pruning Restrictions
The following restrictions govern the pruning steps listed in the
next section. If any step would violate one of these rules, it is
skipped.
* **Never make a selector piece entirely empty**.
* **Never transform the first selector piece into a Swift keyword**,
to avoid forcing the user to escape it with backticks. In Swift, the
first Objective-C selector piece becomes:
* the base name of a method
* or the full name of a property
neither of which can match a Swift keyword without forcing the
user to write backticks. For example,
<pre>
extension NSParagraphStyle {
class func default<b>ParagraphStyle</b>() -> NS<b>ParagraphStyle</b>
}
let defaultStyle = NSParagraphStyle.<b>default</b>ParagraphStyle() // OK
</pre>
would become:
<pre>
extension NSParagraphStyle {
class func <b>`default`</b>() -> NSParagraphStyle
}
let defaultStyle = NSParagraphStyle.<b>`default`</b>() // Awkward
</pre>
By contrast, later selector pieces become argument labels, which
are allowed to match Swift keywords without requiring backticks:
<pre>
receiver.handle(someMessage, <b>for</b>: somebody) // OK
</pre>
* **Never transform a name into "get", "set", "with", "for", or
"using"**, just to avoid creating absurdly vacuous names.
* **Never prune a suffix from a parameter introducer unless the suffix
is immediately preceded by a preposition, verb, or gerund**.
This heuristic has the effect of preventing us from breaking up
sequences of nouns that refer to a parameter. Dropping just the
suffix of a noun phrase tends to imply something unintended about
the parameter that follows. For example,
<pre>
func setText<b>Color</b>(_: UI<b>Color</b>)
...
button.<b>setTextColor</b>(.red()) <b>// clear</b>
</pre>
If we were to drop `Color`, leaving just `Text`, call sites
would become confusing:
<pre>
func setText(_: UIColor)
...
button.<b>setText</b>(.red()) <b>// appears to be setting the text!</b>
</pre>
Note: We don't maintain a list of nouns, but if we did, this
rule could be more simply phrased as "don't prune a suffix
leaving a trailing noun before a parameter".
* **Never prune a suffix from the base name of a method that matches a property of the enclosing class**:
This heuristic has the effect of preventing us from producing
too-generic names for methods that conceptually modify a property
of the class.
<pre>
var <b>gestureRecognizers</b>: [UIGestureRecognizer]
func add<b>GestureRecognizer</b>(_: UI<b>GestureRecognizer</b>)
</pre>
If we were to drop `GestureRecognizer`, leaving just `add`, we end
up with a method that conceptually modifies the
`gestureRecognizers` property but uses an overly generic name to
do so:
<pre>
var gestureRecognizers: [UIGestureRecognizer]
func add(_: UIGestureRecognizer) <b>// should indicate that we're adding to the property</b>
</pre>
#### Pruning Steps
The following pruning steps are performed in the order
shown:
1. **Prune the result type from the head of type-preserving
transforms**. Specifically, when
* the receiver type is the same as the result type
* and the type name is matched at the head of the first selector piece
* and the match is followed by a preposition
then prune the match.
You can think of the affected operations as properties or
non-mutating methods that produce a transformed version of the
receiver. For example:
<pre>
extension NS<b>Color</b> {
func <b>color</b><i>With</i>AlphaComponent(_: CGFloat) -> NS<b>Color</b>
}
let translucentForeground = <b>foregroundColor.color</b><i>With</i>AlphaComponent(0.5)
</pre>
becomes:
<pre>
extension NS<b>Color</b> {
func <i>with</i>AlphaComponent(_: CGFloat) -> NS<b>Color</b>
}
let translucentForeground = <b>foregroundColor</b>.<i>with</i>AlphaComponent(0.5)
</pre>
2. **Prune an additional hanging "By"**. Specifically, if
* anything was pruned in step 1
* and the remaining selector piece begins with "`By`" *followed by a gerund*,
then prune the initial "`By`" as well.
This heuristic allows us to arrive at usage of the form `a =
b.frobnicating(c)`. For example:
<pre>
extension NSString {
func string<b>By</b><i>Applying</i>Transform(_: NSString, reverse: Bool) -> NSString?
}
let sanitizedInput = rawInput.<b>stringByApplyingTransform</b>(NSStringTransformToXMLHex, reverse: false)
</pre>
becomes:
<pre>
extension NSString {
func applyingTransform(_: NSString, reverse: Bool) -> NString?
}
let sanitizedInput = rawInput.<b>applyingTransform</b>(NSStringTransformToXMLHex, reverse: false)
</pre>
3. **Prune a match for any type name in the signature from the tail of
the preceding selector piece**. Specifically,
|From the tail of: |Prune a match for: |
|------------------------------------------------|--------------------------------|
|a selector piece that introduces a parameter |the parameter type name |
|the name of a property |the property type name |
|the name of a zero-argument method |the return type name |
For example,
<pre>
extension NSDocumentController {
func documentFor<b>URL</b>(_ url: NS<b>URL</b>) -> NSDocument? // parameter introducer
}
extension NSManagedObjectContext {
var parent<b>Context</b>: NSManagedObject<b>Context</b>? // property
}
extension UIColor {
class func darkGray<b>Color</b>() -> UI<b>Color</b> // zero-argument method
}
...
myDocument = self.documentFor<b>URL</b>(locationOfFile)
if self.managedObjectContext.parent<b>Context</b> != changedContext { return }
foregroundColor = .darkGray<b>Color</b>()
</pre>
becomes:
<pre>
extension NSDocumentController {
func documentFor(_ url: NSURL) -> NSDocument?
}
extension NSManagedObjectContext {
var parent : NSManagedObjectContext?
}
extension UIColor {
class func darkGray() -> UIColor
}
...
myDocument = self.<b>documentFor</b>(locationOfFile)
if self.managedObjectContext.<b>parent</b> != changedContext { return }
foregroundColor = .<b>darkGray</b>()
</pre>
3. **Prune a match for the enclosing type from the base name of a method so long as the match starts after a verb**. For example,
<pre>
extension UI<b>ViewController</b> {
func dismiss<b>ViewController</b>Animated(flag: Bool, completion: (() -> Void)? = nil)
}
</pre>
becomes:
<pre>
extension UIViewController {
func dismissAnimated(flag: Bool, completion: (() -> Void)? = nil)
}
</pre>
##### Why Does Order Matter?
Some steps below prune matches from the head of the first selector
piece, and some prune from the tail. When [pruning restrictions](#pruning-restrictions)
prevent both the head and tail from being pruned, prioritizing
head-pruning steps can keep method families together. For example,
in NSFontDescriptor:
```swift
func fontDescriptorWithSymbolicTraits(_: NSFontSymbolicTraits) -> NSFontDescriptor
func fontDescriptorWithSize(_: CGFloat) -> UIFontDescriptor
func fontDescriptorWithMatrix(_: CGAffineTransform) -> UIFontDescriptor
...
```
becomes:
<pre>
func <b>with</b>SymbolicTraits(_: UIFontDescriptorSymbolicTraits) -> UIFontDescriptor
func <b>with</b>Size(_: CGFloat) -> UIFontDescriptor
func <b>with</b>Matrix(_: CGAffineTransform) -> UIFontDescriptor
...
</pre>
If we instead began by pruning `SymbolicTraits` from the tail of
the first method name, the prohibition against creating absurdly
vacuous names would prevent us from pruning "`fontDescriptorWith`"
down to "`with`", resulting in:
<pre>
func <b>fontDescriptorWith</b>(_: NSFontSymbolicTraits) -> NSFontDescriptor // inconsistent
func withSize(_: CGFloat) -> UIFontDescriptor
func withMatrix(_: CGAffineTransform) -> UIFontDescriptor
...
</pre>
#### Add Default Arguments
For any method that is not a single-parameter setter, default
arguments are added to parameters in the following cases:
* **Nullable trailing closure parameters** are given a default value of `nil`.
* **Nullable NSZone parameters** are given a default value of `nil`. Zones are essentially unused in Swift and should always be ``nil``.
* **Option set types** whose type name contain the word "Options" are given a default value of `[]` (the empty option set).
* **NSDictionary parameters** with names that involve "options", "attributes", or "info" are given a default value of `[:]`.
Together, these heuristics allow code like:
<pre>
rootViewController.presentViewController(alert, animated: true<b>, completion: nil</b>)
UIView.animateWithDuration(
0.2, delay: 0.0, <b>options: [],</b> animations: { self.logo.alpha = 0.0 }) {
_ in self.logo.hidden = true
}
</pre>
to become:
```swift
rootViewController.present(alert, animated: true)
UIView.animateWithDuration(
0.2, delay: 0.0, animations: { self.logo.alpha = 0.0 }) { _ in self.logo.hidden = true }
```
#### Add First Argument Labels
If the first selector piece contains a preposition, **split the first
selector piece at the last preposition**, turning everything
starting with the last preposition into a *required* label for the
first argument.
As well as creating first argument label for a significant number of
APIs, this heuristic eliminates words that refer only to the first
argument from call sites where the argument's default value is
used. For example, instead of:
<pre>
extension UIBezierPath {
func enumerateObjects<b>With</b>(_: NSEnumerationOptions <b>= []</b>, using: (AnyObject, UnsafeMutablePointer<ObjCBool>) -> Void)
}
array.enumerateObjects<b>With</b>(.Reverse) { // OK
// ..
}
array.enumerateObjects<b>With</b>() { // ?? With what?
// ..
}
</pre>
we get:
<pre>
extension NSArray {
func enumerateObjects(<b>options</b> _: NSEnumerationOptions <b>= []</b>, using: (AnyObject, UnsafeMutablePointer<ObjCBool>) -> Void)
}
array.enumerateObjects(<b>options:</b> .Reverse) { // OK
// ..
}
array.enumerateObjects() { // OK
// ..
}
</pre>
#### Use getter names for Boolean Properties
**For Boolean properties, use the name of the getter as the property
name in Swift*. For example:
```swift
@interface NSBezierPath : NSObject
@property (readonly,getter=isEmpty) BOOL empty;
```
will become
<pre>
extension NSBezierPath {
var <b>isEmpty</b>: Bool
}
if path.<b>isEmpty</b> { ... }
</pre>
### Conformance of implementers of compare method
Currently, in comparing protocols, for example developers usually have
to extend `NSDate` to make it to conform to `Comparable`, or use
`compare(_:) -> NSComparisonResult` method of `NSDate` directly. In
this case Using comparison operators on `NSDate`s will make the code
more readable, such as `someDate < today`, rather than
`someDate.compare(today) == .OrderedAscending`. Since the import process
can determine if a class implements the objective-c method for
comparison all classes that implement this method will then be imported
as adopting `Comparable`.
A survey of Foundation classes reveals not just NSDate but a few
other classes that would be affected by this change.
```swift
func compare(other: NSDate) -> NSComparisonResult
func compare(decimalNumber: NSNumber) -> NSComparisonResult
func compare(otherObject: NSIndexPath) -> NSComparisonResult
func compare(string: String) -> NSComparisonResult
func compare(otherNumber: NSNumber) -> NSComparisonResult
```
## Impact on existing code
The proposed changes are massively source-breaking for Swift code that
makes use of Objective-C frameworks, and will require a migrator to
translate Swift 2 code into Swift 3 code. The `-swift3-migration`
flag described in the [Implementation
Experience](#implementation-experience) section can provide the basics
for such a migrator. Additionally, the compiler needs to provide good
error messages (with Fix-Its) for Swift code that refers to the old
(pre-transformed) Objective-C names, which could be achieved with some
combination of the Fix-Its described previously and a secondary name
lookup mechanism retaining the old names.
## Acknowledgments
The automatic translation described in this proposal has been
developed as part of the effort to produce the [Swift API Design
Guidelines][api-design-guidelines] with Dmitri Hrybenko, Ted Kremenek,
Chris Lattner, Alex Migicovsky, Max Moiseev, Ali Ozer, and Tony Parker.
The addendum of comparable was originally proposed to the [core-libraries]
mailing list by [Chris Amanse](https://github.com/chrisamanse) and modified
to fit to this proposal after review by Philippe Hausler.
[objc-cocoa-guidelines]: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html "Coding Guidelines for Cocoa"
[api-design-guidelines]: https://swift.org/documentation/api-design-guidelines "API Design Guidelines"
[core-libraries]: https://swift.org/core-libraries/ "Swift Core Libraries"
[swift-3-api-guidelines-branch]: https://github.com/apple/swift/tree/swift-3-api-guidelines "Swift 3 API Guidelines branch"
[swift-2_2-branch]: https://github.com/apple/swift/tree/swift-2.2-branch "Swift 2.2 branch"
================================================
FILE: proposals/0006-apply-api-guidelines-to-the-standard-library.md
================================================
# Apply API Guidelines to the Standard Library
* Proposal: [SE-0006](0006-apply-api-guidelines-to-the-standard-library.md)
* Authors: [Dave Abrahams](https://github.com/dabrahams), [Dmitri Gribenko](https://github.com/gribozavr), [Maxim Moiseev](https://github.com/moiseev)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.0)**
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0006-apply-api-guidelines-to-the-standard-library/1667)
## Reviewer notes
This review is part of a group of three related reviews, running
concurrently:
* [SE-0023 API Design Guidelines](0023-api-guidelines.md)
([Review](https://forums.swift.org/t/review-se-0023-api-design-guidelines/1162))
* [SE-0006 Apply API Guidelines to the Standard Library](0006-apply-api-guidelines-to-the-standard-library.md)
([Review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163))
* [SE-0005 Better Translation of Objective-C APIs Into Swift](0005-objective-c-name-translation.md)
([Review](https://forums.swift.org/t/review-se-0005-better-translation-of-objective-c-apis-into-swift/1164))
These reviews are running concurrently because they interact strongly
(e.g., an API change in the standard library will correspond to a
particular guideline, or an importer rule implements a particular
guideline, etc.). Because of these interactions, and to keep
discussion manageable, we ask that you:
* **Please get a basic understanding of all three documents** before
posting review commentary
* **Please post your review of each individual document in response to
its review announcement**. It's okay (and encouraged) to make
cross-references between the documents in your review where it helps
you make a point.
## Introduction
[Swift API Design Guidelines][api-design-guidelines] being developed as
part of Swift 3. It is important that the Standard Library is an exemplar of
Swift API Design Guidelines: the APIs from the Standard Library are, probably,
the most frequently used Swift APIs in any application domain; the Standard
Library also sets precedent for other libraries.
In this project, we are reviewing the entire Standard Library and updating it
to follow the guidelines.
## Proposed solution
The actual work is being performed on the [swift-3-api-guidelines
branch][swift-3-api-guidelines-branch] of the [Swift repository][swift-repo].
On high level, the changes can be summarized as follows.
* Strip `Type` suffix from protocol names. In a few special cases
this means adding a `Protocol` suffix to get out of the way of type
names that are primary (though most of these we expect to be
obsoleted by Swift 3 language features).
* The concept of `generator` is renamed to `iterator` across all APIs.
* The type `Bit`, which was only used as the index for `CollectionOfOne`, was
removed. We recommend using `Int` instead.
* The generic parameter name in unsafe pointer types was renamed from `Memory`
to `Pointee`.
* No-argument initializers were removed from unsafe pointer types. We
recommend using the `nil` literal instead.
* `PermutationGenerator` was removed.
* `MutableSliceable` was removed. Use `Collection where SubSequence :
MutableCollection` instead.
* `sort()` => `sorted()`, `sortInPlace()` => `sort()`.
* `reverse()` => `reversed()`.
* `enumerate()` => `enumerated()`.
* `partition()` API was simplified. It composes better with collection slicing
now.
* `SequenceType.minElement()` => `.min()`, `.maxElement()` => `.max()`.
* Some initializers for sequence and collection adapters were removed. We
suggest calling the corresponding algorithm function or method instead.
* Some functions were changed into properties and vice versa.
* `String` factory methods dealing with nul-terminated UTF-8 data (a.k.a.
C-strings) became initializers.
## API diffs
Differences between Swift 2.2 Standard library API and the proposed API are
added to this section as they are being implemented on the
[swift-3-api-guidelines branch][swift-3-api-guidelines-branch].
For repetitive changes that affect many types, only one representative instance
is shown in the diff. For example, `generate()` was renamed to
`makeIterator()`. We only show the diff for the protocol requirement, and all
other renames of this method are implied. If a type was renamed, we show only
the diff for the type declaration, all other effects on the API where the name
is used are implied.
* Strip `Type` suffix from protocol names.
```diff
-public protocol BooleanType { ... }
+public protocol Boolean { ... }
-public protocol SequenceType { ... }
+public protocol Sequence { ... }
-public protocol CollectionType : ... { ... }
+public protocol Collection : ... { ... }
-public protocol MutableCollectionType : ... { ... }
+public protocol MutableCollection : ... { ... }
-public protocol RangeReplaceableCollectionType : ... { ... }
+public protocol RangeReplaceableCollection : ... { ... }
-public protocol AnyCollectionType : ... { ... }
+public protocol AnyCollectionProtocol : ... { ... }
-public protocol IntegerType : ... { ... }
+public protocol Integer : ... { ... }
-public protocol SignedIntegerType : ... { ... }
+public protocol SignedInteger : ... { ... }
-public protocol UnsignedIntegerType : ... { ... }
+public protocol UnsignedInteger : ... { ... }
-public protocol FloatingPointType : ... { ... }
+public protocol FloatingPoint : ... { ... }
-public protocol ForwardIndexType { ... }
+public protocol ForwardIndex { ... }
-public protocol BidirectionalIndexType : ... { ... }
+public protocol BidirectionalIndex : ... { ... }
-public protocol RandomAccessIndexType : ... { ... }
+public protocol RandomAccessIndex : ... { ... }
-public protocol IntegerArithmeticType : ... { ... }
+public protocol IntegerArithmetic : ... { ... }
-public protocol SignedNumberType : ... { ... }
+public protocol SignedNumber : ... { ... }
-public protocol IntervalType : ... { ... }
+public protocol Interval : ... { ... }
-public protocol LazyCollectionType : ... { ... }
+public protocol LazyCollectionProtocol : ... { ... }
-public protocol LazySequenceType : ... { ... }
+public protocol LazySequenceProtocol : ... { ... }
-public protocol OptionSetType : ... { ... }
+public protocol OptionSet : ... { ... }
-public protocol OutputStreamType : ... { ... }
+public protocol OutputStream : ... { ... }
-public protocol BitwiseOperationsType { ... }
+public protocol BitwiseOperations { ... }
-public protocol ReverseIndexType : ... { ... }
+public protocol ReverseIndexProtocol : ... { ... }
-public protocol SetAlgebraType : ... { ... }
+public protocol SetAlgebra : ... { ... }
-public protocol UnicodeCodecType { ... }
+public protocol UnicodeCodec { ... }
-public protocol CVarArgType { ... }
+public protocol CVarArg { ... }
-public protocol MirrorPathType { ... }
+public protocol MirrorPath { ... }
-public protocol ErrorType { ... }
+public protocol ErrorProtocol { ... }
```
* The concept of "generator" is renamed to "iterator" across all APIs.
```diff
-public protocol GeneratorType { ... }
+public protocol IteratorProtocol { ... }
public protocol Collection : ... {
- associatedtype Generator : GeneratorType = IndexingGenerator<Self>
+ associatedtype Iterator : IteratorProtocol = IndexingIterator<Self>
- func generate() -> Generator
+ func makeIterator() -> Iterator
}
-public struct IndexingGenerator<Elements : Indexable> : ... { ... }
+public struct IndexingIterator<Elements : Indexable> : ... { ... }
-public struct GeneratorOfOne<Element> : ... { ... }
+public struct IteratorOverOne<Element> : ... { ... }
-public struct EmptyGenerator<Element> : ... { ... }
+public struct EmptyIterator<Element> : ... { ... }
-public struct AnyGenerator<Element> : ... { ... }
+public struct AnyIterator<Element> : ... { ... }
-public struct LazyFilterGenerator<Base : GeneratorType> : ... { ... }
+public struct LazyFilterIterator<Base : IteratorProtocol> : ... { ... }
-public struct FlattenGenerator<Base : ...> : ... { ... }
+public struct FlattenIterator<Base : ...> : ... { ... }
-public struct JoinGenerator<Base : ...> : ... { ... }
+public struct JoinedIterator<Base : ...> : ... { ... }
-public struct LazyMapGenerator<Base : ...> ... { ... }
+public struct LazyMapIterator<Base : ...> ... { ... }
-public struct RangeGenerator<Element : ForwardIndexType> : ... { ... }
+public struct RangeIterator<Element : ForwardIndex> : ... { ... }
-public struct GeneratorSequence<Base : GeneratorType> : ... { ... }
+public struct IteratorSequence<Base : IteratorProtocol> : ... { ... }
-public struct StrideToGenerator<Element : Strideable> : ... { ... }
+public struct StrideToIterator<Element : Strideable> : ... { ... }
-public struct StrideThroughGenerator<Element : Strideable> : ... { ... }
+public struct StrideThroughIterator<Element : Strideable> : ... { ... }
-public struct UnsafeBufferPointerGenerator<Element> : ... { ... }
+public struct UnsafeBufferPointerIterator<Element> : ... { ... }
```
* The type `Bit`, which was only used as the index for `CollectionOfOne`, was
removed. We recommend using `Int` instead.
```diff
-public enum Bit : ... { ... }
```
* `PermutationGenerator` was removed.
```diff
-public struct PermutationGenerator<
- C : CollectionType, Indices : SequenceType
- where C.Index == Indices.Generator.Element
-> : ... { ... }
```
* `MutableSliceable` was removed. Use `Collection where SubSequence :
MutableCollection` instead.
```diff
-public protocol MutableSliceable : CollectionType, MutableCollectionType {
- subscript(_: Range<Index>) -> SubSequence { get set }
-}
```
* The generic parameter name in unsafe pointer types was renamed from `Memory`
to `Pointee`.
* No-argument initializers were removed from unsafe pointer types. We
recommend using the `nil` literal instead.
```diff
// The same changes applied to `UnsafePointer`, `UnsafeMutablePointer` and
// `AutoreleasingUnsafeMutablePointer`.
public struct UnsafePointer<
- Memory
+ Pointee
> ... : {
- public var memory: Memory { get set }
+ public var pointee: Pointee { get set }
// Use `nil` instead.
- public init()
}
public struct OpaquePointer : ... {
// Use `nil` instead.
- public init()
}
```
* `sort()` => `sorted()`, `sortInPlace()` => `sort()`. We also added argument
labels to closures.
```diff
extension Sequence where Self.Iterator.Element : Comparable {
@warn_unused_result
- public func sort() -> [Generator.Element]
+ public func sorted() -> [Iterator.Element]
}
extension Sequence {
@warn_unused_result
- public func sort(
+ public func sorted(
- @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
) -> [Iterator.Element]
}
extension MutableCollection where Self.Iterator.Element : Comparable {
@warn_unused_result(mutable_variant="sort")
- public func sort() -> [Generator.Element]
+ public func sorted() -> [Iterator.Element]
}
extension MutableCollection {
@warn_unused_result(mutable_variant="sort")
- public func sort(
+ public func sorted(
- @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
) -> [Iterator.Element]
}
extension MutableCollection
where
Self.Index : RandomAccessIndex,
Self.Iterator.Element : Comparable {
- public mutating func sortInPlace()
+ public mutating func sort()
}
extension MutableCollection where Self.Index : RandomAccessIndex {
- public mutating func sortInPlace(
+ public mutating func sort(
- @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
)
}
```
* `reverse()` => `reversed()`.
```diff
extension SequenceType {
- public func reverse() -> [Generator.Element]
+ public func reversed() -> [Iterator.Element]
}
extension CollectionType where Index : BidirectionalIndexType {
- public func reverse() -> ReverseCollection<Self>
+ public func reversed() -> ReverseCollection<Self>
}
extension CollectionType where Index : RandomAccessIndexType {
- public func reverse() -> ReverseRandomAccessCollection<Self>
+ public func reversed() -> ReverseRandomAccessCollection<Self>
}
extension LazyCollectionProtocol
where Index : BidirectionalIndexType, Elements.Index : BidirectionalIndexType {
- public func reverse()
+ public func reversed()
-> LazyCollection<ReverseCollection<Elements>>
}
extension LazyCollectionProtocol
where Index : RandomAccessIndexType, Elements.Index : RandomAccessIndexType {
- public func reverse()
+ public func reversed()
-> LazyCollection<ReverseRandomAccessCollection<Elements>>
}
```
* `enumerate()` => `enumerated()`.
```diff
extension Sequence {
- public func enumerate() -> EnumerateSequence<Self>
+ public func enumerated() -> EnumeratedSequence<Self>
}
-public struct EnumerateSequence<Base : SequenceType> : ... { ... }
+public struct EnumeratedSequence<Base : Sequence> : ... { ... }
-public struct EnumerateGenerator<Base : GeneratorType> : ... { ... }
+public struct EnumeratedIterator<Base : IteratorProtocol> : ... { ... }
```
* `partition()` API was simplified: the range argument was removed. It
composes better with collection slicing now, and is more uniform with other
collection algorithms. We also added `@noescape` and an argument label to
the closure.
```diff
extension MutableCollection where Index : RandomAccessIndex {
public mutating func partition(
- range: Range<Index>,
- isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
) -> Index
}
extension MutableCollection
where Index : RandomAccessIndex, Iterator.Element : Comparable {
- public mutating func partition(range: Range<Index>) -> Index
+ public mutating func partition() -> Index
}
```
* `SequenceType.minElement()` => `.min()`, `.maxElement()` => `.max()`. We
also added argument labels to closures.
```diff
extension Sequence {
- public func minElement(
+ public func min(
- @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) throws -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Iterator.Element?
- public func maxElement(
+ public func max(
- @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) throws -> Bool
+ @noescape isOrderedBefore isOrderedBefore: (Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Iterator.Element?
}
extension Sequence where Iterator.Element : Comparable {
- public func minElement() -> Iterator.Element?
+ public func min() -> Iterator.Element?
- public func maxElement() -> Iterator.Element?
+ public func max() -> Iterator.Element?
}
```
* Some initializers for sequence, collection and iterator adapters were
removed. We suggest calling the corresponding algorithm function or
method instead.
```diff
extension Repeated {
- public init(count: Int, repeatedValue: Element)
}
+/// Return a collection containing `n` repetitions of `elementInstance`.
+public func repeatElement<T>(element: T, count n: Int) -> Repeated<T>
public struct LazyMapSequence<Base : Sequence, Element> : ... {
// Call `.lazy.map` on the sequence instead.
- public init(_ base: Base, transform: (Base.Generator.Element) -> Element)
}
public struct LazyMapCollection<Base : Collection, Element> : ... {
// Call `.lazy.map` on the collection instead.
- public init(_ base: Base, transform: (Base.Generator.Element) -> Element)
}
public struct LazyFilterIterator<Base : IteratorProtocol> : ... {
// Call `.lazy.filter` on the sequence instead.
- public init(
- _ base: Base,
- whereElementsSatisfy predicate: (Base.Element) -> Bool
- )
}
public struct RangeIterator<Element : ForwardIndex> : ... {
// Use the 'generate()' method on the collection instead.
- public init(_ bounds: Range<Element>)
// Use the '..<' operator.
- public init(start: Element, end: Element)
}
public struct ReverseCollection<Base : ...> : ... {
// Use the 'reverse()' method on the collection.
- public init(_ base: Base)
}
public struct ReverseRandomAccessCollection<Base : ...> : ... {
// Use the 'reverse()' method on the collection.
- public init(_ base: Base)
}
public struct Slice<Base : Indexable> : ... {
// Use the slicing syntax.
- public init(base: Base, bounds: Range<Index>)
}
public struct MutableSlice<Base : MutableIndexable> : ... {
// Use the slicing syntax.
- public init(base: Base, bounds: Range<Index>)
}
public struct EnumeratedIterator<Base : IteratorProtocol> : ... {
// Use the 'enumerated()' method.
- public init(_ base: Base)
}
public struct EnumeratedSequence<Base : IteratorProtocol> : ... {
// Use the 'enumerated()' method.
- public init(_ base: Base)
}
public struct IndexingIterator<Elements : Indexable> : ... {
// Call 'iterator()' on the collection instead.
- public init(_elements: Elements)
}
public struct HalfOpenInterval<Bound : Comparable> : ... {
// Use the '..<' operator.
- public init(_ start: Bound, _ end: Bound)
}
public struct ClosedInterval<Bound : Comparable> : ... {
// Use the '...' operator.
- public init(_ start: Bound, _ end: Bound)
}
```
* Some functions were changed into properties and vice versa.
```diff
-public func unsafeUnwrap<T>(nonEmpty: T?) -> T
extension Optional {
+ public var unsafelyUnwrapped: Wrapped { get }
}
public struct Mirror {
- public func superclassMirror() -> Mirror?
+ public var superclassMirror: Mirror? { get }
}
public protocol CustomReflectable {
- func customMirror() -> Mirror
+ var customMirror: Mirror { get }
}
public protocol Collection : ... {
- public func underestimateCount() -> Int
+ public var underestimatedCount: Int { get }
}
public protocol CustomPlaygroundQuickLookable {
- func customPlaygroundQuickLook() -> PlaygroundQuickLook
+ var customPlaygroundQuickLook: PlaygroundQuickLook { get }
}
extension String {
- public var lowercaseString: String { get }
+ public func lowercased()
- public var uppercaseString: String { get }
+ public func uppercased()
}
public enum UnicodeDecodingResult {
- public func isEmptyInput() -> Bool {
+ public var isEmptyInput: Bool
}
```
* Base names and argument labels were changed to follow guidelines about first
argument labels. (Some changes in this category are already specified
elsewhere in the diff and are not repeated.)
```diff
public protocol ForwardIndex {
- func advancedBy(n: Distance) -> Self
+ func advanced(by n: Distance) -> Self
- func advancedBy(n: Distance, limit: Self) -> Self
+ func advanced(by n: Distance, limit: Self) -> Self
- func distanceTo(end: Self) -> Distance
+ func distance(to end: Self) -> Distance
}
public struct Set<Element : Hashable> : ... {
- public mutating func removeAtIndex(index: Index) -> Element
+ public mutating func remove(at index: Index) -> Element
}
public struct Dictionary<Key : Hashable, Value> : ... {
- public mutating func removeAtIndex(index: Index) -> Element
+ public mutating func remove(at index: Index) -> Element
- public func indexForKey(key: Key) -> Index?
+ public func index(forKey key: Key) -> Index?
- public mutating func removeValueForKey(key: Key) -> Value?
+ public mutating func removeValue(forKey key: Key) -> Value?
}
extension Sequence where Iterator.Element : Sequence {
// joinWithSeparator(_:) => join(separator:)
- public func joinWithSeparator<
+ public func joined<
Separator : Sequence
where
Separator.Iterator.Element == Iterator.Element.Iterator.Element
- >(separator: Separator) -> JoinSequence<Self>
+ >(separator separator: Separator) -> JoinedSequence<Self>
}
extension Sequence where Iterator.Element == String {
- public func joinWithSeparator(separator: String) -> String
+ public func joined(separator separator: String) -> String
}
public class ManagedBuffer<Value, Element> : ... {
public final class func create(
- minimumCapacity: Int,
+ minimumCapacity minimumCapacity: Int,
initialValue: (ManagedProtoBuffer<Value, Element>) -> Value
) -> ManagedBuffer<Value, Element>
}
public protocol Streamable {
- func writeTo<Target : OutputStream>(inout target: Target)
+ func write<Target : OutputStream>(inout to target: Target)
}
public func dump<T, TargetStream : OutputStream>(
value: T,
- inout _ target: TargetStream,
+ inout to target: TargetStream,
name: String? = nil,
indent: Int = 0,
maxDepth: Int = .max,
maxItems: Int = .max
) -> T
extension Sequence {
- public func startsWith<
+ public func starts<
PossiblePrefix : Sequence where PossiblePrefix.Iterator.Element == Iterator.Element
>(
- possiblePrefix: PossiblePrefix,
+ with possiblePrefix: PossiblePrefix,
@noescape isEquivalent: (Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Bool
- public func startsWith<
+ public func starts<
PossiblePrefix : Sequence where PossiblePrefix.Iterator.Element == Iterator.Element
>(
- possiblePrefix: PossiblePrefix
+ with possiblePrefix: PossiblePrefix
) -> Bool
}
extension CollectionType where Iterator.Element : Equatable {
- public func indexOf(element: Iterator.Element) -> Index?
+ public func index(of element: Iterator.Element) -> Index?
}
extension CollectionType {
- public func indexOf(predicate: (Iterator.Element) throws -> Bool) rethrows -> Index?
+ public func index(where predicate: (Iterator.Element) throws -> Bool) rethrows -> Index?
}
extension String.Index {
- public func samePositionIn(utf8: String.UTF8View) -> String.UTF8View.Index
+ public func samePosition(in utf8: String.UTF8View) -> String.UTF8View.Index
- public func samePositionIn(utf16: String.UTF16View) -> String.UTF16View.Index
+ public func samePosition(in utf16: String.UTF16View) -> String.UTF16View.Index
- public func samePositionIn(unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
+ public func samePosition(in unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
}
extension String.UTF16View.Index {
- public func samePositionIn(characters: String) -> String.Index
+ public func samePosition(in characters: String) -> String.Index
- public func samePositionIn(utf8: String.UTF8View) -> String.UTF8View.Index
+ public func samePosition(in utf8: String.UTF8View) -> String.UTF8View.Index
- public func samePositionIn(unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
+ public func samePosition(in unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
}
extension String.UTF8View.Index {
- public func samePositionIn(characters: String) -> String.Index
+ public func samePosition(in characters: String) -> String.Index
- public func samePositionIn(utf16: String.UTF16View) -> String.UTF16View.Index
+ public func samePosition(in utf16: String.UTF16View) -> String.UTF16View.Index
- public func samePositionIn(unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
+ public func samePosition(in unicodeScalars: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
}
extension String.UnicodeScalarView.Index {
- public func samePositionIn(characters: String) -> String.Index
+ public func samePosition(in characters: String) -> String.Index
- public func samePositionIn(utf16: String.UTF16View) -> String.UTF16View.Index
+ public func samePosition(in utf16: String.UTF16View) -> String.UTF16View.Index
- public func samePositionIn(utf16: String.UTF16View) -> String.UTF16View.Index
+ public func samePosition(in utf16: String.UTF16View) -> String.UTF16View.Index
}
```
* Lowercase enum cases and static properties.
```diff
public struct Float {
- public static var NaN: Float
+ public static var nan: Float
}
public struct Double {
- public static var NaN: Double
+ public static var nan: Double
public struct CGFloat {
- public static var NaN: CGFloat
+ public static var nan: CGFloat
}
public protocol FloatingPoint : ... {
- static var NaN: Self { get }
+ static var nan: Self { get }
}
public enum FloatingPointClassification {
- case SignalingNaN
+ case signalingNaN
- case QuietNaN
+ case quietNaN
- case NegativeInfinity
+ case negativeInfinity
- case NegativeNormal
+ case negativeNormal
- case NegativeSubnormal
+ case negativeSubnormal
- case NegativeZero
+ case negativeZero
- case PositiveZero
+ case positiveZero
- case PositiveSubnormal
+ case positiveSubnormal
- case PositiveNormal
+ case positiveNormal
- case PositiveInfinity
+ case positiveInfinity
}
public enum ImplicitlyUnwrappedOptional<Wrapped> : ... {
- case None
+ case none
- case Some(Wrapped)
+ case some(Wrapped)
}
public enum Optional<Wrapped> : ... {
- case None
+ case none
- case Some(Wrapped)
+ case some(Wrapped)
}
public struct Mirror {
public enum AncestorRepresentation {
- case Generated
+ case generated
- case Customized(() -> Mirror)
+ case customized(() -> Mirror)
- case Suppressed
+ case suppressed
}
public enum DisplayStyle {
- case struct, class, enum, tuple, optional, collection
+ case `struct`, `class`, `enum`, tuple, optional, collection
- case dictionary, `set`
+ case dictionary, `set`
}
}
public enum PlaygroundQuickLook {
- case Text(String)
+ case text(String)
- case Int(Int64)
+ case int(Int64)
- case UInt(UInt64)
+ case uInt(UInt64)
- case Float(Float32)
+ case float(Float32)
- case Double(Float64)
+ case double(Float64)
- case Image(Any)
+ case image(Any)
- case Sound(Any)
+ case sound(Any)
- case Color(Any)
+ case color(Any)
- case BezierPath(Any)
+ case bezierPath(Any)
- case AttributedString(Any)
+ case attributedString(Any)
- case Rectangle(Float64,Float64,Float64,Float64)
+ case rectangle(Float64,Float64,Float64,Float64)
- case Point(Float64,Float64)
+ case point(Float64,Float64)
- case Size(Float64,Float64)
+ case size(Float64,Float64)
- case Logical(Bool)
+ case bool(Bool)
- case Range(Int64, Int64)
+ case range(Int64, Int64)
- case View(Any)
+ case view(Any)
- case Sprite(Any)
+ case sprite(Any)
- case URL(String)
+ case url(String)
- case _Raw([UInt8], String)
+ case _raw([UInt8], String)
}
```
* `String` factory methods dealing with nul-terminated UTF-8 data (a.k.a.
C-strings) became initializers.
```diff
extension String {
- public static func fromCString(cs: UnsafePointer<CChar>) -> String?
+ public init?(validatingUTF8 cString: UnsafePointer<CChar>)
- public static func fromCStringRepairingIllFormedUTF8(cs: UnsafePointer<CChar>) -> (String?, hadError: Bool)
+ public init(cString: UnsafePointer<CChar>)
+ public static func decodeCString<Encoding : UnicodeCodec>(
+ cString: UnsafePointer<Encoding.CodeUnit>,
+ as encoding: Encoding.Type,
+ repairingInvalidCodeUnits isReparing: Bool = true)
+ -> (result: String, repairsMade: Bool)?
}
```
* `String` methods that mirror imported methods on NSString are renamed to reflect the new importing rules.
```diff
extension String {
- public static func localizedNameOfStringEncoding(
- encoding: NSStringEncoding
- ) -> String
+ public static func localizedName(
+ ofStringEncoding encoding: NSStringEncoding
+ ) -> String
- public static func pathWithComponents(components: [String]) -> String
+ public static func path(withComponents components: [String]) -> String
- public init?(UTF8String bytes: UnsafePointer<CChar>)
+ public init?(utf8String bytes: UnsafePointer<CChar>)
- public func canBeConvertedToEncoding(encoding: NSStringEncoding) -> Bool
+ public func canBeConverted(toEncoding encoding: NSStringEncoding) -> Bool
- public var capitalizedString: String
+ public var capitalized: String
- public var localizedCapitalizedString: String
+ public var localizedCapitalized: String
- public func capitalizedStringWithLocale(locale: NSLocale?) -> String
+ public func capitalized(with locale: NSLocale?) -> String
- public func commonPrefixWithString(
- aString: String, options: NSStringCompareOptions) -> String
+ public func commonPrefix(
+ with aString: String, options: NSStringCompareOptions = []) -> String
- public func completePathIntoString(
- outputName: UnsafeMutablePointer<String> = nil,
- caseSensitive: Bool,
- matchesIntoArray: UnsafeMutablePointer<[String]> = nil,
- filterTypes: [String]? = nil
- ) -> Int
+ public func completePath(
+ into outputName: UnsafeMutablePointer<String> = nil,
+ caseSensitive: Bool,
+ matchesInto matchesIntoArray: UnsafeMutablePointer<[String]> = nil,
+ filterTypes: [String]? = nil
+ ) -> Int
- public func componentsSeparatedByCharactersInSet(
- separator: NSCharacterSet
- ) -> [String]
+ public func componentsSeparatedByCharacters(
+ in separator: NSCharacterSet
+ ) -> [String]
- public func componentsSeparatedByString(separator: String) -> [String]
+ public func componentsSeparated(by separator: String) -> [String]
- public func cStringUsingEncoding(encoding: NSStringEncoding) -> [CChar]?
+ public func cString(usingEncoding encoding: NSStringEncoding) -> [CChar]?
- public func dataUsingEncoding(
- encoding: NSStringEncoding,
- allowLossyConversion: Bool = false
- ) -> NSData?
+ public func data(
+ usingEncoding encoding: NSStringEncoding,
+ allowLossyConversion: Bool = false
+ ) -> NSData?
- public func enumerateLinguisticTagsInRange(
- range: Range<Index>,
- scheme tagScheme: String,
- options opts: NSLinguisticTaggerOptions,
- orthography: NSOrthography?,
- _ body:
- (String, Range<Index>, Range<Index>, inout Bool) -> ()
- )
+ public func enumerateLinguisticTags(
+ in range: Range<Index>,
+ scheme tagScheme: String,
+ options opts: NSLinguisticTaggerOptions = [],
+ orthography: NSOrthography? = nil,
+ _ body:
+ (String, Range<Index>, Range<Index>, inout Bool) -> ()
+ )
- public func enumerateSubstringsInRange(
- range: Range<Index>,
- options opts:NSStringEnumerationOptions,
- _ body: (
- substring: String?, substringRange: Range<Index>,
- enclosingRange: Range<Index>, inout Bool
- ) -> ()
- )
+ public func enumerateSubstrings(
+ in range: Range<Index>,
+ options opts:NSStringEnumerationOptions = [],
+ _ body: (
+ substring: String?, substringRange: Range<Index>,
+ enclosingRange: Range<Index>, inout Bool
+ ) -> ()
+ )
- public func fileSystemRepresentation() -> [CChar]
+ public var fileSystemRepresentation: [CChar]
- public func getBytes(
- inout buffer: [UInt8],
- maxLength maxBufferCount: Int,
- usedLength usedBufferCount: UnsafeMutablePointer<Int>,
- encoding: NSStringEncoding,
- options: NSStringEncodingConversionOptions,
- range: Range<Index>,
- remainingRange leftover: UnsafeMutablePointer<Range<Index>>
- ) -> Bool
+ public func getBytes(
+ inout buffer: [UInt8],
+ maxLength maxBufferCount: Int,
+ usedLength usedBufferCount: UnsafeMutablePointer<Int>,
+ encoding: NSStringEncoding,
+ options: NSStringEncodingConversionOptions = [],
+ range: Range<Index>,
+ remaining leftover: UnsafeMutablePointer<Range<Index>>
+ ) -> Bool
- public func getLineStart(
- start: UnsafeMutablePointer<Index>,
- end: UnsafeMutablePointer<Index>,
- contentsEnd: UnsafeMutablePointer<Index>,
- forRange: Range<Index>
- )
+ public func getLineStart(
+ start: UnsafeMutablePointer<Index>,
+ end: UnsafeMutablePointer<Index>,
+ contentsEnd: UnsafeMutablePointer<Index>,
+ for range: Range<Index>
+ )
- public func getParagraphStart(
- start: UnsafeMutablePointer<Index>,
- end: UnsafeMutablePointer<Index>,
- contentsEnd: UnsafeMutablePointer<Index>,
- forRange: Range<Index>
- )
+ public func getParagraphStart(
+ start: UnsafeMutablePointer<Index>,
+ end: UnsafeMutablePointer<Index>,
+ contentsEnd: UnsafeMutablePointer<Index>,
+ for range: Range<Index>
+ )
public init(
- contentsOfURL url: NSURL,
+ contentsOf url: NSURL,
encoding enc: NSStringEncoding
) throws
public init(
- contentsOfURL url: NSURL,
+ contentsOf url: NSURL,
usedEncoding enc: UnsafeMutablePointer<NSStringEncoding> = nil
) throws
public init?(
- CString: UnsafePointer<CChar>,
+ cString: UnsafePointer<CChar>,
encoding enc: NSStringEncoding
)
- public init(format: String, _ arguments: CVarArgType...)
+ public init(format: String, _ arguments: CVarArg...)
- public init(format: String, arguments: [CVarArgType])
+ public init(format: String, arguments: [CVarArg])
- public init(format: String, locale: NSLocale?, _ args: CVarArgType...)
+ public init(format: String, locale: NSLocale?, _ args: CVarArg...)
- public init(format: String, locale: NSLocale?, arguments: [CVarArgType])
+ public init(format: String, locale: NSLocale?, arguments: [CVarArg])
- public func lengthOfBytesUsingEncoding(encoding: NSStringEncoding) -> Int
+ public func lengthOfBytes(usingEncoding encoding: NSStringEncoding) -> Int
- public func lineRangeForRange(aRange: Range<Index>) -> Range<Index>
+ public func lineRange(for aRange: Range<Index>) -> Range<Index>
- public func linguisticTagsInRange(
- range: Range<Index>,
- scheme tagScheme: String,
- options opts: NSLinguisticTaggerOptions = [],
- orthography: NSOrthography? = nil,
- tokenRanges: UnsafeMutablePointer<[Range<Index>]> = nil // FIXME:Can this be nil?
- ) -> [String]
+ public func linguisticTags(
+ in range: Range<Index>,
+ scheme tagScheme: String,
+ options opts: NSLinguisticTaggerOptions = [],
+ orthography: NSOrthography? = nil,
+ tokenRanges: UnsafeMutablePointer<[Range<Index>]> = nil // FIXME:Can this be nil?
+ ) -> [String]
- public var localizedLowercaseString: String
+ public var localizedLowercase: String
- public func lowercaseStringWithLocale(locale: NSLocale?) -> String
+ public func lowercaseString(with locale: NSLocale?) -> String
- func maximumLengthOfBytesUsingEncoding(encoding: NSStringEncoding) -> Int
+ func maximumLengthOfBytes(usingEncoding encoding: NSStringEncoding) -> Int
- public func paragraphRangeForRange(aRange: Range<Index>) -> Range<Index>
+ public func paragraphRange(for aRange: Range<Index>) -> Range<Index>
- public func rangeOfCharacterFromSet(
- aSet: NSCharacterSet,
- options mask:NSStringCompareOptions = [],
- range aRange: Range<Index>? = nil
- ) -> Range<Index>?
+ public func rangeOfCharacter(
+ from aSet: NSCharacterSet,
+ options mask:NSStringCompareOptions = [],
+ range aRange: Range<Index>? = nil
+ ) -> Range<Index>?
- func rangeOfComposedCharacterSequenceAtIndex(anIndex: Index) -> Range<Index>
+ func rangeOfComposedCharacterSequence(at anIndex: Index) -> Range<Index>
- public func rangeOfComposedCharacterSequencesForRange(
- range: Range<Index>
- ) -> Range<Index>
+ public func rangeOfComposedCharacterSequences(
+ for range: Range<Index>
+ ) -> Range<Index>
- public func rangeOfString(
- aString: String,
- options mask: NSStringCompareOptions = [],
- range searchRange: Range<Index>? = nil,
- locale: NSLocale? = nil
- ) -> Range<Index>?
+ public func range(
+ of aString: String,
+ options mask: NSStringCompareOptions = [],
+ range searchRange: Range<Index>? = nil,
+ locale: NSLocale? = nil
+ ) -> Range<Index>?
- public func localizedStandardContainsString(string: String) -> Bool
+ public func localizedStandardContains(string: String) -> Bool
- public func localizedStandardRangeOfString(string: String) -> Range<Index>?
+ public func localizedStandardRange(of string: String) -> Range<Index>?
- public var stringByAbbreviatingWithTildeInPath: String
+ public var abbreviatingWithTildeInPath: String
- public func stringByAddingPercentEncodingWithAllowedCharacters(
- allowedCharacters: NSCharacterSet
- ) -> String?
+ public func addingPercentEncoding(
+ withAllowedCharacters allowedCharacters: NSCharacterSet
+ ) -> String?
- public func stringByAddingPercentEscapesUsingEncoding(
- encoding: NSStringEncoding
- ) -> String?
+ public func addingPercentEscapes(
+ usingEncoding encoding: NSStringEncoding
+ ) -> String?
- public func stringByAppendingFormat(
- format: String, _ arguments: CVarArgType...
- ) -> String
+ public func appendingFormat(
+ format: String, _ arguments: CVarArg...
+ ) -> String
- public func stringByAppendingPathComponent(aString: String) -> String
+ public func appendingPathComponent(aString: String) -> String
- public func stringByAppendingPathExtension(ext: String) -> String?
+ public func appendingPathExtension(ext: String) -> String?
- public func stringByAppendingString(aString: String) -> String
+ public func appending(aString: String) -> String
- public var stringByDeletingLastPathComponent: String
+ public var deletingLastPathComponent: String
- public var stringByDeletingPathExtension: String
+ public var deletingPathExtension: String
- public var stringByExpandingTildeInPath: String
+ public var expandingTildeInPath: String
- public func stringByFoldingWithOptions(
- options: NSStringCompareOptions, locale: NSLocale?
- ) -> String
+ public func folding(
+ options: NSStringCompareOptions = [], locale: NSLocale?
+ ) -> String
- public func stringByPaddingToLength(
- newLength: Int, withString padString: String, startingAtIndex padIndex: Int
- ) -> String
+ public func padding(
+ toLength newLength: Int,
+ with padString: String,
+ startingAt padIndex: Int
+ ) -> String
- public var stringByRemovingPercentEncoding: String?
+ public var removingPercentEncoding: String?
- public func stringByReplacingCharactersInRange(
- range: Range<Index>, withString replacement: String
- ) -> String
+ public func replacingCharacters(
+ in range: Range<Index>, with replacement: String
+ ) -> String
- public func stringByReplacingOccurrencesOfString(
- target: String,
- withString replacement: String,
- options: NSStringCompareOptions = [],
- range searchRange: Range<Index>? = nil
- ) -> String
+ public func replacingOccurrences(
+ of target: String,
+ with replacement: String,
+ options: NSStringCompareOptions = [],
+ range searchRange: Range<Index>? = nil
+ ) -> String
- public func stringByReplacingPercentEscapesUsingEncoding(
- encoding: NSStringEncoding
- ) -> String?
+ public func replacingPercentEscapes(
+ usingEncoding encoding: NSStringEncoding
+ ) -> String?
- public var stringByResolvingSymlinksInPath: String
+ public var resolvingSymlinksInPath: String
- public var stringByStandardizingPath: String
+ public var standardizingPath: String
- public func stringByTrimmingCharactersInSet(set: NSCharacterSet) -> String
+ public func trimmingCharacters(in set: NSCharacterSet) -> String
- public func stringsByAppendingPaths(paths: [String]) -> [String]
+ public func strings(byAppendingPaths paths: [String]) -> [String]
- public func substringFromIndex(index: Index) -> String
+ public func substring(from index: Index) -> String
- public func substringToIndex(index: Index) -> String
+ public func substring(to index: Index) -> String
- public func substringWithRange(aRange: Range<Index>) -> String
+ public func substring(with aRange: Range<Index>) -> String
- public var localizedUppercaseString: String
+ public var localizedUppercase: String
- public func uppercaseStringWithLocale(locale: NSLocale?) -> String
+ public func uppercaseString(with locale: NSLocale?) -> String
- public func writeToFile(
- path: String, atomically useAuxiliaryFile:Bool,
- encoding enc: NSStringEncoding
- ) throws
+ public func write(
+ toFile path: String, atomically useAuxiliaryFile:Bool,
+ encoding enc: NSStringEncoding
+ ) throws
- public func writeToURL(
- url: NSURL, atomically useAuxiliaryFile: Bool,
- encoding enc: NSStringEncoding
- ) throws
+ public func write(
+ to url: NSURL, atomically useAuxiliaryFile: Bool,
+ encoding enc: NSStringEncoding
+ ) throws
- public func stringByApplyingTransform(
- transform: String, reverse: Bool
- ) -> String?
+ public func applyingTransform(
+ transform: String, reverse: Bool
+ ) -> String?
- public func containsString(other: String) -> Bool
+ public func contains(other: String) -> Bool
- public func localizedCaseInsensitiveContainsString(other: String) -> Bool
+ public func localizedCaseInsensitiveContains(other: String) -> Bool
}
```
* Miscellaneous changes.
```diff
public struct EnumeratedIterator<Base : IteratorProtocol> : ... {
- public typealias Element = (index: Int, element: Base.Element)
+ public typealias Element = (offset: Int, element: Base.Element)
}
public struct Array<Element> : ... {
// Same changes were also applied to `ArraySlice` and `ContiguousArray`.
- public init(count: Int, repeatedValue: Element)
+ public init(repeating: Element, count: Int)
}
public protocol Sequence : ... {
public func split(
- maxSplit: Int = Int.max,
+ maxSplits maxSplits: Int = Int.max,
- allowEmptySlices: Bool = false,
+ omittingEmptySubsequences: Bool = true,
@noescape isSeparator: (Iterator.Element) throws -> Bool
) rethrows -> [SubSequence]
}
extension Sequence where Iterator.Element : Equatable {
public func split(
- separator: Iterator.Element,
+ separator separator: Iterator.Element,
- maxSplit: Int = Int.max,
+ maxSplits maxSplits: Int = Int.max,
- allowEmptySlices: Bool = false
+ omittingEmptySubsequences: Bool = true
) -> [AnySequence<Iterator.Element>] {
}
public protocol Sequence : ... {
- public func lexicographicalCompare<
+ public func lexicographicallyPrecedes<
OtherSequence : Sequence where OtherSequence.Iterator.Element == Iterator.Element
>(
other: OtherSequence,
@noescape isOrderedBefore: (Iterator.Element, Iterator.Element) throws -> Bool
) rethrows -> Bool {
}
extension Sequence where Iterator.Element : Equatable {
- public func lexicographicalCompare<
+ public func lexicographicallyPrecedes<
OtherSequence : Sequence where OtherSequence.Iterator.Element == Iterator.Element
>(
other: OtherSequence
) -> Bool {
}
public protocol Collection : ... {
- func prefixUpTo(end: Index) -> SubSequence
+ func prefix(upTo end: Index) -> SubSequence
- func suffixFrom(start: Index) -> SubSequence
+ func suffix(from start: Index) -> SubSequence
- func prefixThrough(position: Index) -> SubSequence
+ func prefix(through position: Index) -> SubSequence
}
// Changes to this protocol affect `Array`, `ArraySlice`, `ContiguousArray` and
// other types.
public protocol RangeReplaceableCollection : ... {
+ public init(repeating repeatedValue: Iterator.Element, count: Int)
- mutating func replaceRange<
+ mutating func replaceSubrange<
C : CollectionType where C.Iterator.Element == Iterator.Element
>(
subRange: Range<Int>, with newElements: C
)
- mutating func insert(newElement: Iterator.Element, atIndex i: Int)
+ mutating func insert(newElement: Iterator.Element, at i: Int)
- mutating func insertContentsOf<
+ mutating func insert<
S : Collection where S.Iterator.Element == Iterator.Element
- >(newElements: S, at i: Index)
+ >(contentsOf newElements: S, at i: Index)
- mutating func removeAtIndex(index: Int) -> Element
+ mutating func remove(at index: Int) -> Element
- mutating func removeAll(keepCapacity keepCapacity: Bool = false)
+ mutating func removeAll(keepingCapacity keepingCapacity: Bool = false)
- mutating func removeRange(subRange: Range<Index>)
+ mutating func removeSubrange(subRange: Range<Index>)
- mutating func appendContentsOf<S : SequenceType>(newElements: S)
+ mutating func append<S : SequenceType>(contentsOf newElements: S)
}
+extension Set : SetAlgebra {}
public struct Dictionary<Key : Hashable, Value> : ... {
- public typealias Element = (Key, Value)
+ public typealias Element = (key: Key, value: Value)
}
public struct DictionaryLiteral<Key, Value> : ... {
- public typealias Element = (Key, Value)
+ public typealias Element = (key: Key, value: Value)
}
extension String {
- public mutating func appendContentsOf(other: String) {
+ public mutating func append(other: String) {
- public mutating appendContentsOf<S : SequenceType>(newElements: S)
+ public mutating append<S : SequenceType>(contentsOf newElements: S)
- public mutating func replaceRange<
+ public mutating func replaceSubrange<
C: CollectionType where C.Iterator.Element == Character
>(
subRange: Range<Index>, with newElements: C
)
- public mutating func replaceRange(
+ public mutating func replaceSubrange(
subRange: Range<Index>, with newElements: String
)
- public mutating func insert(newElement: Character, atIndex i: Index)
+ public mutating func insert(newElement: Character, at i: Index)
- public mutating func insertContentsOf<
+ public mutating func insert<
S : Collection where S.Iterator.Element == Character
- >(newElements: S, at i: Index)
+ >(contentsOf newElements: S, at i: Index)
- public mutating func removeAtIndex(i: Index) -> Character
+ public mutating func remove(at i: Index) -> Character
- public mutating func removeRange(subRange: Range<Index>)
+ public mutating func removeSubrange(subRange: Range<Index>)
- mutating func removeAll(keepCapacity keepCapacity: Bool = false)
+ mutating func removeAll(keepingCapacity keepingCapacity: Bool = false)
- public init(count: Int, repeatedValue c: Character)
+ public init(repeating repeatedValue: Character, count: Int)
- public init(count: Int, repeatedValue
gitextract_f7lua7kp/
├── .gitattributes
├── .gitignore
├── .nojekyll
├── 404.html
├── CONTRIBUTING.md
├── LICENSE.txt
├── README.md
├── commonly_proposed.md
├── policies/
│ ├── 0001-platform-support-tiers.md
│ └── templates/
│ └── xxxx-policy-template.md
├── process.md
├── proposal-templates/
│ ├── 0000-swift-template.md
│ ├── 0000-swift-testing-template.md
│ └── 0000-swiftpm-template.md
├── proposals/
│ ├── 0001-keywords-as-argument-labels.md
│ ├── 0002-remove-currying.md
│ ├── 0003-remove-var-parameters.md
│ ├── 0004-remove-pre-post-inc-decrement.md
│ ├── 0005-objective-c-name-translation.md
│ ├── 0006-apply-api-guidelines-to-the-standard-library.md
│ ├── 0007-remove-c-style-for-loops.md
│ ├── 0008-lazy-flatmap-for-optionals.md
│ ├── 0009-require-self-for-accessing-instance-members.md
│ ├── 0010-add-staticstring-unicodescalarview.md
│ ├── 0011-replace-typealias-associated.md
│ ├── 0012-add-noescape-to-public-library-api.md
│ ├── 0013-remove-partial-application-super.md
│ ├── 0014-constrained-AnySequence.md
│ ├── 0015-tuple-comparison-operators.md
│ ├── 0016-initializers-for-converting-unsafe-pointers-to-ints.md
│ ├── 0017-convert-unmanaged-to-use-unsafepointer.md
│ ├── 0018-flexible-memberwise-initialization.md
│ ├── 0019-package-manager-testing.md
│ ├── 0020-if-swift-version.md
│ ├── 0021-generalized-naming.md
│ ├── 0022-objc-selectors.md
│ ├── 0023-api-guidelines.md
│ ├── 0024-optional-value-setter.md
│ ├── 0025-scoped-access-level.md
│ ├── 0026-abstract-classes-and-methods.md
│ ├── 0027-string-from-code-units.md
│ ├── 0028-modernizing-debug-identifiers.md
│ ├── 0029-remove-implicit-tuple-splat.md
│ ├── 0030-property-behavior-decls.md
│ ├── 0031-adjusting-inout-declarations.md
│ ├── 0032-sequencetype-find.md
│ ├── 0033-import-objc-constants.md
│ ├── 0034-disambiguating-line.md
│ ├── 0035-limit-inout-capture.md
│ ├── 0036-enum-dot.md
│ ├── 0037-clarify-comments-and-operators.md
│ ├── 0038-swiftpm-c-language-targets.md
│ ├── 0039-playgroundliterals.md
│ ├── 0040-attributecolons.md
│ ├── 0041-conversion-protocol-conventions.md
│ ├── 0042-flatten-method-types.md
│ ├── 0043-declare-variables-in-case-labels-with-multiple-patterns.md
│ ├── 0044-import-as-member.md
│ ├── 0045-scan-takewhile-dropwhile.md
│ ├── 0046-first-label.md
│ ├── 0047-nonvoid-warn.md
│ ├── 0048-generic-typealias.md
│ ├── 0049-noescape-autoclosure-type-attrs.md
│ ├── 0050-floating-point-stride.md
│ ├── 0051-stride-semantics.md
│ ├── 0052-iterator-post-nil-guarantee.md
│ ├── 0053-remove-let-from-function-parameters.md
│ ├── 0054-abolish-iuo.md
│ ├── 0055-optional-unsafe-pointers.md
│ ├── 0056-trailing-closures-in-guard.md
│ ├── 0057-importing-objc-generics.md
│ ├── 0058-objectivecbridgeable.md
│ ├── 0059-updated-set-apis.md
│ ├── 0060-defaulted-parameter-order.md
│ ├── 0061-autoreleasepool-signature.md
│ ├── 0062-objc-keypaths.md
│ ├── 0063-swiftpm-system-module-search-paths.md
│ ├── 0064-property-selectors.md
│ ├── 0065-collections-move-indices.md
│ ├── 0066-standardize-function-type-syntax.md
│ ├── 0067-floating-point-protocols.md
│ ├── 0068-universal-self.md
│ ├── 0069-swift-mutability-for-foundation.md
│ ├── 0070-optional-requirements.md
│ ├── 0071-member-keywords.md
│ ├── 0072-eliminate-implicit-bridging-conversions.md
│ ├── 0073-noescape-once.md
│ ├── 0074-binary-search.md
│ ├── 0075-import-test.md
│ ├── 0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md
│ ├── 0077-operator-precedence.md
│ ├── 0078-rotate-algorithm.md
│ ├── 0079-upgrade-self-from-weak-to-strong.md
│ ├── 0080-failable-numeric-initializers.md
│ ├── 0081-move-where-expression.md
│ ├── 0082-swiftpm-package-edit.md
│ ├── 0083-remove-bridging-from-dynamic-casts.md
│ ├── 0084-trailing-commas.md
│ ├── 0085-package-manager-command-name.md
│ ├── 0086-drop-foundation-ns.md
│ ├── 0087-lazy-attribute.md
│ ├── 0088-libdispatch-for-swift3.md
│ ├── 0089-rename-string-reflection-init.md
│ ├── 0090-remove-dot-self.md
│ ├── 0091-improving-operators-in-protocols.md
│ ├── 0092-typealiases-in-protocols.md
│ ├── 0093-slice-base.md
│ ├── 0094-sequence-function.md
│ ├── 0095-any-as-existential.md
│ ├── 0096-dynamictype.md
│ ├── 0097-negative-attributes.md
│ ├── 0098-didset-capitalization.md
│ ├── 0099-conditionclauses.md
│ ├── 0100-add-sequence-based-init-and-merge-to-dictionary.md
│ ├── 0101-standardizing-sizeof-naming.md
│ ├── 0102-noreturn-bottom-type.md
│ ├── 0103-make-noescape-default.md
│ ├── 0104-improved-integers.md
│ ├── 0105-remove-where-from-forin-loops.md
│ ├── 0106-rename-osx-to-macos.md
│ ├── 0107-unsaferawpointer.md
│ ├── 0108-remove-assoctype-inference.md
│ ├── 0109-remove-boolean.md
│ ├── 0110-distinguish-single-tuple-arg.md
│ ├── 0111-remove-arg-label-type-significance.md
│ ├── 0112-nserror-bridging.md
│ ├── 0113-rounding-functions-on-floatingpoint.md
│ ├── 0114-buffer-naming.md
│ ├── 0115-literal-syntax-protocols.md
│ ├── 0116-id-as-any.md
│ ├── 0117-non-public-subclassable-by-default.md
│ ├── 0118-closure-parameter-names-and-labels.md
│ ├── 0119-extensions-access-modifiers.md
│ ├── 0120-revise-partition-method.md
│ ├── 0121-remove-optional-comparison-operators.md
│ ├── 0122-use-colons-for-subscript-type-declarations.md
│ ├── 0123-disallow-value-to-optional-coercion-in-operator-arguments.md
│ ├── 0124-bitpattern-label-for-int-initializer-objectidentfier.md
│ ├── 0125-remove-nonobjectivecbase.md
│ ├── 0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md
│ ├── 0127-cleaning-up-stdlib-ptr-buffer.md
│ ├── 0128-unicodescalar-failable-initializer.md
│ ├── 0129-package-manager-test-naming-conventions.md
│ ├── 0130-string-initializers-cleanup.md
│ ├── 0131-anyhashable.md
│ ├── 0132-sequence-end-ops.md
│ ├── 0133-rename-flatten-to-joined.md
│ ├── 0134-rename-string-properties.md
│ ├── 0135-package-manager-support-for-differentiating-packages-by-swift-version.md
│ ├── 0136-memory-layout-of-values.md
│ ├── 0137-avoiding-lock-in.md
│ ├── 0138-unsaferawbufferpointer.md
│ ├── 0139-bridge-nsnumber-and-nsvalue.md
│ ├── 0140-bridge-optional-to-nsnull.md
│ ├── 0141-available-by-swift-version.md
│ ├── 0142-associated-types-constraints.md
│ ├── 0143-conditional-conformances.md
│ ├── 0144-allow-single-dollar-sign-as-valid-identifier.md
│ ├── 0145-package-manager-version-pinning.md
│ ├── 0146-package-manager-product-definitions.md
│ ├── 0147-move-unsafe-initialize-from.md
│ ├── 0148-generic-subscripts.md
│ ├── 0149-package-manager-top-of-tree.md
│ ├── 0150-package-manager-branch-support.md
│ ├── 0151-package-manager-swift-language-compatibility-version.md
│ ├── 0152-package-manager-tools-version.md
│ ├── 0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
│ ├── 0154-dictionary-key-and-value-collections.md
│ ├── 0155-normalize-enum-case-representation.md
│ ├── 0156-subclass-existentials.md
│ ├── 0157-recursive-protocol-constraints.md
│ ├── 0158-package-manager-manifest-api-redesign.md
│ ├── 0159-fix-private-access-levels.md
│ ├── 0160-objc-inference.md
│ ├── 0161-key-paths.md
│ ├── 0162-package-manager-custom-target-layouts.md
│ ├── 0163-string-revision-1.md
│ ├── 0164-remove-final-support-in-protocol-extensions.md
│ ├── 0165-dict.md
│ ├── 0166-swift-archival-serialization.md
│ ├── 0167-swift-encoders.md
│ ├── 0168-multi-line-string-literals.md
│ ├── 0169-improve-interaction-between-private-declarations-and-extensions.md
│ ├── 0170-nsnumber_bridge.md
│ ├── 0171-reduce-with-inout.md
│ ├── 0172-one-sided-ranges.md
│ ├── 0173-swap-indices.md
│ ├── 0174-filter-range-replaceable.md
│ ├── 0175-package-manager-revised-dependency-resolution.md
│ ├── 0176-enforce-exclusive-access-to-memory.md
│ ├── 0177-add-clamped-to-method.md
│ ├── 0178-character-unicode-view.md
│ ├── 0179-swift-run-command.md
│ ├── 0180-string-index-overhaul.md
│ ├── 0181-package-manager-cpp-language-version.md
│ ├── 0182-newline-escape-in-strings.md
│ ├── 0183-substring-affordances.md
│ ├── 0184-unsafe-pointers-add-missing.md
│ ├── 0185-synthesize-equatable-hashable.md
│ ├── 0186-remove-ownership-keyword-support-in-protocols.md
│ ├── 0187-introduce-filtermap.md
│ ├── 0188-stdlib-index-types-hashable.md
│ ├── 0189-restrict-cross-module-struct-initializers.md
│ ├── 0190-target-environment-platform-condition.md
│ ├── 0191-eliminate-indexdistance.md
│ ├── 0192-non-exhaustive-enums.md
│ ├── 0193-cross-module-inlining-and-specialization.md
│ ├── 0194-derived-collection-of-enum-cases.md
│ ├── 0195-dynamic-member-lookup.md
│ ├── 0196-diagnostic-directives.md
│ ├── 0197-remove-where.md
│ ├── 0198-playground-quicklook-api-revamp.md
│ ├── 0199-bool-toggle.md
│ ├── 0200-raw-string-escaping.md
│ ├── 0201-package-manager-local-dependencies.md
│ ├── 0202-random-unification.md
│ ├── 0203-rename-sequence-elements-equal.md
│ ├── 0204-add-last-methods.md
│ ├── 0205-withUnsafePointer-for-lets.md
│ ├── 0206-hashable-enhancements.md
│ ├── 0207-containsOnly.md
│ ├── 0208-package-manager-system-library-targets.md
│ ├── 0209-package-manager-swift-lang-version-update.md
│ ├── 0210-key-path-offset.md
│ ├── 0211-unicode-scalar-properties.md
│ ├── 0212-compiler-version-directive.md
│ ├── 0213-literal-init-via-coercion.md
│ ├── 0214-DictionaryLiteral.md
│ ├── 0215-conform-never-to-hashable-and-equatable.md
│ ├── 0216-dynamic-callable.md
│ ├── 0217-bangbang.md
│ ├── 0218-introduce-compact-map-values.md
│ ├── 0219-package-manager-dependency-mirroring.md
│ ├── 0220-count-where.md
│ ├── 0221-character-properties.md
│ ├── 0222-lazy-compactmap-sequence.md
│ ├── 0223-array-uninitialized-initializer.md
│ ├── 0224-ifswift-lessthan-operator.md
│ ├── 0225-binaryinteger-iseven-isodd-ismultiple.md
│ ├── 0226-package-manager-target-based-dep-resolution.md
│ ├── 0227-identity-keypath.md
│ ├── 0228-fix-expressiblebystringinterpolation.md
│ ├── 0229-simd.md
│ ├── 0230-flatten-optional-try.md
│ ├── 0231-optional-iteration.md
│ ├── 0232-remove-customization-points.md
│ ├── 0233-additive-arithmetic-protocol.md
│ ├── 0234-remove-sequence-subsequence.md
│ ├── 0235-add-result.md
│ ├── 0236-package-manager-platform-deployment-settings.md
│ ├── 0237-contiguous-collection.md
│ ├── 0238-package-manager-build-settings.md
│ ├── 0239-codable-range.md
│ ├── 0240-ordered-collection-diffing.md
│ ├── 0241-string-index-explicit-encoding-offset.md
│ ├── 0242-default-values-memberwise.md
│ ├── 0243-codepoint-and-character-literals.md
│ ├── 0244-opaque-result-types.md
│ ├── 0245-array-uninitialized-initializer.md
│ ├── 0246-mathable.md
│ ├── 0247-contiguous-strings.md
│ ├── 0248-string-gaps-missing-apis.md
│ ├── 0249-key-path-literal-function-expressions.md
│ ├── 0250-swift-style-guide-and-formatter.md
│ ├── 0251-simd-additions.md
│ ├── 0252-keypath-dynamic-member-lookup.md
│ ├── 0253-callable.md
│ ├── 0254-static-subscripts.md
│ ├── 0255-omit-return.md
│ ├── 0256-contiguous-collection.md
│ ├── 0257-elide-comma.md
│ ├── 0258-property-wrappers.md
│ ├── 0259-approximately-equal.md
│ ├── 0260-library-evolution.md
│ ├── 0261-identifiable.md
│ ├── 0262-demangle.md
│ ├── 0263-string-uninitialized-initializer.md
│ ├── 0264-stdlib-preview-package.md
│ ├── 0265-offset-indexing-and-slicing.md
│ ├── 0266-synthesized-comparable-for-enumerations.md
│ ├── 0267-where-on-contextually-generic.md
│ ├── 0268-didset-semantics.md
│ ├── 0269-implicit-self-explicit-capture.md
│ ├── 0270-rangeset-and-collection-operations.md
│ ├── 0271-package-manager-resources.md
│ ├── 0272-swiftpm-binary-dependencies.md
│ ├── 0273-swiftpm-conditional-target-dependencies.md
│ ├── 0274-magic-file.md
│ ├── 0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md
│ ├── 0276-multi-pattern-catch-clauses.md
│ ├── 0277-float16.md
│ ├── 0278-package-manager-localized-resources.md
│ ├── 0279-multiple-trailing-closures.md
│ ├── 0280-enum-cases-as-protocol-witnesses.md
│ ├── 0281-main-attribute.md
│ ├── 0282-atomics.md
│ ├── 0283-tuples-are-equatable-comparable-hashable.md
│ ├── 0284-multiple-variadic-parameters.md
│ ├── 0285-ease-pound-file-transition.md
│ ├── 0286-forward-scan-trailing-closures.md
│ ├── 0287-implicit-member-chains.md
│ ├── 0288-binaryinteger-ispower.md
│ ├── 0289-result-builders.md
│ ├── 0290-negative-availability.md
│ ├── 0291-package-collections.md
│ ├── 0292-package-registry-service.md
│ ├── 0293-extend-property-wrappers-to-function-and-closure-parameters.md
│ ├── 0294-package-executable-targets.md
│ ├── 0295-codable-synthesis-for-enums-with-associated-values.md
│ ├── 0296-async-await.md
│ ├── 0297-concurrency-objc.md
│ ├── 0298-asyncsequence.md
│ ├── 0299-extend-generic-static-member-lookup.md
│ ├── 0300-continuation.md
│ ├── 0301-package-editing-commands.md
│ ├── 0302-concurrent-value-and-concurrent-closures.md
│ ├── 0303-swiftpm-extensible-build-tools.md
│ ├── 0304-structured-concurrency.md
│ ├── 0305-swiftpm-binary-target-improvements.md
│ ├── 0306-actors.md
│ ├── 0307-allow-interchangeable-use-of-double-cgfloat-types.md
│ ├── 0308-postfix-if-config-expressions.md
│ ├── 0309-unlock-existential-types-for-all-protocols.md
│ ├── 0310-effectful-readonly-properties.md
│ ├── 0311-task-locals.md
│ ├── 0312-indexed-and-enumerated-zip-collections.md
│ ├── 0313-actor-isolation-control.md
│ ├── 0314-async-stream.md
│ ├── 0315-placeholder-types.md
│ ├── 0316-global-actors.md
│ ├── 0317-async-let.md
│ ├── 0318-package-creation.md
│ ├── 0319-never-identifiable.md
│ ├── 0320-codingkeyrepresentable.md
│ ├── 0321-package-registry-publish.md
│ ├── 0322-temporary-buffers.md
│ ├── 0323-async-main-semantics.md
│ ├── 0324-c-lang-pointer-arg-conversion.md
│ ├── 0325-swiftpm-additional-plugin-apis.md
│ ├── 0326-extending-multi-statement-closure-inference.md
│ ├── 0327-actor-initializers.md
│ ├── 0328-structural-opaque-result-types.md
│ ├── 0329-clock-instant-duration.md
│ ├── 0330-collection-conditionals.md
│ ├── 0331-remove-sendable-from-unsafepointer.md
│ ├── 0332-swiftpm-command-plugins.md
│ ├── 0333-with-memory-rebound.md
│ ├── 0334-pointer-usability-improvements.md
│ ├── 0335-existential-any.md
│ ├── 0336-distributed-actor-isolation.md
│ ├── 0337-support-incremental-migration-to-concurrency-checking.md
│ ├── 0338-clarify-execution-non-actor-async.md
│ ├── 0339-module-aliasing-for-disambiguation.md
│ ├── 0340-swift-noasync.md
│ ├── 0341-opaque-parameters.md
│ ├── 0342-static-link-runtime-libraries-by-default-on-supported-platforms.md
│ ├── 0343-top-level-concurrency.md
│ ├── 0344-distributed-actor-runtime.md
│ ├── 0345-if-let-shorthand.md
│ ├── 0346-light-weight-same-type-syntax.md
│ ├── 0347-type-inference-from-default-exprs.md
│ ├── 0348-buildpartialblock.md
│ ├── 0349-unaligned-loads-and-stores.md
│ ├── 0350-regex-type-overview.md
│ ├── 0351-regex-builder.md
│ ├── 0352-implicit-open-existentials.md
│ ├── 0353-constrained-existential-types.md
│ ├── 0354-regex-literals.md
│ ├── 0355-regex-syntax-run-time-construction.md
│ ├── 0356-swift-snippets.md
│ ├── 0357-regex-string-processing-algorithms.md
│ ├── 0358-primary-associated-types-in-stdlib.md
│ ├── 0359-build-time-constant-values.md
│ ├── 0360-opaque-result-types-with-availability.md
│ ├── 0361-bound-generic-extensions.md
│ ├── 0362-piecemeal-future-features.md
│ ├── 0363-unicode-for-string-processing.md
│ ├── 0364-retroactive-conformance-warning.md
│ ├── 0365-implicit-self-weak-capture.md
│ ├── 0366-move-function.md
│ ├── 0367-conditional-attributes.md
│ ├── 0368-staticbigint.md
│ ├── 0369-add-customdebugdescription-conformance-to-anykeypath.md
│ ├── 0370-pointer-family-initialization-improvements.md
│ ├── 0371-isolated-synchronous-deinit.md
│ ├── 0372-document-sorting-as-stable.md
│ ├── 0373-vars-without-limits-in-result-builders.md
│ ├── 0374-clock-sleep-for.md
│ ├── 0375-opening-existential-optional.md
│ ├── 0376-function-back-deployment.md
│ ├── 0377-parameter-ownership-modifiers.md
│ ├── 0378-package-registry-auth.md
│ ├── 0379-opt-in-reflection-metadata.md
│ ├── 0380-if-switch-expressions.md
│ ├── 0381-task-group-discard-results.md
│ ├── 0382-expression-macros.md
│ ├── 0383-deprecate-uiapplicationmain-and-nsapplicationmain.md
│ ├── 0384-importing-forward-declared-objc-interfaces-and-protocols.md
│ ├── 0385-custom-reflection-metadata.md
│ ├── 0386-package-access-modifier.md
│ ├── 0387-cross-compilation-destinations.md
│ ├── 0388-async-stream-factory.md
│ ├── 0389-attached-macros.md
│ ├── 0390-noncopyable-structs-and-enums.md
│ ├── 0391-package-registry-publish.md
│ ├── 0392-custom-actor-executors.md
│ ├── 0393-parameter-packs.md
│ ├── 0394-swiftpm-expression-macros.md
│ ├── 0395-observability.md
│ ├── 0396-never-codable.md
│ ├── 0397-freestanding-declaration-macros.md
│ ├── 0398-variadic-types.md
│ ├── 0399-tuple-of-value-pack-expansion.md
│ ├── 0400-init-accessors.md
│ ├── 0401-remove-property-wrapper-isolation.md
│ ├── 0402-extension-macros.md
│ ├── 0403-swiftpm-mixed-language-targets.md
│ ├── 0404-nested-protocols.md
│ ├── 0405-string-validating-initializers.md
│ ├── 0406-async-stream-backpressure.md
│ ├── 0407-member-macro-conformances.md
│ ├── 0408-pack-iteration.md
│ ├── 0409-access-level-on-imports.md
│ ├── 0410-atomics.md
│ ├── 0411-isolated-default-values.md
│ ├── 0412-strict-concurrency-for-global-variables.md
│ ├── 0413-typed-throws.md
│ ├── 0414-region-based-isolation.md
│ ├── 0415-function-body-macros.md
│ ├── 0416-keypath-function-subtyping.md
│ ├── 0417-task-executor-preference.md
│ ├── 0418-inferring-sendable-for-methods.md
│ ├── 0419-backtrace-api.md
│ ├── 0420-inheritance-of-actor-isolation.md
│ ├── 0421-generalize-async-sequence.md
│ ├── 0422-caller-side-default-argument-macro-expression.md
│ ├── 0423-dynamic-actor-isolation.md
│ ├── 0424-custom-isolation-checking-for-serialexecutor.md
│ ├── 0425-int128.md
│ ├── 0426-bitwise-copyable.md
│ ├── 0427-noncopyable-generics.md
│ ├── 0428-resolve-distributed-actor-protocols.md
│ ├── 0429-partial-consumption.md
│ ├── 0430-transferring-parameters-and-results.md
│ ├── 0431-isolated-any-functions.md
│ ├── 0432-noncopyable-switch.md
│ ├── 0433-mutex.md
│ ├── 0434-global-actor-isolated-types-usability.md
│ ├── 0435-swiftpm-per-target-swift-language-version-setting.md
│ ├── 0436-objc-implementation.md
│ ├── 0437-noncopyable-stdlib-primitives.md
│ ├── 0438-metatype-keypath.md
│ ├── 0439-trailing-comma-lists.md
│ ├── 0440-debug-description-macro.md
│ ├── 0441-formalize-language-mode-terminology.md
│ ├── 0442-allow-taskgroup-childtaskresult-type-to-be-inferred.md
│ ├── 0443-warning-control-flags.md
│ ├── 0444-member-import-visibility.md
│ ├── 0445-string-index-printing.md
│ ├── 0446-non-escapable.md
│ ├── 0447-span-access-shared-contiguous-storage.md
│ ├── 0448-regex-lookbehind-assertions.md
│ ├── 0449-nonisolated-for-global-actor-cutoff.md
│ ├── 0450-swiftpm-package-traits.md
│ ├── 0451-escaped-identifiers.md
│ ├── 0452-integer-generic-parameters.md
│ ├── 0453-vector.md
│ ├── 0454-memory-allocator.md
│ ├── 0455-swiftpm-testable-build-setting.md
│ ├── 0456-stdlib-span-properties.md
│ ├── 0457-duration-attosecond-represenation.md
│ ├── 0458-strict-memory-safety.md
│ ├── 0459-enumerated-collection.md
│ ├── 0460-specialized.md
│ ├── 0461-async-function-isolation.md
│ ├── 0462-task-priority-escalation-apis.md
│ ├── 0463-sendable-completion-handlers.md
│ ├── 0464-utf8span-safe-utf8-processing.md
│ ├── 0465-nonescapable-stdlib-primitives.md
│ ├── 0466-control-default-actor-isolation.md
│ ├── 0467-MutableSpan.md
│ ├── 0468-async-stream-continuation-hashable-conformance.md
│ ├── 0469-task-names.md
│ ├── 0470-isolated-conformances.md
│ ├── 0471-SerialExecutor-isIsolated.md
│ ├── 0471-is-isolated-flow.graffle
│ ├── 0472-task-start-synchronously-on-caller-context.md
│ ├── 0473-clock-epochs.md
│ ├── 0474-yielding-accessors.md
│ ├── 0475-observed.md
│ ├── 0476-abi-attr.md
│ ├── 0477-default-interpolation-values.md
│ ├── 0478-default-isolation-typealias.md
│ ├── 0479-method-and-initializer-keypaths.md
│ ├── 0480-swiftpm-warning-control.md
│ ├── 0481-weak-let.md
│ ├── 0482-swiftpm-static-library-binary-target-non-apple-platforms.md
│ ├── 0483-inline-array-sugar.md
│ ├── 0484-allow-additional-args-to-dynamicmemberlookup-subscripts.md
│ ├── 0485-outputspan.md
│ ├── 0486-adoption-tooling-for-swift-features.md
│ ├── 0487-extensible-enums.md
│ ├── 0488-extracting.md
│ ├── 0489-codable-error-printing.md
│ ├── 0490-environment-constrained-shared-libraries.md
│ ├── 0491-module-selectors.md
│ ├── 0492-section-control.md
│ ├── 0493-defer-async.md
│ ├── 0494-add-is-identical-methods.md
│ ├── 0495-cdecl.md
│ ├── 0496-inline-always.md
│ ├── 0497-definition-visibility.md
│ ├── 0498-runtime-demangle.md
│ ├── 0499-support-non-copyable-simple-protocols.md
│ ├── 0500-package-manager-templates.md
│ ├── 0501-swiftpm-html-coverage-report.md
│ ├── 0502-exclude-private-from-memberwise-init.md
│ ├── 0503-suppressed-associated-types.md
│ ├── 0504-task-cancellation-shields.md
│ ├── 0505-delayed-enqueuing.md
│ ├── 0506-advanced-observation-tracking.md
│ ├── 0507-borrow-accessors.md
│ ├── 0508-array-expression-trailing-closures.md
│ ├── 0509-swift-sboms-via-swiftpm.md
│ ├── 0510-dictionary-mapvalues-with-keys.md
│ ├── 0511-swiftpm-add-target-plugin.md
│ ├── 0512-withlockifavailable-cannot-spuriously-fail.md
│ ├── 0513-commandline-executablepath.md
│ ├── 0514-hashable-conformance-for-dictionarykeys-collectionofone-emptycollection.md
│ ├── 0515-noncopyable-reduce.md
│ ├── 0516-borrowing-sequence.md
│ ├── 0517-uniquebox.md
│ ├── 0518-tilde-sendable.md
│ ├── 0519-borrow-inout-types.md
│ ├── 0520-discardableresult-task-initializers.md
│ ├── 0521-improved-optional-opaque-and-any.md
│ ├── 0522-source-warning-control.md
│ └── testing/
│ ├── 0001-refactor-bug-inits.md
│ ├── 0002-json-abi.md
│ ├── 0003-make-serialized-trait-api.md
│ ├── 0004-constrain-the-granularity-of-test-time-limit-durations.md
│ ├── 0005-ranged-confirmations.md
│ ├── 0006-return-errors-from-expect-throws.md
│ ├── 0007-test-scoping-traits.md
│ ├── 0008-exit-tests.md
│ ├── 0009-attachments.md
│ ├── 0010-evaluate-condition.md
│ ├── 0011-issue-handling-traits.md
│ ├── 0012-exit-test-value-capturing.md
│ ├── 0013-issue-severity-warning.md
│ ├── 0014-image-attachments-in-swift-testing-apple-platforms.md
│ ├── 0015-image-attachments-in-swift-testing-windows.md
│ ├── 0016-test-cancellation.md
│ ├── 0017-image-attachment-consolidation.md
│ ├── 0018-conditionally-saving-attachments.md
│ ├── 0019-include-tags-bugs-and-timeline-in-event-stream.md
│ ├── 0020-sourcelocation-filepath.md
│ └── 0021-targeted-interoperability-swift-testing-and-xctest.md
├── releases/
│ ├── swift-2_2.md
│ ├── swift-3_0.md
│ ├── swift-4_0.md
│ └── swift-5_0.md
└── visions/
├── approachable-concurrency.md
├── embedded-swift.md
├── macros.md
├── memory-safety.md
├── networking.md
├── swift-testing.md
├── using-c++-from-swift.md
├── using-swift-from-c++.md
└── webassembly.md
Copy disabled (too large)
Download .json
Condensed preview — 571 files, each showing path, character count, and a content snippet. Download the .json file for the full structured content (10,076K chars).
[
{
"path": ".gitattributes",
"chars": 64,
"preview": "*.md linguist-detectable=true\n*.md linguist-documentation=false\n"
},
{
"path": ".gitignore",
"chars": 112,
"preview": "# Temporary files.\n*~\n\n# Xcode user data.\nxcuserdata\n\n# Finder metadata\n.DS_Store\n\n# Built site content.\n/_site\n"
},
{
"path": ".nojekyll",
"chars": 0,
"preview": ""
},
{
"path": "404.html",
"chars": 275,
"preview": "<!DOCTYPE html>\n<meta charset=\"utf-8\">\n<noscript>\n <meta http-equiv=\"Refresh\" content=\"0; URL=https://www.swift.org/swi"
},
{
"path": "CONTRIBUTING.md",
"chars": 2274,
"preview": "# Welcome to the Swift community! \n\nContributions to Swift are welcomed and encouraged! Please see the [Contributing to "
},
{
"path": "LICENSE.txt",
"chars": 11757,
"preview": " Apache License\n Version 2.0, January 2004\n "
},
{
"path": "README.md",
"chars": 3845,
"preview": "# Swift Evolution\n\n<https://www.swift.org/swift-evolution/>\n\nThis repository tracks the ongoing evolution of the Swift p"
},
{
"path": "commonly_proposed.md",
"chars": 9844,
"preview": "# Commonly Rejected Changes \n\nThis is a list of changes to the Swift language that are frequently proposed but that are "
},
{
"path": "policies/0001-platform-support-tiers.md",
"chars": 13769,
"preview": "# Swift Platform Support Tiers\n\n* Policy: [SP-0001](0001-platform-support-tiers.md)\n* Authors: [Platform Steering Group]"
},
{
"path": "policies/templates/xxxx-policy-template.md",
"chars": 861,
"preview": "# Policy name\n\n* Policy: [SP-NNNN](NNNN-filename.md)\n* Authors: [Author 1](https://github.com/swiftdev), [Author 2](http"
},
{
"path": "process.md",
"chars": 32089,
"preview": "# Swift Evolution Process\n\nSwift is a powerful and intuitive programming language that is designed to make writing and m"
},
{
"path": "proposal-templates/0000-swift-template.md",
"chars": 15501,
"preview": "# Feature name\n\n* Proposal: [SE-NNNN](NNNN-filename.md)\n* Authors: [Author 1](https://github.com/swiftdev), [Author 2](h"
},
{
"path": "proposal-templates/0000-swift-testing-template.md",
"chars": 10223,
"preview": "# Swift Testing Feature name\n\n* Proposal: [ST-NNNN](NNNN-filename.md)\n* Authors: [Author 1](https://github.com/author1),"
},
{
"path": "proposal-templates/0000-swiftpm-template.md",
"chars": 2586,
"preview": "# Package Manager Feature name\n\n* Proposal: [SE-NNNN](NNNN-filename.md)\n* Authors: [Author 1](https://github.com/swiftde"
},
{
"path": "proposals/0001-keywords-as-argument-labels.md",
"chars": 3827,
"preview": "# Allow (most) keywords as argument labels\n\n* Proposal: [SE-0001](0001-keywords-as-argument-labels.md)\n* Author: [Doug G"
},
{
"path": "proposals/0002-remove-currying.md",
"chars": 4425,
"preview": "# Removing currying `func` declaration syntax\n\n* Proposal: [SE-0002](0002-remove-currying.md)\n* Author: [Joe Groff](http"
},
{
"path": "proposals/0003-remove-var-parameters.md",
"chars": 3939,
"preview": "# Removing `var` from Function Parameters\n\n* Proposal: [SE-0003](0003-remove-var-parameters.md)\n* Author: [Ashley Garlan"
},
{
"path": "proposals/0004-remove-pre-post-inc-decrement.md",
"chars": 4314,
"preview": "# Remove the `++` and `--` operators\n\n* Proposal: [SE-0004](0004-remove-pre-post-inc-decrement.md)\n* Author: [Chris Latt"
},
{
"path": "proposals/0005-objective-c-name-translation.md",
"chars": 31078,
"preview": "# Better Translation of Objective-C APIs Into Swift\n\n* Proposal: [SE-0005](0005-objective-c-name-translation.md)\n* Autho"
},
{
"path": "proposals/0006-apply-api-guidelines-to-the-standard-library.md",
"chars": 52809,
"preview": "# Apply API Guidelines to the Standard Library\n\n* Proposal: [SE-0006](0006-apply-api-guidelines-to-the-standard-library."
},
{
"path": "proposals/0007-remove-c-style-for-loops.md",
"chars": 5665,
"preview": "# Remove C-style for-loops with conditions and incrementers\n\n* Proposal: [SE-0007](0007-remove-c-style-for-loops.md)\n* A"
},
{
"path": "proposals/0008-lazy-flatmap-for-optionals.md",
"chars": 5047,
"preview": "# Add a Lazy flatMap for Sequences of Optionals #\n\n* Proposal: [SE-0008](0008-lazy-flatmap-for-optionals.md)\n* Author: ["
},
{
"path": "proposals/0009-require-self-for-accessing-instance-members.md",
"chars": 7000,
"preview": "# Require self for accessing instance members\n\n* Proposal: [SE-0009](0009-require-self-for-accessing-instance-members.md"
},
{
"path": "proposals/0010-add-staticstring-unicodescalarview.md",
"chars": 4062,
"preview": "# Add StaticString.UnicodeScalarView\n\n* Proposal: [SE-0010](0010-add-staticstring-unicodescalarview.md)\n* Author: [Lily "
},
{
"path": "proposals/0011-replace-typealias-associated.md",
"chars": 3677,
"preview": "# Replace `typealias` keyword with `associatedtype` for associated type declarations\n\n* Proposal: [SE-0011](0011-replace"
},
{
"path": "proposals/0012-add-noescape-to-public-library-api.md",
"chars": 17957,
"preview": "# Add `@noescape` to public library API\n\n* Proposal: [SE-0012](0012-add-noescape-to-public-library-api.md)\n* Author: [Ja"
},
{
"path": "proposals/0013-remove-partial-application-super.md",
"chars": 4414,
"preview": "# Remove Partial Application of Non-Final Super Methods (Swift 2.2)\n\n* Proposal: [SE-0013](0013-remove-partial-applicati"
},
{
"path": "proposals/0014-constrained-AnySequence.md",
"chars": 3176,
"preview": "# Constraining `AnySequence.init`\n\n* Proposal: [SE-0014](0014-constrained-AnySequence.md)\n* Author: [Max Moiseev](https:"
},
{
"path": "proposals/0015-tuple-comparison-operators.md",
"chars": 4234,
"preview": "# Tuple comparison operators\n\n* Proposal: [SE-0015](0015-tuple-comparison-operators.md)\n* Author: [Lily Ballard](https:/"
},
{
"path": "proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md",
"chars": 5254,
"preview": "# Add initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer\n\n* Proposal: [SE-0016](0016-in"
},
{
"path": "proposals/0017-convert-unmanaged-to-use-unsafepointer.md",
"chars": 4351,
"preview": "# Change `Unmanaged` to use `UnsafePointer`\n\n* Proposal: [SE-0017](0017-convert-unmanaged-to-use-unsafepointer.md)\n* Aut"
},
{
"path": "proposals/0018-flexible-memberwise-initialization.md",
"chars": 36216,
"preview": "# Flexible Memberwise Initialization\n\n* Proposal: [SE-0018](0018-flexible-memberwise-initialization.md)\n* Author: [Matth"
},
{
"path": "proposals/0019-package-manager-testing.md",
"chars": 9628,
"preview": "# Swift Testing\n\n* Proposal: [SE-0019](0019-package-manager-testing.md)\n* Authors: [Max Howell](https://github.com/mxcl)"
},
{
"path": "proposals/0020-if-swift-version.md",
"chars": 3256,
"preview": "# Swift Language Version Build Configuration\n\n* Proposal: [SE-0020](0020-if-swift-version.md)\n* Author: [Ashley Garland]"
},
{
"path": "proposals/0021-generalized-naming.md",
"chars": 6763,
"preview": "# Naming Functions with Argument Labels\n\n* Proposal: [SE-0021](0021-generalized-naming.md)\n* Author: [Doug Gregor](https"
},
{
"path": "proposals/0022-objc-selectors.md",
"chars": 7506,
"preview": "# Referencing the Objective-C selector of a method\n\n* Proposal: [SE-0022](0022-objc-selectors.md)\n* Author: [Doug Gregor"
},
{
"path": "proposals/0023-api-guidelines.md",
"chars": 3215,
"preview": "# API Design Guidelines\n\n* Proposal: [SE-0023](0023-api-guidelines.md)\n* Authors: [Dave Abrahams](https://github.com/dab"
},
{
"path": "proposals/0024-optional-value-setter.md",
"chars": 2018,
"preview": "# Optional Value Setter `??=`\n\n* Proposal: [SE-0024](0024-optional-value-setter.md)\n* Author: [James Campbell](https://g"
},
{
"path": "proposals/0025-scoped-access-level.md",
"chars": 11140,
"preview": "# Scoped Access Level\n\n* Proposal: [SE-0025](0025-scoped-access-level.md)\n* Author: Ilya Belenkiy\n* Status: **Implemente"
},
{
"path": "proposals/0026-abstract-classes-and-methods.md",
"chars": 4869,
"preview": "# Abstract classes and methods\n\n* Proposal: [SE-0026](0026-abstract-classes-and-methods.md)\n* Author: David Scrève\n* Rev"
},
{
"path": "proposals/0027-string-from-code-units.md",
"chars": 6964,
"preview": "# Expose code unit initializers on String\n\n* Proposal: [SE-0027](0027-string-from-code-units.md)\n* Author: [Zachary Wald"
},
{
"path": "proposals/0028-modernizing-debug-identifiers.md",
"chars": 6771,
"preview": "# Modernizing Swift's Debugging Identifiers\n\n* Proposal: [SE-0028](0028-modernizing-debug-identifiers.md)\n* Author: [Eri"
},
{
"path": "proposals/0029-remove-implicit-tuple-splat.md",
"chars": 7441,
"preview": "# Remove implicit tuple splat behavior from function applications\n\n* Proposal: [SE-0029](0029-remove-implicit-tuple-spla"
},
{
"path": "proposals/0030-property-behavior-decls.md",
"chars": 34390,
"preview": "# Property Behaviors\n\n* Proposal: [SE-0030](0030-property-behavior-decls.md)\n* Author: [Joe Groff](https://github.com/jc"
},
{
"path": "proposals/0031-adjusting-inout-declarations.md",
"chars": 2468,
"preview": "# Adjusting `inout` Declarations for Type Decoration\n\n* Proposal: [SE-0031](0031-adjusting-inout-declarations.md)\n* Auth"
},
{
"path": "proposals/0032-sequencetype-find.md",
"chars": 2801,
"preview": "# Add `first(where:)` method to `Sequence`\n\n* Proposal: [SE-0032](0032-sequencetype-find.md)\n* Author: [Lily Ballard](ht"
},
{
"path": "proposals/0033-import-objc-constants.md",
"chars": 8270,
"preview": "# Import Objective-C Constants as Swift Types\n\n* Proposal: [SE-0033](0033-import-objc-constants.md)\n* Author: [Jeff Kell"
},
{
"path": "proposals/0034-disambiguating-line.md",
"chars": 3856,
"preview": "# Disambiguating Line Control Statements from Debugging Identifiers\n\n* Proposal: [SE-0034](0034-disambiguating-line.md)\n"
},
{
"path": "proposals/0035-limit-inout-capture.md",
"chars": 6589,
"preview": "# Limiting `inout` capture to `@noescape` contexts\n\n* Proposal: [SE-0035](0035-limit-inout-capture.md)\n* Author: [Joe Gr"
},
{
"path": "proposals/0036-enum-dot.md",
"chars": 3954,
"preview": "# Requiring Leading Dot Prefixes for Enum Instance Member Implementations\n\n* Proposal: [SE-0036](0036-enum-dot.md)\n* Aut"
},
{
"path": "proposals/0037-clarify-comments-and-operators.md",
"chars": 5777,
"preview": "# Clarify interaction between comments & operators\n\n* Proposal: [SE-0037](0037-clarify-comments-and-operators.md)\n* Auth"
},
{
"path": "proposals/0038-swiftpm-c-language-targets.md",
"chars": 12685,
"preview": "# Package Manager C Language Target Support\n\n* Proposal: [SE-0038](0038-swiftpm-c-language-targets.md)\n* Author: [Daniel"
},
{
"path": "proposals/0039-playgroundliterals.md",
"chars": 4439,
"preview": "# Modernizing Playground Literals\n\n* Proposal: [SE-0039](0039-playgroundliterals.md)\n* Author: [Erica Sadun](https://git"
},
{
"path": "proposals/0040-attributecolons.md",
"chars": 3659,
"preview": "# Replacing Equal Signs with Colons For Attribute Arguments\n\n* Proposal: [SE-0040](0040-attributecolons.md)\n* Author: [E"
},
{
"path": "proposals/0041-conversion-protocol-conventions.md",
"chars": 11725,
"preview": "# Updating Protocol Naming Conventions for Conversions\n\n* Proposal: [SE-0041](0041-conversion-protocol-conventions.md)\n*"
},
{
"path": "proposals/0042-flatten-method-types.md",
"chars": 5251,
"preview": "# Flattening the function type of unapplied method references\n\n* Proposal: [SE-0042](0042-flatten-method-types.md)\n* Aut"
},
{
"path": "proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md",
"chars": 6012,
"preview": "# Declare variables in 'case' labels with multiple patterns \n\n* Proposal: [SE-0043](0043-declare-variables-in-case-label"
},
{
"path": "proposals/0044-import-as-member.md",
"chars": 12036,
"preview": "# Import as member\n\n* Proposal: [SE-0044](0044-import-as-member.md)\n* Author: [Michael Ilseman](https://github.com/milse"
},
{
"path": "proposals/0045-scan-takewhile-dropwhile.md",
"chars": 7183,
"preview": "# Add prefix(while:) and drop(while:) to the stdlib\n\n* Proposal: [SE-0045](0045-scan-takewhile-dropwhile.md)\n* Author: ["
},
{
"path": "proposals/0046-first-label.md",
"chars": 6201,
"preview": "# Establish consistent label behavior across all parameters including first labels\n\n* Proposal: [SE-0046](0046-first-lab"
},
{
"path": "proposals/0047-nonvoid-warn.md",
"chars": 11212,
"preview": "# Defaulting non-Void functions so they warn on unused results\n\n* Proposal: [SE-0047](0047-nonvoid-warn.md)\n* Authors: ["
},
{
"path": "proposals/0048-generic-typealias.md",
"chars": 2715,
"preview": "# Generic Type Aliases\n\n* Proposal: [SE-0048](0048-generic-typealias.md)\n* Author: [Chris Lattner](https://github.com/la"
},
{
"path": "proposals/0049-noescape-autoclosure-type-attrs.md",
"chars": 4205,
"preview": "# Move @noescape and @autoclosure to be type attributes\n\n* Proposal: [SE-0049](0049-noescape-autoclosure-type-attrs.md)\n"
},
{
"path": "proposals/0050-floating-point-stride.md",
"chars": 14189,
"preview": "# Decoupling Floating Point Strides from Generic Implementations\n\n* Proposal: [SE-0050](0050-floating-point-stride.md)\n*"
},
{
"path": "proposals/0051-stride-semantics.md",
"chars": 7968,
"preview": "# Conventionalizing `stride` semantics\n\n* Proposal: [SE-0051](0051-stride-semantics.md)\n* Author: [Erica Sadun](https://"
},
{
"path": "proposals/0052-iterator-post-nil-guarantee.md",
"chars": 7365,
"preview": "# Change IteratorType post-nil guarantee\n\n* Proposal: [SE-0052](0052-iterator-post-nil-guarantee.md)\n* Author: [Patrick "
},
{
"path": "proposals/0053-remove-let-from-function-parameters.md",
"chars": 3142,
"preview": "# Remove explicit use of `let` from Function Parameters\n\n* Proposal: [SE-0053](0053-remove-let-from-function-parameters."
},
{
"path": "proposals/0054-abolish-iuo.md",
"chars": 8688,
"preview": "# Abolish `ImplicitlyUnwrappedOptional` type\n\n* Proposal: [SE-0054](0054-abolish-iuo.md)\n* Author: [Chris Willmore](http"
},
{
"path": "proposals/0055-optional-unsafe-pointers.md",
"chars": 13674,
"preview": "# Make unsafe pointer nullability explicit using Optional\n\n* Proposal: [SE-0055](0055-optional-unsafe-pointers.md)\n* Aut"
},
{
"path": "proposals/0056-trailing-closures-in-guard.md",
"chars": 4877,
"preview": "# Allow trailing closures in `guard` conditions\n\n* Proposal: [SE-0056](0056-trailing-closures-in-guard.md)\n* Author: [Ch"
},
{
"path": "proposals/0057-importing-objc-generics.md",
"chars": 7768,
"preview": "# Importing Objective-C Lightweight Generics\n\n* Proposal: [SE-0057](0057-importing-objc-generics.md)\n* Author: [Doug Gre"
},
{
"path": "proposals/0058-objectivecbridgeable.md",
"chars": 14775,
"preview": "# Allow Swift types to provide custom Objective-C representations\n\n* Proposal: [SE-0058](0058-objectivecbridgeable.md)\n*"
},
{
"path": "proposals/0059-updated-set-apis.md",
"chars": 9156,
"preview": "# Update API Naming Guidelines and Rewrite Set APIs Accordingly\n\n* Proposal: [SE-0059](0059-updated-set-apis.md)\n* Autho"
},
{
"path": "proposals/0060-defaulted-parameter-order.md",
"chars": 4429,
"preview": "# Enforcing order of defaulted parameters\n\n* Proposal: [SE-0060](0060-defaulted-parameter-order.md)\n* Author: [Joe Groff"
},
{
"path": "proposals/0061-autoreleasepool-signature.md",
"chars": 5269,
"preview": "# Add Generic Result and Error Handling to autoreleasepool()\n\n* Proposal: [SE-0061](0061-autoreleasepool-signature.md)\n*"
},
{
"path": "proposals/0062-objc-keypaths.md",
"chars": 4812,
"preview": "# Referencing Objective-C key-paths\n\n* Proposal: [SE-0062](0062-objc-keypaths.md)\n* Author: [David Hart](https://github."
},
{
"path": "proposals/0063-swiftpm-system-module-search-paths.md",
"chars": 8478,
"preview": "# SwiftPM System Module Search Paths\n\n* Proposal: [SE-0063](0063-swiftpm-system-module-search-paths.md)\n* Author: [Max H"
},
{
"path": "proposals/0064-property-selectors.md",
"chars": 2823,
"preview": "# Referencing the Objective-C selector of property getters and setters\n\n* Proposal: [SE-0064](0064-property-selectors.md"
},
{
"path": "proposals/0065-collections-move-indices.md",
"chars": 24771,
"preview": "# A New Model for Collections and Indices\n\n* Proposal: [SE-0065](0065-collections-move-indices.md)\n* Authors: [Dmitri Gr"
},
{
"path": "proposals/0066-standardize-function-type-syntax.md",
"chars": 7878,
"preview": "# Standardize function type argument syntax to require parentheses\n\n* Proposal: [SE-0066](0066-standardize-function-type"
},
{
"path": "proposals/0067-floating-point-protocols.md",
"chars": 31645,
"preview": "# Enhanced Floating Point Protocols\n\n* Proposal: [SE-0067](0067-floating-point-protocols.md)\n* Author: [Stephen Canon](h"
},
{
"path": "proposals/0068-universal-self.md",
"chars": 4749,
"preview": "# Expanding Swift `Self` to class members and value types\n\n* Proposal: [SE-0068](0068-universal-self.md)\n* Author: [Eric"
},
{
"path": "proposals/0069-swift-mutability-for-foundation.md",
"chars": 35057,
"preview": "# Mutability and Foundation Value Types\n\n* Proposal: [SE-0069](0069-swift-mutability-for-foundation.md)\n* Author: [Tony "
},
{
"path": "proposals/0070-optional-requirements.md",
"chars": 8415,
"preview": "# Make Optional Requirements Objective-C-only\n\n* Proposal: [SE-0070](0070-optional-requirements.md)\n* Author: [Doug Greg"
},
{
"path": "proposals/0071-member-keywords.md",
"chars": 3006,
"preview": "# Allow (most) keywords in member references\n\n* Proposal: [SE-0071](0071-member-keywords.md)\n* Author: [Doug Gregor](htt"
},
{
"path": "proposals/0072-eliminate-implicit-bridging-conversions.md",
"chars": 4596,
"preview": "# Fully eliminate implicit bridging conversions from Swift\n\n* Proposal: [SE-0072](0072-eliminate-implicit-bridging-conve"
},
{
"path": "proposals/0073-noescape-once.md",
"chars": 7705,
"preview": "# Marking closures as executing exactly once\n\n* Proposal: [SE-0073](0073-noescape-once.md)\n* Authors: [Félix Cloutier](h"
},
{
"path": "proposals/0074-binary-search.md",
"chars": 13950,
"preview": "# Implementation of Binary Search functions\n\n* Proposal: [SE-0074](0074-binary-search.md)\n* Authors: [Lorenzo Racca](htt"
},
{
"path": "proposals/0075-import-test.md",
"chars": 5651,
"preview": "# Adding a Build Configuration Import Test\n\n* Proposal: [SE-0075](0075-import-test.md)\n* Author: [Erica Sadun](https://g"
},
{
"path": "proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md",
"chars": 4571,
"preview": "# Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer\n\n* Proposal: ["
},
{
"path": "proposals/0077-operator-precedence.md",
"chars": 17573,
"preview": "# Improved operator declarations\n\n* Proposal: [SE-0077](0077-operator-precedence.md)\n* Author: [Anton Zhilin](https://gi"
},
{
"path": "proposals/0078-rotate-algorithm.md",
"chars": 14095,
"preview": "# Implement a rotate algorithm, equivalent to std::rotate() in C++\n\n* Proposal: [SE-0078](0078-rotate-algorithm.md)\n* Au"
},
{
"path": "proposals/0079-upgrade-self-from-weak-to-strong.md",
"chars": 8623,
"preview": "# Allow using optional binding to upgrade `self` from a weak to strong reference\n\n* Proposal: [SE-0079](0079-upgrade-sel"
},
{
"path": "proposals/0080-failable-numeric-initializers.md",
"chars": 3151,
"preview": "# Failable Numeric Conversion Initializers\n\n* Proposal: [SE-0080](0080-failable-numeric-initializers.md)\n* Author: [Matt"
},
{
"path": "proposals/0081-move-where-expression.md",
"chars": 5488,
"preview": "# Move `where` clause to end of declaration\n\n* Proposal: [SE-0081](0081-move-where-expression.md)\n* Authors: [David Hart"
},
{
"path": "proposals/0082-swiftpm-package-edit.md",
"chars": 12197,
"preview": "# Package Manager Editable Packages\n\n* Proposal: [SE-0082](0082-swiftpm-package-edit.md)\n* Author: [Daniel Dunbar](https"
},
{
"path": "proposals/0083-remove-bridging-from-dynamic-casts.md",
"chars": 18186,
"preview": "# Remove bridging conversion behavior from dynamic casts\n\n* Proposal: [SE-0083](0083-remove-bridging-from-dynamic-casts."
},
{
"path": "proposals/0084-trailing-commas.md",
"chars": 5658,
"preview": "# Allow trailing commas in parameter lists and tuples\n\n* Proposal: [SE-0084](0084-trailing-commas.md)\n* Authors: [Grant "
},
{
"path": "proposals/0085-package-manager-command-name.md",
"chars": 9457,
"preview": "# Package Manager Command Names\n\n* Proposal: [SE-0085](0085-package-manager-command-name.md)\n* Authors: [Rick Ballard](h"
},
{
"path": "proposals/0086-drop-foundation-ns.md",
"chars": 23035,
"preview": "# Drop NS Prefix in Swift Foundation\n\n* Proposal: [SE-0086](0086-drop-foundation-ns.md)\n* Authors: [Tony Parker](https:/"
},
{
"path": "proposals/0087-lazy-attribute.md",
"chars": 1606,
"preview": "# Rename `lazy` to `@lazy`\n\n* Proposal: [SE-0087](0087-lazy-attribute.md)\n* Author: [Anton3](https://github.com/Anton3)\n"
},
{
"path": "proposals/0088-libdispatch-for-swift3.md",
"chars": 31382,
"preview": "# Modernize libdispatch for Swift 3 naming conventions\n\n* Proposal: [SE-0088](0088-libdispatch-for-swift3.md)\n* Author: "
},
{
"path": "proposals/0089-rename-string-reflection-init.md",
"chars": 6663,
"preview": "# Renaming `String.init<T>(_: T)`\n\n* Proposal: [SE-0089](0089-rename-string-reflection-init.md)\n* Authors: [Austin Zheng"
},
{
"path": "proposals/0090-remove-dot-self.md",
"chars": 13604,
"preview": "# Remove `.self` and freely allow type references in expressions\n\n* Proposal: [SE-0090](0090-remove-dot-self.md)\n* Autho"
},
{
"path": "proposals/0091-improving-operators-in-protocols.md",
"chars": 16951,
"preview": "# Improving operator requirements in protocols\n\n* Proposal: [SE-0091](0091-improving-operators-in-protocols.md)\n* Author"
},
{
"path": "proposals/0092-typealiases-in-protocols.md",
"chars": 3102,
"preview": "# Typealiases in protocols and protocol extensions\n\n* Proposal: [SE-0092](0092-typealiases-in-protocols.md)\n* Authors: ["
},
{
"path": "proposals/0093-slice-base.md",
"chars": 2496,
"preview": "# Adding a public `base` property to slices\n\n* Proposal: [SE-0093](0093-slice-base.md)\n* Author: [Max Moiseev](https://g"
},
{
"path": "proposals/0094-sequence-function.md",
"chars": 5454,
"preview": "# Add sequence(first:next:) and sequence(state:next:) to the stdlib\n\n* Proposal: [SE-0094](0094-sequence-function.md)\n* "
},
{
"path": "proposals/0095-any-as-existential.md",
"chars": 3758,
"preview": "# Replace `protocol<P1,P2>` syntax with `P1 & P2` syntax\n\n* Proposal: [SE-0095](0095-any-as-existential.md)\n* Authors: ["
},
{
"path": "proposals/0096-dynamictype.md",
"chars": 2197,
"preview": "# Converting `dynamicType` from a property to an operator\n\n* Proposal: [SE-0096](0096-dynamictype.md)\n* Author: [Erica S"
},
{
"path": "proposals/0097-negative-attributes.md",
"chars": 1501,
"preview": "# Normalizing naming for \"negative\" attributes\n\n* Proposal: [SE-0097](0097-negative-attributes.md)\n* Author: [Erica Sadu"
},
{
"path": "proposals/0098-didset-capitalization.md",
"chars": 1624,
"preview": "# Lowercase `didSet` and `willSet` for more consistent keyword casing\n\n* Proposal: [SE-0098](0098-didset-capitalization."
},
{
"path": "proposals/0099-conditionclauses.md",
"chars": 9184,
"preview": "# Restructuring Condition Clauses\n\n* Proposal: [SE-0099](0099-conditionclauses.md)\n* Authors: [Erica Sadun](https://gith"
},
{
"path": "proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md",
"chars": 11134,
"preview": "# Add sequence-based initializers and merge methods to Dictionary\n\n* Proposal: [SE-0100](0100-add-sequence-based-init-an"
},
{
"path": "proposals/0101-standardizing-sizeof-naming.md",
"chars": 7572,
"preview": "# Reconfiguring `sizeof` and related functions into a unified `MemoryLayout` struct\n\n* Proposal: [SE-0101](0101-standard"
},
{
"path": "proposals/0102-noreturn-bottom-type.md",
"chars": 9311,
"preview": "# Remove `@noreturn` attribute and introduce an empty `Never` type\n\n* Proposal: [SE-0102](0102-noreturn-bottom-type.md)\n"
},
{
"path": "proposals/0103-make-noescape-default.md",
"chars": 5826,
"preview": "# Make non-escaping closures the default\n\n* Proposal: [SE-0103](0103-make-noescape-default.md)\n* Author: [Trent Nadeau]("
},
{
"path": "proposals/0104-improved-integers.md",
"chars": 41756,
"preview": "# Protocol-oriented integers\n\n* Proposal: [SE-0104](0104-improved-integers.md)\n* Authors: [Dave Abrahams](https://github"
},
{
"path": "proposals/0105-remove-where-from-forin-loops.md",
"chars": 7217,
"preview": "# Removing Where Clauses from For-In Loops\n\n* Proposal: [SE-0105](0105-remove-where-from-forin-loops.md)\n* Author: [Eric"
},
{
"path": "proposals/0106-rename-osx-to-macos.md",
"chars": 4039,
"preview": "# Add a `macOS` Alias for the `OSX` Platform Configuration Test\n\n* Proposal: [SE-0106](0106-rename-osx-to-macos.md)\n* Au"
},
{
"path": "proposals/0107-unsaferawpointer.md",
"chars": 63918,
"preview": "# UnsafeRawPointer API\n\n* Proposal: [SE-0107](0107-unsaferawpointer.md)\n* Author: [Andrew Trick](https://github.com/atri"
},
{
"path": "proposals/0108-remove-assoctype-inference.md",
"chars": 8456,
"preview": "# Remove associated type inference\n\n* Proposal: [SE-0108](0108-remove-assoctype-inference.md)\n* Authors: [Douglas Gregor"
},
{
"path": "proposals/0109-remove-boolean.md",
"chars": 2853,
"preview": "# Remove the `Boolean` protocol\r\n\r\n* Proposal: [SE-0109](0109-remove-boolean.md)\r\n* Authors: [Anton Zhilin](https://gith"
},
{
"path": "proposals/0110-distinguish-single-tuple-arg.md",
"chars": 4217,
"preview": "# Distinguish between single-tuple and multiple-argument function types\n\n* Proposal: [SE-0110](0110-distinguish-single-t"
},
{
"path": "proposals/0111-remove-arg-label-type-significance.md",
"chars": 7040,
"preview": "# Remove type system significance of function argument labels\n\n* Proposal: [SE-0111](0111-remove-arg-label-type-signific"
},
{
"path": "proposals/0112-nserror-bridging.md",
"chars": 29398,
"preview": "# Improved NSError Bridging\n\n* Proposal: [SE-0112](0112-nserror-bridging.md)\n* Authors: [Doug Gregor](https://github.com"
},
{
"path": "proposals/0113-rounding-functions-on-floatingpoint.md",
"chars": 5014,
"preview": "# Add integral rounding functions to FloatingPoint\n\n* Proposal: [SE-0113](0113-rounding-functions-on-floatingpoint.md)\n*"
},
{
"path": "proposals/0114-buffer-naming.md",
"chars": 1802,
"preview": "# Updating Buffer \"Value\" Names to \"Header\" Names\n\n* Proposal: [SE-0114](0114-buffer-naming.md)\n* Author: [Erica Sadun]("
},
{
"path": "proposals/0115-literal-syntax-protocols.md",
"chars": 9383,
"preview": "# Rename Literal Syntax Protocols\n\n* Proposal: [SE-0115](0115-literal-syntax-protocols.md)\n* Author: [Matthew Johnson](h"
},
{
"path": "proposals/0116-id-as-any.md",
"chars": 16169,
"preview": "# Import Objective-C `id` as Swift `Any` type\n\n* Proposal: [SE-0116](0116-id-as-any.md)\n* Author: [Joe Groff](https://gi"
},
{
"path": "proposals/0117-non-public-subclassable-by-default.md",
"chars": 19372,
"preview": "# Allow distinguishing between public access and public overridability\n\n* Proposal: [SE-0117](0117-non-public-subclassab"
},
{
"path": "proposals/0118-closure-parameter-names-and-labels.md",
"chars": 4997,
"preview": "# Closure Parameter Names and Labels\n\n* Proposal: [SE-0118](0118-closure-parameter-names-and-labels.md)\n* Authors: [Dave"
},
{
"path": "proposals/0119-extensions-access-modifiers.md",
"chars": 12434,
"preview": "# Remove access modifiers from extensions\n\n* Proposal: [SE-0119](0119-extensions-access-modifiers.md)\n* Author: [Adrian "
},
{
"path": "proposals/0120-revise-partition-method.md",
"chars": 6734,
"preview": "# Revise `partition` Method Signature\n\n* Proposal: [SE-0120](0120-revise-partition-method.md)\n* Authors: [Lorenzo Racca]"
},
{
"path": "proposals/0121-remove-optional-comparison-operators.md",
"chars": 6030,
"preview": "# Remove `Optional` Comparison Operators\n\n* Proposal: [SE-0121](0121-remove-optional-comparison-operators.md)\n* Author: "
},
{
"path": "proposals/0122-use-colons-for-subscript-type-declarations.md",
"chars": 3454,
"preview": "# Use colons for subscript declarations\n\n* Proposal: [SE-0122](0122-use-colons-for-subscript-type-declarations.md)\n* Aut"
},
{
"path": "proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md",
"chars": 8729,
"preview": "# Disallow coercion to optionals in operator arguments\n\n* Proposal: [SE-0123](0123-disallow-value-to-optional-coercion-i"
},
{
"path": "proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md",
"chars": 3401,
"preview": "# `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label\n\n* Proposal: [SE-0124"
},
{
"path": "proposals/0125-remove-nonobjectivecbase.md",
"chars": 13248,
"preview": "# Remove `NonObjectiveCBase` and `isUniquelyReferenced`\n\n* Proposal: [SE-0125](0125-remove-nonobjectivecbase.md)\n* Autho"
},
{
"path": "proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md",
"chars": 25268,
"preview": "# Refactor Metatypes, repurpose `T.self` and `Mirror`\n\n* Proposal: [SE-0126](0126-refactor-metatypes-repurpose-t-dot-sel"
},
{
"path": "proposals/0127-cleaning-up-stdlib-ptr-buffer.md",
"chars": 4423,
"preview": "# Cleaning up stdlib Pointer and Buffer Routines\n\n* Proposal: [SE-0127](0127-cleaning-up-stdlib-ptr-buffer.md)\n* Author:"
},
{
"path": "proposals/0128-unicodescalar-failable-initializer.md",
"chars": 2259,
"preview": "# Change failable UnicodeScalar initializers to failable\n\n* Proposal: [SE-0128](0128-unicodescalar-failable-initializer."
},
{
"path": "proposals/0129-package-manager-test-naming-conventions.md",
"chars": 5895,
"preview": "# Package Manager Test Naming Conventions\n\n* Proposal: [SE-0129](0129-package-manager-test-naming-conventions.md)\n* Auth"
},
{
"path": "proposals/0130-string-initializers-cleanup.md",
"chars": 2771,
"preview": "# Replace repeating `Character` and `UnicodeScalar` forms of String.init\n\n* Proposal: [SE-0130](0130-string-initializers"
},
{
"path": "proposals/0131-anyhashable.md",
"chars": 5029,
"preview": "# Add `AnyHashable` to the standard library\n\n* Proposal: [SE-0131](0131-anyhashable.md)\n* Author: [Dmitri Gribenko](http"
},
{
"path": "proposals/0132-sequence-end-ops.md",
"chars": 54731,
"preview": "# Rationalizing Sequence end-operation names\n\n* Proposal: [SE-0132](0132-sequence-end-ops.md)\n* Authors: [Becca Royal-Go"
},
{
"path": "proposals/0133-rename-flatten-to-joined.md",
"chars": 3834,
"preview": "# Rename `flatten()` to `joined()`\n\n* Proposal: [SE-0133](0133-rename-flatten-to-joined.md)\n* Author: [Jacob Bandes-Stor"
},
{
"path": "proposals/0134-rename-string-properties.md",
"chars": 2943,
"preview": "# Rename two UTF8-related properties on String\n\n* Proposal: [SE-0134](0134-rename-string-properties.md)\n* Authors: [Xiao"
},
{
"path": "proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md",
"chars": 12379,
"preview": "# Package Manager Support for Differentiating Packages by Swift version\n\n* Proposal: [SE-0135](0135-package-manager-supp"
},
{
"path": "proposals/0136-memory-layout-of-values.md",
"chars": 4234,
"preview": "# Memory layout of values\n\n* Proposal: [SE-0136](0136-memory-layout-of-values.md)\n* Author: [Xiaodi Wu](https://github.c"
},
{
"path": "proposals/0137-avoiding-lock-in.md",
"chars": 4005,
"preview": "# Avoiding Lock-In to Legacy Protocol Designs\n\n* Proposal: [SE-0137](0137-avoiding-lock-in.md)\n* Authors: [Dave Abrahams"
},
{
"path": "proposals/0138-unsaferawbufferpointer.md",
"chars": 41307,
"preview": "# UnsafeRawBufferPointer\n\n* Proposal: [SE-0138](0138-unsaferawbufferpointer.md)\n* Author: [Andrew Trick](https://github."
},
{
"path": "proposals/0139-bridge-nsnumber-and-nsvalue.md",
"chars": 6046,
"preview": "# Bridge Numeric Types to `NSNumber` and Cocoa Structs to `NSValue`\n\n* Proposal: [SE-0139](0139-bridge-nsnumber-and-nsva"
},
{
"path": "proposals/0140-bridge-optional-to-nsnull.md",
"chars": 9154,
"preview": "# Warn when `Optional` converts to `Any`, and bridge `Optional` As Its Payload Or `NSNull`\n\n* Proposal: [SE-0140](0140-b"
},
{
"path": "proposals/0141-available-by-swift-version.md",
"chars": 5004,
"preview": "# Availability by Swift version\n\n* Proposal: [SE-0141](0141-available-by-swift-version.md)\n* Author: [Graydon Hoare](htt"
},
{
"path": "proposals/0142-associated-types-constraints.md",
"chars": 4103,
"preview": "# Permit where clauses to constrain associated types\n\n* Proposal: [SE-0142](0142-associated-types-constraints.md)\n* Auth"
},
{
"path": "proposals/0143-conditional-conformances.md",
"chars": 27763,
"preview": "# Conditional conformances\n\n* Proposal: [SE-0143](0143-conditional-conformances.md)\n* Author: [Doug Gregor](https://gith"
},
{
"path": "proposals/0144-allow-single-dollar-sign-as-valid-identifier.md",
"chars": 2720,
"preview": "# Allow Single Dollar Sign as a Valid Identifier\n\n* Proposal: [SE-0144](0144-allow-single-dollar-sign-as-valid-identifie"
},
{
"path": "proposals/0145-package-manager-version-pinning.md",
"chars": 19987,
"preview": "# Package Manager Version Pinning\n\n* Proposal: [SE-0145](0145-package-manager-version-pinning.md)\n* Author: [Daniel Dunb"
},
{
"path": "proposals/0146-package-manager-product-definitions.md",
"chars": 17939,
"preview": "# Package Manager Product Definitions\n\n* Proposal: [SE-0146](0146-package-manager-product-definitions.md)\n* Author: [And"
},
{
"path": "proposals/0147-move-unsafe-initialize-from.md",
"chars": 11259,
"preview": "# Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer\n\n* Proposal: [SE-0147](0147-move-unsafe-init"
},
{
"path": "proposals/0148-generic-subscripts.md",
"chars": 3048,
"preview": "# Generic Subscripts\n\n* Proposal: [SE-0148](0148-generic-subscripts.md)\n* Author: [Chris Eidhof](https://github.com/chri"
},
{
"path": "proposals/0149-package-manager-top-of-tree.md",
"chars": 3622,
"preview": "# Package Manager Support for Top of Tree development\n\n* Proposal: [SE-0149](0149-package-manager-top-of-tree.md)\n* Auth"
},
{
"path": "proposals/0150-package-manager-branch-support.md",
"chars": 4850,
"preview": "# Package Manager Support for branches\n\n* Proposal: [SE-0150](0150-package-manager-branch-support.md)\n* Author: [Boris B"
},
{
"path": "proposals/0151-package-manager-swift-language-compatibility-version.md",
"chars": 6032,
"preview": "# Package Manager Swift Language Compatibility Version\n\n* Proposal: [SE-0151](0151-package-manager-swift-language-compat"
},
{
"path": "proposals/0152-package-manager-tools-version.md",
"chars": 25663,
"preview": "# Package Manager Tools Version\n\n* Proposal: [SE-0152](0152-package-manager-tools-version.md)\n* Author: [Rick Ballard](h"
},
{
"path": "proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md",
"chars": 9467,
"preview": "# Compensate for the inconsistency of `@NSCopying`'s behaviour\n\n* Proposal: [SE-0153](0153-compensate-for-the-inconsiste"
},
{
"path": "proposals/0154-dictionary-key-and-value-collections.md",
"chars": 7776,
"preview": "# Provide Custom Collections for Dictionary Keys and Values\n\n* Proposal: [SE-0154](0154-dictionary-key-and-value-collect"
},
{
"path": "proposals/0155-normalize-enum-case-representation.md",
"chars": 11886,
"preview": "# Normalize Enum Case Representation\n\n* Proposal: [SE-0155][]\n* Authors: [Daniel Duan][], [Joe Groff][]\n* Review Manager"
},
{
"path": "proposals/0156-subclass-existentials.md",
"chars": 8891,
"preview": "# Class and Subtype existentials\n\n* Proposal: [SE-0156](0156-subclass-existentials.md)\n* Authors: [David Hart](https://g"
},
{
"path": "proposals/0157-recursive-protocol-constraints.md",
"chars": 8494,
"preview": "# Support recursive constraints on associated types\n\n* Proposal: [SE-0157](0157-recursive-protocol-constraints.md)\n* Aut"
},
{
"path": "proposals/0158-package-manager-manifest-api-redesign.md",
"chars": 25187,
"preview": "# Package Manager Manifest API Redesign\n\n* Proposal: [SE-0158](0158-package-manager-manifest-api-redesign.md)\n* Author: "
},
{
"path": "proposals/0159-fix-private-access-levels.md",
"chars": 3515,
"preview": "# Fix Private Access Levels\n\n* Proposal: [SE-0159](0159-fix-private-access-levels.md)\n* Author: [David Hart](https://git"
},
{
"path": "proposals/0160-objc-inference.md",
"chars": 24214,
"preview": "# Limiting `@objc` inference\n\n* Proposal: [SE-0160](0160-objc-inference.md)\n* Author: [Doug Gregor](https://github.com/D"
},
{
"path": "proposals/0161-key-paths.md",
"chars": 11670,
"preview": "# Smart KeyPaths: Better Key-Value Coding for Swift\n\n* Proposal: [SE-0161](0161-key-paths.md)\n* Authors: [David Smith](h"
},
{
"path": "proposals/0162-package-manager-custom-target-layouts.md",
"chars": 9571,
"preview": "# Package Manager Custom Target Layouts\n\n* Proposal: [SE-0162](0162-package-manager-custom-target-layouts.md)\n* Author: "
},
{
"path": "proposals/0163-string-revision-1.md",
"chars": 18662,
"preview": "# String Revision: Collection Conformance, C Interop, Transcoding\n\n* Proposal: [SE-0163](0163-string-revision-1.md)\n* Au"
},
{
"path": "proposals/0164-remove-final-support-in-protocol-extensions.md",
"chars": 2131,
"preview": "# Remove final support in protocol extensions\n\n* Proposal: [SE-0164](0164-remove-final-support-in-protocol-extensions.md"
},
{
"path": "proposals/0165-dict.md",
"chars": 24578,
"preview": "# Dictionary & Set Enhancements\n\n* Proposal: [SE-0165](0165-dict.md)\n* Author: [Nate Cook](https://github.com/natecook10"
},
{
"path": "proposals/0166-swift-archival-serialization.md",
"chars": 115859,
"preview": "# Swift Archival & Serialization\n\n* Proposal: [SE-0166](0166-swift-archival-serialization.md)\n* Authors: [Itai Ferber](h"
},
{
"path": "proposals/0167-swift-encoders.md",
"chars": 19996,
"preview": "# Swift Encoders\n\n* Proposal: [SE-0167](0167-swift-encoders.md)\n* Authors: [Itai Ferber](https://github.com/itaiferber),"
},
{
"path": "proposals/0168-multi-line-string-literals.md",
"chars": 6181,
"preview": "# Multi-Line String Literals\n\n* Proposal: [SE-0168](0168-multi-line-string-literals.md)\n* Authors: [John Holdsworth](htt"
},
{
"path": "proposals/0169-improve-interaction-between-private-declarations-and-extensions.md",
"chars": 7972,
"preview": "# Improve Interaction Between `private` Declarations and Extensions\n\n* Proposal: [SE-0169](0169-improve-interaction-betw"
},
{
"path": "proposals/0170-nsnumber_bridge.md",
"chars": 11482,
"preview": "# NSNumber bridging and Numeric types\n\n* Proposal: [SE-0170](0170-nsnumber_bridge.md)\n* Author: [Philippe Hausler](https"
},
{
"path": "proposals/0171-reduce-with-inout.md",
"chars": 4410,
"preview": "# Reduce with `inout`\n\n* Proposal: [SE-0171](0171-reduce-with-inout.md)\n* Author: [Chris Eidhof](https://github.com/chri"
},
{
"path": "proposals/0172-one-sided-ranges.md",
"chars": 8683,
"preview": "# One-sided Ranges\n\n* Proposal: [SE-0172](0172-one-sided-ranges.md)\n* Authors: [Ben Cohen](https://github.com/airspeedsw"
},
{
"path": "proposals/0173-swap-indices.md",
"chars": 4005,
"preview": "# Add `MutableCollection.swapAt(_:_:)`\n\n* Proposal: [SE-0173](0173-swap-indices.md)\n* Author: [Ben Cohen](https://github"
},
{
"path": "proposals/0174-filter-range-replaceable.md",
"chars": 4546,
"preview": "# Change `RangeReplaceableCollection.filter` to return `Self`\n\n* Proposal: [SE-0174](0174-filter-range-replaceable.md)\n*"
},
{
"path": "proposals/0175-package-manager-revised-dependency-resolution.md",
"chars": 13738,
"preview": "# Package Manager Revised Dependency Resolution\n\n* Proposal: [SE-0175](0175-package-manager-revised-dependency-resolutio"
},
{
"path": "proposals/0176-enforce-exclusive-access-to-memory.md",
"chars": 32566,
"preview": "# Enforce Exclusive Access to Memory\n\n* Proposal: [SE-0176](0176-enforce-exclusive-access-to-memory.md)\n* Author: [John "
},
{
"path": "proposals/0177-add-clamped-to-method.md",
"chars": 4346,
"preview": "# Add clamp(to:) to the stdlib\n\n* Proposal: [SE-0177](0177-add-clamped-to-method.md)\n* Author: [Nicholas Maccharoli](htt"
},
{
"path": "proposals/0178-character-unicode-view.md",
"chars": 3140,
"preview": "# Add `unicodeScalars` property to `Character`\n\n* Proposal: [SE-0178](0178-character-unicode-view.md)\n* Author: [Ben Coh"
},
{
"path": "proposals/0179-swift-run-command.md",
"chars": 3553,
"preview": "# Swift `run` Command\n\n* Proposal: [SE-0179](0179-swift-run-command.md)\n* Author: [David Hart](https://github.com/hartbi"
},
{
"path": "proposals/0180-string-index-overhaul.md",
"chars": 14369,
"preview": "# String Index Overhaul\n\n* Proposal: [SE-0180](0180-string-index-overhaul.md)\n* Author: [Dave Abrahams](https://github.c"
},
{
"path": "proposals/0181-package-manager-cpp-language-version.md",
"chars": 2482,
"preview": "# Package Manager C/C++ Language Standard Support\n\n* Proposal: [SE-0181](0181-package-manager-cpp-language-version.md)\n*"
},
{
"path": "proposals/0182-newline-escape-in-strings.md",
"chars": 5270,
"preview": "# String Newline Escaping\n\n* Proposal: [SE-0182](0182-newline-escape-in-strings.md)\n* Authors: [John Holdsworth](https:/"
},
{
"path": "proposals/0183-substring-affordances.md",
"chars": 3423,
"preview": "# Substring performance affordances\n\n* Proposal: [SE-0183](0183-substring-affordances.md)\n* Author: [Ben Cohen](https://"
},
{
"path": "proposals/0184-unsafe-pointers-add-missing.md",
"chars": 26645,
"preview": "# Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation "
},
{
"path": "proposals/0185-synthesize-equatable-hashable.md",
"chars": 15285,
"preview": "# Synthesizing `Equatable` and `Hashable` conformance\n\n* Proposal: [SE-0185](0185-synthesize-equatable-hashable.md)\n* Au"
},
{
"path": "proposals/0186-remove-ownership-keyword-support-in-protocols.md",
"chars": 3114,
"preview": "# Remove ownership keyword support in protocols\n\n* Proposal: [SE-0186](0186-remove-ownership-keyword-support-in-protocol"
}
]
// ... and 371 more files (download for full content)
About this extraction
This page contains the full source code of the swiftlang/swift-evolution GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 571 files (9.4 MB), approximately 2.5M tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.