profile
viewpoint

apple/swift 53945

The Swift Programming Language

apple/swift-evolution 11556

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

benrimmington/swift 0

The Swift Programming Language

benrimmington/swift-corelibs-foundation 0

The Foundation Project, providing core utilities, internationalization, and OS independence

benrimmington/swift-evolution 0

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

push eventbenrimmington/swift

Egor Zhdan

commit sha a4a1ff6442a7b380b380ab04c0ad5ef9ec441d54

WinSDK: prevent windows.h from hijacking imm.h Both `immdev.h` & `windows.h` include `imm.h`, and sometimes this header gets assigned to the module containing `windows.h` (currently `WinSDK.WinSock2`) instead of the Internationalization submodule

view details

Patrick Pijnappel

commit sha 87c177c4b6e22e2e7281328443d644326852f4a6

[stdlib] Change misleading comment

view details

Patrick Pijnappel

commit sha 8ecd884b626a98f7b84ececfc1cbe37dde8f5b59

[stdlib] Expand integer conversion comment

view details

Saleem Abdulrasool

commit sha 74144e4788135649280b134cc260959228e2b6eb

Platform: extract `WLANAPI` module on Windows The WLAN APIs are used for the native WiFi implementation and is not as generally useful. Extract it into a submodule.

view details

Meghana Gupta

commit sha 0044e7dcac6ff176be0945ba0f468967979779d3

[ownership] Move OME past SILMem2Reg

view details

Doug Gregor

commit sha e1852956a065bdeca503c28fec37b3de139f8010

[Concurrency] Drop "get" prefix when importing Objective-C methods as async. Implements rdar://70506634.

view details

Andrew Trick

commit sha b0bda135430ea5bccd471946f850a114aaf8521d

LoadBorrowInvalidation: fix mysteriously inverted boolean returns.

view details

Andrew Trick

commit sha 4f05d8a857f08b42c0def949fe37c99d4131be49

LoadBorrowImmutabilityChecker renaming. Limit names to a straightforward and unambiguous statement of purpose. They should not pose additional questions which can only be answered by reading the code. Nuanced meaning belongs in descriptions and code comments. These are all examples that legitimately made reading the code very difficult for me: - LoadBorrowInvalidationChecker: what does "invalidation" mean in this context? How does that extend the meaning of "checker"? How can something ever pass a checker and not be invalid? - constructValuesForKey outside of an ADT does not state purpose at all. - wellBehavedWriteAccumulator: Raises questions about what writes are included and the broader semantics of the parent function. It turns out that well-behavedness is handled by the function's return value and has nothing to do with the accumulator.

view details

Andrew Trick

commit sha 8e3fb44f2d7981fa443c45386342eeb8cdefb440

Rewrite LoadBorrowImmutabilityChecker using AccessPath. The verification will now be as complete as it can be within the capability of our SIL utilities. It is much more aggressive with respect to boxes, references, and pointers. It's more efficient in that it only considers "overlapping" uses. It is also now wholly consistent with the utilities that it uses, so can be reenabled. We could probably go even further and remove the switch statement entirely, relying on AccessPath to recognize any operations that propagate addresses, boxes, or pointers. But I didn't want to potentially weaken enforcement without more careful consideration.

view details

Andrew Trick

commit sha 0f1beedfb7cb62a8e9c8969152615593a382877e

Reenable load-borrow checker.

view details

Nate Chandler

commit sha 97202faee50f20d1e86be9205b87ca8b801cd342

[Async CC] Put direct returns after indirect returns. For callers who do not know the actual type of the called function, e.g. when the called function is the result of a partial apply, the offset to the direct returns would otherwise not be known.

view details

Nate Chandler

commit sha a9aee1b9ddbba56a27de3a604cecefb17ed042a5

[Async CC] Put bindings after formal arguments. Bindings will always be supplied by the first partial apply, so they will only be added to the async context when its full layout is known. If they are earlier in the layout, subsequent partial applies will put their arguments into the wrong position because they will not be privy to the space requirements of the bindings.

view details

Nate Chandler

commit sha 409f3d253b4f09de15722b4f08d65e7b60f9b461

[NFC] Removed Explosion::peek. The convenience was added to aid with the async calling convention but it has proven to be unnecessary. Here, it is removed.

view details

Nate Chandler

commit sha 0356c9f4c009daea16595a39690be335c70f2367

[NFC] Simplify saving of self to async context.

view details

Nate Chandler

commit sha 63b5ba457e5a36e890fd4846fc9ec0f2b638259c

[NFC] Used consistent style for casting.

view details

Nate Chandler

commit sha 03f4e40f20c512fad34cae93a89144090bda1ee5

[Async CC] Move self after formal arguments. Partial applies of methods supply only self. When applies of the resulting thick function are performed, that self was one of the arguments is not known. As a result, self must appear after the fields that might be supplied at the apply site, which is to say all the arguments.

view details

Argyrios Kyrtzidis

commit sha a9f497d20cdd1fee7953f762f4cd2fe032262026

[utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces Including all the system header dependencies and `stat`ing them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.

view details

Robert Widmann

commit sha af5fa5e31dca51e9b3622c628ad59cace301fd53

Remove `isPrivateToEnclosingFile` Accessor I removed the implementation in #34151

view details

Robert Widmann

commit sha c3881d9651c9383dc1046a4696c5b61f020ddd6f

[NFC] Pull the Computation of Fingerprints Into the Common Base Class

view details

Robert Widmann

commit sha e2e19dcf822eac442605651a5b7bb71ad26c5ae3

Add Compilation "Wave" Assertion in +Asserts Builds The "wave" of a compilation job describes the number of indirections through other compile jobs the driver required to reach the decision to schedule a job. In incremental mode, it should always be the case that it takes no more than two complete waves to arrive at a fixpoint in the build. This is a natural consequence of the structure of the dependencies emitted by the Swift frontend - namely we rely on transitivity in dependency arcs. A quick proof sketch: Suppose an arbitrary perturbation of the inputs to an incremental compilation session are made. In the first wave, dependency edges from the prior build's state (the "zeroeth wave") are loaded and the files corresponding to invalidated edges are scheduled into the first wave. Supposing the second wave is not the null set - the trivial case - there are additional arcs that were invalidated. Now suppose that there were a third wave. Take an arbitrary arc invalidated by this third wave. It must be the case that the file containing the use is not new - else it would be scheduled. Further it must be the case that its def was not invalidated by the zeroeth or first waves of compilation otherwise we would have scheduled it into the first or second waves. Finally, it must have a use that was discovered in the second wave. But in order for that use to have been included in the second wave, there must have been an invalidated arc created by the first wave. By transitivity of dependency arcs, there must therefore be a dependency arc from a definition invalidated in the first wave to our third wave job, which implies that the file would be scheduled into the second wave! [Insert contradiction pig image here]

view details

push time in 9 hours

push eventbenrimmington/swift-evolution

Doug Gregor

commit sha 15b9660ca599fe7eb4ebf6e6473afd505a77a6a1

SE-0289: Use "Swift Next" as implementation version

view details

push time in 9 hours

Pull request review commentapple/swift

[DNM][TypeChecker] Implement Double <-> CGFloat implicit conversion

 class alignas(1 << TypeAlignInBits) TypeBase {      /// Check if this is a nominal type defined at the top level of the Swift module   bool isStdlibType();-  ++  /// Check if this is a CGFloat type from `CoreGraphics` module.+  bool isCGFloatType();+

CGFloat also exists in open-source Foundation.

https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/Foundation/CGFloat.swift

xedin

comment created time in a day

PullRequestReviewEvent

Pull request review commentapple/swift-system

Initial port to Windows

 public struct Errno: RawRepresentable, Error, Hashable, Codable {   public static var EBADMACHO: Errno { malformedMachO } #endif +#if os(Windows)+  /// Operation canceled.+  ///+  /// The scheduled operation was canceled.+  ///+  /// The corresponding C error is `ECANCELED`.+  @_alwaysEmitIntoClient+  public static var canceled: Errno { Errno(_ECANCELLED) }++  @_alwaysEmitIntoClient+  @available(*, unavailable, renamed: "canceled")+  public static var ECANCELED: Errno { canceled }+#else

@compnerd If the internal var _ECANCELLED: CInt { 10103 } can also be renamed, then this #if os(Windows) will exactly match the #else below.

compnerd

comment created time in a day

PullRequestReviewEvent

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test source compatibility

Azoy

comment created time in a day

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

All checks have passed. Should we test source compatibility again?

Azoy

comment created time in a day

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test Windows platform

Azoy

comment created time in 2 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test

Azoy

comment created time in 2 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

S:\jenkins\workspace\swift-PR-windows\swift\test\IRGen\builtin_conformances.swift:3:17: 
error: CHECK-LABEL: expected string not found in input

// CHECK-LABEL: @_swift_tupleEquatable_conf = external global %swift.protocol_conformance_descriptor

                ^
<stdin>:55:1: note: possible intended match here

@_swift_tupleEquatable_conf = external dllimport global %swift.protocol_conformance_descriptor, align 4

^
Azoy

comment created time in 2 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test Windows platform

Azoy

comment created time in 2 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test

Azoy

comment created time in 2 days

push eventbenrimmington/swift-evolution

Saleem Abdulrasool

commit sha 24a746d12bc234a072cb0a61c8abc5fddb1be103

Update 0289-result-builders.md Update the status of the proposal, which has been accepted.

view details

Doug Gregor

commit sha 510866545390364f4faea652aca255ee44b14567

SE-0289 is implemented in GitHub main for Swift 5.4 (#1199)

view details

push time in 3 days

Pull request review commentapple/swift

[Docs] Clarifies `ObjectIdentifier` guarantees

 /// /// In Swift, only class instances and metatypes have unique identities. There /// is no notion of identity for structs, enums, functions, or tuples.+///+/// `ObjectIdentifier` is only guaranteed to remain unique for the+/// lifetime of an object. When the instance gets deallocated, its object +/// identifier may be reused for a different object. (Internally, objects are+/// identified by their memory location.)

That example could give different results, depending on whether:

  • tagged pointers are supported (Apple platforms only), or
  • the allocator decides to reuse the same memory location.

(Although tagged pointers might not be used for Int.min and Int.max).

sunbohong

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentapple/swift-evolution

Update status and implementation of SE-0274

 * Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Dave DeLong](https://github.com/davedelong) * Review Manager: [Ben Cohen](https://github.com/airspeedswift/) * Original review: [Returned for revision](https://forums.swift.org/t/se-0274-concise-magic-file-names/32373/50) -* Status: **Accepted**-* Implementation: Prototype in master behind `-Xfrontend -enable-experimental-concise-pound-file`; revisions in [apple/swift#29412](https://github.com/apple/swift/pull/29412)+* Status: Implemented (Swift 5.3)

This field needs double asterisks, to avoid a "status not found" warning in the proposals data.

* Status: **Implemented (Swift 5.3)**

I'm not sure of the actual status, because SE-0285 extended the transition until Swift 6.

Can the Implementation status section in this proposal be removed?

dabrahams

comment created time in 3 days

PullRequestReviewEvent

PR opened apple/swift-corelibs-foundation

[Windows] `@available` unknown platform warnings

Using @available(Windows) results in warning: unknown platform 'Windows' for attribute 'available'.

This pull request uses @available(*) within #if os(Windows) to avoid the warning.

Alternatively, support for @available(Windows) could be added (e.g. see apple/swift#31686 for OpenBSD).

+14 -12

0 comment

3 changed files

pr created time in 3 days

push eventbenrimmington/swift-corelibs-foundation

Andrew Druk

commit sha 800f207949b48c92251ebd339c712b36afbe23c2

Fix crashes in NSAttributedString replace while enumeration

view details

Tim Kientzle

commit sha 2d7dc96f0626e067d3077de3429cdb00505bf561

Remove an invalid numeric JSON test The value `2.7976931348623158e+308` is a perfectly valid JSON number and should be accepted. This test is only passing today because the Swift standard library's `Double(_ String:)` initializer has a bug that rejected numbers larger than the maximum Double value. But we're getting ready to fix that bug in the Swift standard library, (apple/swift#34339) which will break this test when it lands.

view details

Butta

commit sha e50b83b1a3349aa8ebcc9cd20a598258bdbbad1b

[FileManager] _attributesOfItem: use creationDate from the stat extension in NSURL rather than repeating that logic The last case in stat.creationDate also works for Android.

view details

Simon Evans

commit sha cfef71fe9e0df0a5d6430f6fb202896080a17956

Merge pull request #2903 from tbkka/tbkka/RemoveInvalidNumericTest Remove an invalid numeric JSON test

view details

Saleem Abdulrasool

commit sha 9580a2e6f90a442e02a0b582c6d91c22b8340b0b

Foundation: migrate to the new `CRT` module The Windows environment calls the library `CRT`. Additionally, this enables the removal of the `visualc` module from the Swift SDK overlay for Windows.

view details

Alexander Smarus

commit sha bd4051bee033c9e40f8f842da81997021a8ab005

Make mach_absolute_time implementation consistent with libdispatch

view details

Saleem Abdulrasool

commit sha 2132247e1deb71a3d8f7d1bf73468e4061baa04d

Merge pull request #2907 from readdle/mach-absolute-time-win [Windows] Make mach_absolute_time implementation consistent with libdispatch

view details

Lily Vulcano

commit sha efe05bc3d2c65db1c1adaa25efd3f20550f3e2b3

Merge pull request #2901 from readdle/fix/attributed-string-replace-in-enumeration Fix crashes in NSMutableAttributedString: modify in an enumeration

view details

Saleem Abdulrasool

commit sha ff29c5b355efdc908f3f89658c68826ffd644b02

Merge pull request #2905 from buttaface/create [FileManager] _attributesOfItem: use creationDate from the stat extension in NSURL

view details

Saleem Abdulrasool

commit sha 46b20d4aa480ea92d31e238d537cfc103afc7335

Merge pull request #2906 from compnerd/CRT Foundation: migrate to the new `CRT` module

view details

push time in 3 days

push eventbenrimmington/swift

Varun Gandhi

commit sha be109b72a576799a018dba368c8495d5a9f0d6e7

[AST] Add method to check if a function type has a non-trivial Clang type.

view details

Martin Boehme

commit sha a5e953b69009b59541420d06496206a26961a976

Add support for calling C++ constructors. Because C++ constructors always take a `this` pointer to the object to be initialized, we mark the SIL function return type with the `@out` attribute. On the IRGen side, we retrofit support for formal indirect return values as well as thin metatypes.

view details

Martin Boehme

commit sha 7ad2eef26508ad92d8d92f2d5546913c0ced3bbd

Only import constructors marked `noexcept`.

view details

Martin Boehme

commit sha 384854810a60a69c8df8a8c0248e209adc28c295

Revert "Only import constructors marked `noexcept`." This reverts commit 29650d8c1f302708a32304d49c703c9ddbf30b75. As discussed here, we want to import all constructors (whether they are marked `noexcept` or not) as non-throwing initializers; https://forums.swift.org/t/handling-c-exceptions/34823/50

view details

Martin Boehme

commit sha fd00bc1f01357ecd264b8216373c23014771c124

Move tests from `CXXInterop` to `Interop/Cxx`. This is the canonical location that we've agreed on.

view details

Martin Boehme

commit sha e6067275a6659cfab8640e68e93a5bba36ddca20

Duplicate changes to GenClangType in ClangTypeConverter. See discussion here: https://github.com/apple/swift/pull/30630#discussion_r398967412

view details

Martin Boehme

commit sha b2c5a3eeed4e0d80c819f98c816481fbedc49526

Add a constructor thunk if required to add additional constructor arguments. Also add more IR tests and make various other changes.

view details

Martin Boehme

commit sha 3066e16c37e26a5fea370877409b4d0bd1c0fea6

Remove redundant "cxx" from test names.

view details

Martin Boehme

commit sha 5644137ea0696164c5b5835179b1ec450d508c88

Eliminate duplication of code for adding empty argument names.

view details

Martin Boehme

commit sha bed26039446c189a82c453126e0a622e43c6256d

Various changes after merging master: - Adapt tests to changes that have happened in the meantime (e.g. `HasVirtualBase` is rightly no longer considered loadable) - Don't import copy or move constructors (noticed this because references are now imported correctly, so copy and move constructors suddenly started showing up in the SIL test) - Don't try to define an implicitly-deleted default constructor (this previously broke loadable-types-silgen.swift)

view details

Martin Boehme

commit sha beaaa742c3e774b6739de26bb1a3f0c8761512a5

Don't put an `sret` attribute on the `this` argument.

view details

Martin Boehme

commit sha 8416ccfa06d05da67af70a8ed57a2f120ea251b2

Rename constructors-ir.swift to constructors-irgen.swift.

view details

Martin Boehme

commit sha 8f6042aa0870a527505262c7dbe89ec7ffe20e12

Add additional IR tests for a class without a virtual base class.

view details

Martin Boehme

commit sha c9405fb7fc338f59db4386488245a3ce82227e00

Add Windows-name-mangled version of symbol to SIL test.

view details

Martin Boehme

commit sha cb4ddda6e2292c584cb83905f3f9df17a4e017f1

Avoid crashing if lldb imports C++ structs without enabling C++ interop.

view details

Martin Boehme

commit sha 33e8c717f2682b913eb04e1c7746c84315be90ef

Update comment in VisitCXXRecordDecl().

view details

Martin Boehme

commit sha 7e8ea120701b33958a1adca9e885a99f5d583607

Respond to review comments.

view details

Martin Boehme

commit sha 1ce3753d08522cefe255f4acf498dba5085aa60a

Another response to review comments.

view details

Martin Boehme

commit sha faca489c6f524096019fd124cba847949972e0db

Add a test that Objective-C types passed to a C++ constructor are bridged correctly.

view details

Martin Boehme

commit sha 83b51b95b534108494de1032bb4e098274fe606b

Add SILGen and IRGen tests for passing Objective-C types to C++ constructors.

view details

push time in 3 days

push eventbenrimmington/swift

Butta

commit sha 69d04aad08da3245f87c6a2df35869126d48b55e

[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.

view details

Joe Groff

commit sha 3364c51b1d53fd22a3adbaf3d406bd6685535221

SIL: Verify invariants of async_continuation instructions. - Enforce types of continuations and resume/error BBargs for await - Can't access the continuation again or exit the function mid-suspend

view details

Saleem Abdulrasool

commit sha 2fc5cbdc14dfee3b27070d3f0c761e89f23b01d0

stdlib: remove `swiftMSVCRT`, replace with `swiftCRT` on Windows This replaces swiftMSVCRT with swiftCRT. The big difference here is that the `visualc` module is no longer imported nor exported. The `visualc` module remains in use for a singular test wrt availability, but this should effectively remove the need for the `visualc` module. The difference between the MSVCRT and ucrt module was not well understood by most. MSVCRT provided ucrt AND visualc, combining pieces of the old MSVCRT and the newer ucrt. The ucrt module is what you really wanted most of the time, however, would need to use MSVCRT for the convenience aliases for type-generic math and the deprecated math constants. Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK overlay for ucrt as that seems to result in circular dependencies when processing the `_Concurrency` module. Although this makes using the C library easier for most people, it has a more important subtle change: it cleaves the dependency on visualc. This means that this enables use of Swift without Visual Studio for the singular purpose of providing 3 header files. Additionally, it removes the need for the installation of 2 of the 4 support files. This greatly simplifies the deployment process on Windows.

view details

Pavel Yaskevich

commit sha 17f7ad82cac717a0be4e8417a136348fb0365ca9

[CSBindings] Record all of the protocol requirements (not just literal)

view details

Pavel Yaskevich

commit sha 0c51159228992019f029530844d7c482256b2ed2

[CSBindings] Record constraint associated with a subtype relationship While inferring bindings, let's record not only the fact that current type variable is a subtype of some other type variable but track constraint which establishes this relationship.

view details

Pavel Yaskevich

commit sha a9cce605a4a4062366ce7c4ef2afedd055e79f2c

[CSBindings] Shrink binding "sources" to supertype and equivalence only Instead of recording all of the binding "sources" let's only record subtype, supertype and equivalence relationships which didn't materialize as bindings (because other side is a type variable). This is the only information necessary to infer transitive bindings and protocol requirements.

view details

Pavel Yaskevich

commit sha d011bf3d7d72adc8235d336a202241f8cda62971

[CSBindings] Implement transtive protocol requirement inference Implements iterative protocol requirement inference through subtype, conversion and equivalence relationships. This algorithm doesn't depend on a type variable finalization order (which is currently the order of type variable introduction). If a given type variable doesn't yet have its transitive protocol requirements inferred, algorithm would use iterative depth-first walk through its supertypes and equivalences and incrementally infer transitive protocols for each type variable involved, transferring new information down the chain e.g. T1 T3 \ / T4 T5 \ / T2 Here `T1`, `T3` are supertypes of `T4`, `T4` and `T5` are supertypes of `T2`. Let's assume that algorithm starts at `T2` and none of the involved type variables have their protocol requirements inferred yet. First, it would consider supertypes of `T2` which are `T4` and `T5`, since `T5` is the last in the chain algorithm would transfer its direct protocol requirements to `T2`. `T4` has supertypes `T1` and `T3` - they transfer their direct protocol requirements to `T4` and `T4` transfers its direct and transitive (from `T1` and `T3`) protocol requirements to `T2`. At this point all the type variables in subtype chain have their transitive protocol requirements resolved and cached so they don't have to be re-inferred later.

view details

Pavel Yaskevich

commit sha 5dc9919aff788fc71ab69603db997f0a45ca258e

[ConstraintSystem] NFC: Make `SemaTest` a friend of `ConstraintSystem` This is necessary in order to have access to private members of a `ConstraintSystem` for testing purposes, such as logic related to potential binding computation.

view details

Pavel Yaskevich

commit sha 1aecea17e41bde3508326c9ae72c47b432ed5c15

[unittest/Sema] Add a helper method to infer bindings for a given type variable This mimics what `determineBestBindings` does but without sorting.

view details

Pavel Yaskevich

commit sha a24383112214c2a23a2008f5b704a0acb513b9fe

[unittest/Sema] Add a test-case for a single hop protocol requirement inference In situations like: `$T0 <convertible> $T1` `$T1 <conforms to> P` `$T0` should know about `P` as a transitive protocol requirement.

view details

Pavel Yaskevich

commit sha 8024b7bef3a3907299656eab5c0dc9ac844a5d05

[CSBindings] Improve equivalence class handling in transitive protocol inference Let all of the members of the equivalence class be represented by the first type variable encountered during the depth-first walk. This means that supertypes are inferred from the members and all of the transitive protocol requirements are distributed among the members upon return back to the "representative".

view details

Pavel Yaskevich

commit sha a3c3981a68f9672e48823fda0661c06df5c9fbc3

[unittest/Sema] NFC: Add a way to create a protocol with a given name and parent type

view details

Pavel Yaskevich

commit sha 9598f1984833a76aaa38cdb080bf997e28dacd1b

[unittest/Sema] Cover transitive protocol inference with unit tests

view details

Erik Eckstein

commit sha 007351223eb96a1a0132953a219b12d9b06ec0e7

MemBehavior: handle begin_access when checking for apply side-effects.

view details

Erik Eckstein

commit sha 68db2e7c6ce6f2bf9cdce1add556ef69971bc6a1

TempRValueOpt: don't use collectLoads in tryOptimizeStoreIntoTemp This refactoring removes a lot of special-casing in collectLoads and also makes tryOptimizeStoreIntoTemp simpler. It's a NFC.

view details

Erik Eckstein

commit sha 673b8873ab2930c0497944411a28070877883591

TempRValueOpt: refactoring: simplify the signature of collectLoads It's sufficient to pass the operand instead of the operand, the user and the operand value. NFC.

view details

Erik Eckstein

commit sha d569031f1a367281871ba18c92f385ffa0cafa7d

TempRValueOpt: move the mayWrite-check for applies from collectLoads to checkNoSourceModification ... where it belongs. This is mostly refactoring, but it also fixes a bug: we don't recurse into a begin_access in collectLoads. If there is an apply in such a scope, the mayWrite-check wouldn't be done. In checkNoSourceModification all instructions are visited, so the check is always done.

view details

Erik Eckstein

commit sha 7c293d8de960045fbe2d1717aa21481d801cd036

TempRValueOpt: fix the handling of begin_access Consider the related end_access instructions as uses to correctly mark the end of the lifetime of the temporary. This fixes a miscompile in case there is a modification of the copy-source between an begin_access and end_access.

view details

Erik Eckstein

commit sha 6310dfcc939d88664d1fb63a908f1139e9cf6b47

TempRValueOpt: fix the handling of load [take] load [take] was not considered as a use and it was not detected if it's in a different basic block. This fixes a miscompile in case there is a modification of the copy-source before a load [take]. rdar://problem/69757314

view details

Erik Eckstein

commit sha 9a10ec7d581345cbfcd15990c54848ca1b25dc8c

SILBuilder: add an API to insert _after_ an instruction. ... and use that API in FullApplySite::insertAfterInvocation. Also change FullApplySite::insertAfterInvocation/insertAfterFullEvaluation to directly pass a SILBuilder instead of just an insertion point to the callback. This makes more sense (given the function names) and simplifies the usages. It's a NFC.

view details

push time in 5 days

Pull request review commentapple/swift

[Docs] Clarifies `ObjectIdentifier` guarantees

 /// /// In Swift, only class instances and metatypes have unique identities. There /// is no notion of identity for structs, enums, functions, or tuples.+///+/// `ObjectIdentifier` is only guaranteed to remain unique for the+/// lifetime of an object. When the instance gets deallocated, its object +/// identifier may be reused for a different object. (Internally, objects are+/// identified by their memory location.)+///+/// If you need an object identifier over the lifetime of an object, it may+/// be appropriate to provide a custom implementation of `Identifiable`.

I don't think this final paragraph is correct.

Firstly, it may be misleading, because a custom implementation of Identifiable won't directly affect ObjectIdentifier.

Secondly, it should say something more like "a unique object identifier over the lifetime of a program".

sunbohong

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentapple/swift

[Docs] Clarifies `ObjectIdentifier` guarantees

 /// In Swift, only class instances and metatypes have unique identities. There /// is no notion of identity for structs, enums, functions, or tuples. @frozen // trivial-implementation

Your documentation comment should be inserted above this @frozen attribute.

sunbohong

comment created time in 5 days

PullRequestReviewEvent

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

@compnerd All checks have passed. Please test on Windows (or else commit 007b850342af9c3b64074edcd29cd8040a10afac can be reverted later).

benrimmington

comment created time in 5 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

I've reported the test failure as SR-13754.

benrimmington

comment created time in 5 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

There was a failure in 'lldb-shell :: SwiftREPL/RedirectInput.test' on Linux.

I can see the files in my working copy, but I can't find them on GitHub.

  • "llvm-project/lldb/test/Shell/SwiftREPL/RedirectInput.test" contains:

    Foo.foo()
    // CHECK: ${{R0}}: String = "A"
    
  • "llvm-project/lldb/test/Shell/SwiftREPL/Inputs/A.swift" contains:

    public class Foo {
      public static func foo() -> String  {
        print("A")
        return "A"
      }
    }
    
  • The expected REPL output is intermixed with the print("A") output:

    $R0: String =A
     "A"
    
benrimmington

comment created time in 5 days

push eventapple/swift

Hans Harck Tønning

commit sha f2f7cc6fb2494074c6ce9cbfe8869f819bc5934a

[docs] Fix a typo in CppInteroperabilityManifesto.md (#34345) The "bridging-std-string" section contained a typo in the C++ header example, compared to the imported Swift header.

view details

push time in 6 days

PR merged apple/swift

[docs] Fix a typo in CppInteroperabilityManifesto.md

The "bridging-std-string" section contained a typo in the C++ header example, compared to the imported Swift header.

+1 -1

2 comments

1 changed file

TheHarcker

pr closed time in 6 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

@compnerd I've applied your suggestions as separate commits.

benrimmington

comment created time in 6 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha e3809b751817f15cc990c51722bf033fcb7f1d54

[POSIX] Simplify _updateTimes and NSDate.init()

view details

Ben Rimmington

commit sha 007b850342af9c3b64074edcd29cd8040a10afac

[Windows] Enable the FileManager modificationDate

view details

push time in 6 days

pull request commentapple/swift

[docs] Fix a typo in CppInteroperabilityManifesto.md

@swift-ci Please smoke test Linux platform

TheHarcker

comment created time in 6 days

pull request commentapple/swift

[docs] Fix a typo in CppInteroperabilityManifesto.md

@swift-ci Please smoke test

TheHarcker

comment created time in 6 days

startedapple/swift

started time in 6 days

startedapple/swift-algorithms

started time in 6 days

startedapple/swift-argument-parser

started time in 6 days

startedapple/swift-atomics

started time in 6 days

startedapple/swift-evolution

started time in 6 days

startedapple/swift-format

started time in 6 days

startedapple/swift-numerics

started time in 6 days

startedapple/swift-system

started time in 6 days

startedapple/swift-evolution

started time in 6 days

startedapple/swift

started time in 6 days

CommitCommentEvent

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

Why are the tests marked as not windows? The file modification time information is available on windows as well IIRC.

An _updateTimes function is available for Windows, but I think the tests would currently fail:

https://github.com/apple/swift-corelibs-foundation/blob/cfef71fe9e0df0a5d6430f6fb202896080a17956/Sources/Foundation/FileManager.swift#L403-L408

benrimmington

comment created time in 7 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

@MaxDesiatov Thanks for your help.

benrimmington

comment created time in 7 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha fb2835f023da26074d7c94d6ce817c75a312bf58

[SR-13300] FileManager _updateTimes (microseconds)

view details

push time in 7 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

This pull request should fix the reported bug on Raspberry Pi OS.

It will also fix an unreported bug on other POSIX platforms (e.g. where 0.5 seconds unexpectedly becomes 500 seconds).

I've updated the test for Linux, to assert that the modification date is almost equal, within an accuracy of 1 second.

benrimmington

comment created time in 7 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha adcb077a7c3c8145e22b73bb6dd9c087825aec66

[SR-13300] FileManager _updateTimes (microseconds)

view details

push time in 7 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

Without this bug fix, time interval 1234567890.5 results in timeval.tv_usec = 0.5e9. This value is:

  • rejected on Raspberry Pi OS (SR-13300);
  • accepted on macOS, but the modification date is 500 seconds later than expected.
benrimmington

comment created time in 7 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha ecbe199a346df96e87f1b6489ccda4d21cc02768

[SR-13300] FileManager _updateTimes (microseconds)

view details

push time in 7 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

What prevents adding tests on Linux, as the bug reported on Jira is reproducible on Linux?

Because the test may fail on Linux, depending on the OS and filesystem:

https://github.com/apple/swift-corelibs-foundation/blob/9ebb4442a45223b252ab714a2c101748a969e2da/Tests/Foundation/Tests/TestURL.swift#L728

benrimmington

comment created time in 7 days

pull request commentapple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

@MaxDesiatov I've added tests for macOS only (1, 2).

benrimmington

comment created time in 7 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha dcbb158b641bcf4c5ff6a04ed092946c9694eb86

[SR-13300] FileManager _updateTimes (microseconds)

view details

push time in 7 days

push eventbenrimmington/swift

Antoine Cœur

commit sha 4c30f8bd6de5487603ed645cc4dd2a2983f4f0ba

appendingPathComponent(:isDirectory:) should account for isDirectory

view details

Xiaodi Wu

commit sha 26cda274ca78b1df246521ba1eeea33285b57d5f

[stdlib] Simplify 'BinaryFloatingPoint.init?<T: BinaryFloatingPoint>(exactly: T)'

view details

Mike Ash

commit sha ece0399d601eec1069131f465bdbe7e16f4c6a50

[Runtime] Have ConcurrentReadableHashMap use 1-byte or 2-byte indices when possible.

view details

Alexis Laferrière

commit sha 14e6772dc04cf778ba393bebc21a0a8b8ada3603

Consider inherited platform unavailability to silence diagnostics rdar://68597591

view details

Holly Borla

commit sha 3a47087cc197aab8970a55ee265d395bc4f6f002

[Parser] Don't resolve decl references in the parser if the declaration has a custom attribute.

view details

Holly Borla

commit sha 9b2cd5e3ffa09063a8b64250cd0c62850a41fd26

[NameLookup] Teach unqualified lookup to resolve backing property wrapper and projected value references

view details

Holly Borla

commit sha b33dbedd9b8d3dc2e6ee28373c69a24764249745

[SILGen] Teach SIlGen to emit local property wrappers

view details

Holly Borla

commit sha 0842b4212773b36778d773331155df6be20d2c21

[SILGen] Only use assign_by_wrapper for wrapped instance properties inside an initializer, and for wrapped local variables.

view details

Holly Borla

commit sha 9bd3d0b67fc9599c693735d98c6ff98defccc8e5

[Property Wrappers] Make sure captures are computed for synthesized property wrapper accessors.

view details

Holly Borla

commit sha d8df6217d32cf7ec970d67bc66ff966df0c1a671

[Property Wrappers] Allow property wrappers on local variables.

view details

Holly Borla

commit sha 21cbdfa337dfa41e108573d5d99c6259bee671c9

[Property Wrappers] Add a VarDecl helper method for visiting synthesized property wrapper vars.

view details

Arnold Schwaighofer

commit sha 8e8c57caf59f043b4046ad0df6e7c358bcac9903

SIL type lowering: Compute IsTypeExpansionSensitive and use it instead of TypeBase's hasOpaqueArchetypePropertiesOrCases A type is IsTypeExpansionSensitive if it contains an opaque result type that influences how the type is lowered. This could be because the type mentions an opaque archetype and therefore we would look through to the underlying type depending on the type expansion and could get a different SIL type. For example '() -> out some P' could lower to '() -> @out Int'. Or this could be because when we lower an aggregate type some of its fields are opaque types that could be looked through and therefore the aggregate has different lowering (e.g address vs. loadable) in different type expansion contexts. By replacing it this change also fixes an infinite recursion in hasOpaqueArchetypePropertiesOrCases. rdar://68798822

view details

Adrian Prantl

commit sha 26b5230f3c93ace3b5ad77ce36826bb5ea5da0d6

Remove stray character.

view details

Holly Borla

commit sha 2a67c651eecb6ccd6384a90961cfee46338c954e

[Property Wrappers] Generalize a few property wrapper decl context checks to check for type context instead of local context. This generalization will help us implement property wrappers on global variables, which should use the same approach of not adding synthesized accessors to the AST and instead lazily visit them in SILGen.

view details

Holly Borla

commit sha 9e373a240540f4bf90ed26981a9e29958445d3c6

[Name Lookup] Remove property wrapper name lookup flags and generalize unqualified lookup of auxiliary decl names.

view details

Holly Borla

commit sha 4bb98baf1364ce63e410c381aed7f9690dc5119f

[SILGen] Add a new CaptureEmission kind specifically for emitting captured local variables for the assign_by_wrapper setter. Since assign_by_wrapper will always be re-written to initialization if the captured local variable is uninitialized, it's unnecessary to mark the capture as an escape. This lets us support out-of-line initialization for local property wrappers.

view details

Cassie Jones

commit sha e01893cb56f989b20ba4309286450105211f031e

[build-script] Add a flag for sccache This adds a flag to enable sccache in order to simplify the build-script invocation, particularly for new contributors.

view details

Holly Borla

commit sha 176391f18208898f24b5a24c5423b48d4c097ace

[Test] Start to add SILGen tests for local property wrappers.

view details

Daniel Rodríguez Troitiño

commit sha fcb51dc9473b6cd75ef69c748981ddfb63db1b47

[windows] XFAIL crash-in-user-code test in MSVC 2017 See also #33383 where this problem is better explained. MSVC doesn't seem to trigger the exception code when no frame pointers are generated. The only thing missing would be for interpreted code to have a more informative crash message. Add a new LLVM Lit feature with the value of the VisualStudioVersion environment variable (it seems to not change even for minor versions, so it is an easy way to figure out the 2017/2019 difference, even if updates are applied). Use the new feature in a XFAIL check in the test.

view details

Cassie Jones

commit sha 6d92486c9a6ddc8b71f7c842d546ae3599be5c30

[build-script] Add SWIFT_ prefix to USE_SCCACHE env var

view details

push time in 7 days

push eventbenrimmington/swift-evolution

Kyle Macomber

commit sha 9d5c3a22cb697cdddedddd74e8d43b8a9018b2d6

SE-0282 update link to atomics package (#1195)

view details

Ling Wang

commit sha 218f37d0507cc02d894d1152179a53b2c02e6d7d

Fix double addressing

view details

Joe Groff

commit sha 513e694e70fc6e4d943783e75f6e86931dd93fe4

Merge pull request #1196 from an0/patch-1 Fix double addressing

view details

push time in 7 days

PR opened apple/swift-corelibs-foundation

[SR-13300] FileManager _updateTimes (microseconds)

The _updateTimes function is multiplying by 1.0e9 as if for nanoseconds, but it should be using 1.0e6 for microseconds.

The timeval.tv_usec value will be too large, hence the EINVAL errno on Raspberry Pi OS (SR-13300).

+2 -2

0 comment

1 changed file

pr created time in 8 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha 98d4196c83ddb51206c22c5b96eb42f1b0cec536

[SR-13300] FileManager _updateTimes (microseconds)

view details

push time in 8 days

create barnchbenrimmington/swift-corelibs-foundation

branch : sr-13300-microseconds

created branch time in 8 days

delete branch benrimmington/swift-corelibs-foundation

delete branch : sr-13300-microseconds

delete time in 8 days

push eventbenrimmington/swift-corelibs-foundation

Ben Rimmington

commit sha a9bda48302ff3c9589ed853506831888404ee218

[SR-13300] FileManager._updateTimes (microseconds)

view details

push time in 8 days

create barnchbenrimmington/swift-corelibs-foundation

branch : sr-13300-microseconds

created branch time in 8 days

fork benrimmington/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence

swift.org

fork in 8 days

issue openedapple/swift-system

Foundation additions

Should the open-source Swift System have a new module, with the same Foundation additions as in the closed-source Swift System?

// MARK: - Foundation Additions

import Foundation

// Available when Foundation is imported with System
@available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
extension FilePath {

    /// Creates a file path from a URL
    ///
    /// The result is nil if `url` doesn't refer to a local file.
    public init?(_ url: URL)
}

// Available when Foundation is imported with System
@available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
extension URL {

    /// Creates a URL from a file path by by copying and validating its UTF-8 contents.
    ///
    /// This initializer does not try to repair ill-formed UTF-8 code unit
    /// sequences. If any are found, the result of the initializer is `nil`.
    ///
    public init?(_ path: FilePath)

    /// Creates a URL from a file path by by copying and validating its UTF-8 contents.
    ///
    /// This initializer does not try to repair ill-formed UTF-8 code unit
    /// sequences. If any are found, the result of the initializer is `nil`.
    ///
    public init?(_ path: FilePath, isDirectory: Bool)
}

created time in 8 days

Pull request review commentapple/swift-system

Initial port to Windows

 public struct Errno: RawRepresentable, Error, Hashable, Codable {   public static var EBADMACHO: Errno { malformedMachO } #endif +#if os(Windows)+  /// Operation canceled.+  ///+  /// The scheduled operation was canceled.+  ///+  /// The corresponding C error is `ECANCELED`.+  @_alwaysEmitIntoClient+  public static var canceled: Errno { Errno(_ECANCELLED) }++  @_alwaysEmitIntoClient+  @available(*, unavailable, renamed: "canceled")+  public static var ECANCELLED: Errno { canceled }+#else

ECANCELED appears to be supported, possibly by defining _CRT_NONSTDC_NO_WARNINGS.

Otherwise, does the above comment need to change?

-  /// The corresponding C error is `ECANCELED`.
+  /// The corresponding C error is `ECANCELLED`.
compnerd

comment created time in 8 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

(Succeeded on Linux. Failed on Windows with link error.)

StdlibUnittest.obj : error LNK2019: unresolved external symbol __imp__swift_tupleEquatable_conf referenced in function $s14StdlibUnittest11expectEqual___10stackTrace9showFrame4file4lineySS_SsSSyXKAA14SourceLocStackVSbSSSutF

Azoy

comment created time in 9 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

Errors due to swift_runtime_unreachable — renamed to swift_unreachable.

Azoy

comment created time in 10 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test source compatibility

Azoy

comment created time in 10 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test Windows platform

Azoy

comment created time in 10 days

pull request commentapple/swift

[SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

@swift-ci Please test

Azoy

comment created time in 10 days

pull request commentapple/swift-evolution

Change leftover links from 'master' to 'main'.

The master branch for apple/swift has already been deleted.

e.g. https://github.com/apple/swift/blob/master/CHANGELOG.md

Branch not found, redirected to default branch.

amartini51

comment created time in 16 days

pull request commentapple/swift-evolution

Dark mode

Duplicate of #1177

behnammodi

comment created time in 16 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }

The existing example is intentional.

@hborla Thanks, I've updated the suggested change.

filip-sakel

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal describes extending property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {+  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+}++struct Percentage {+  @Clamped(to: 0 ... 100)+  var percent = 0+     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // Manual adjustment instead of using the Clamped abstraction.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use @Clamped(to: 0 ... 100) here+    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access wrappedValue manually.+  }+}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Disallowing the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {+  func modify(+    inSeconds seconds: Int,+    block: @escaping (Clamped<Int>) -> Void+  ) { ... }+}++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to +    // access count through+    // `wrappedValue`.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could utilize this feature to expose the mutable state of its data source to its 'content' closure. Thus, instead of manually mutating the data source, as is done here:++```swift+struct MyView: View {+  // A simple Shopping Item that includes+  // a 'quantity' and a 'name' property.+  @State +  private var shoppingItems: [Item]++  var body: some View {+    ForEach(0 ..< shoppingItems.count) { index in+  +      Text(shoppingItems[index].name)+        .onTapGesture {+          // We increase the item's quantity +          // when the user taps the item. +          // Unfortunately, to mutate the item+          // we have to manually index our+          // data source.+          shoppingItems[index].quanity += 1+        }+      +    }+  }+}+```++With an appropriate initializer we would be able to simplify the above code, therefore reducing boilerplate:++```swift+struct MyView: View {+  @State +  private var shoppingItems: [Item]++  var body: some View {+    ForEach($shoppingItems) { @Binding shoppingItem in+    +      Text(shoppingItem.name)+        .onTapGesture {+          shoppingItem.quanity += 1+        }+      +    }+  }+}+```+++## Proposed solution++We propose to extend the contexts were application of property-wrapper types is allowed. Namely, application of such types will be allowed on function and closure parameters:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {+  ...+    +  var projectedValue: Self {+    self+  }+}++func increment(+  @Clamped(to: 0 ... 100) percent: Int = 100+) { ... }++myPercentage+  .modify(inSeconds: 3) { @Clamped percent in+    percent = 100 +  }+```+++## Detailed design++Property wrappers are essentially sugar wrapping a given property with compiler synthesized code. This proposal retains this principle employing the following rules for transformation.++### Property Wrappers on Function Parameters++Function parameters marked with a set of property wrapper custom attributes must conform to the following rules:++1. Each property wrapper type must have a suitable `init(wrappedValue:)` for initializing the property wrapper from an instance of its `wrappedValue` type.+2. Each `wrappedValue` getter must be `nonmutating`.+3. Default values must be expressed in terms of the innermost `wrappedValue` type.++The transformation of a property wrapper parameter will take place is as follows:++1. The external parameter name will remain unchanged.+2. The internal parameter name will be prefixed with an underscore, and the type of this parameter is the backing property wrapper type.+3. A local computed property representing  `wrappedValue` will be synthesized by the compiler and named per the original (non-prefixed) parameter name. The accessors will mirror the `wrappedValue` accessors. A setter will only be synthesized for the local property if the `wrappedValue` setter is `nonmutating`, or if the wrapper is a reference type.+4. If the property wrapper defines a `projectedValue`, a local computed property representing  `projectedValue` will be synthesized by the compiler and named per the original parameter name prefixed with a dollar sign (`$`). The same accessor rules for `wrappedValue` apply to `projectedValue`.+5. When passing an argument to a property wrapper parameter, the compiler will wrap the argument in the appropriate `init(wrappedValue:)` call.++#### Transformation Example:++```swift+@propertyWrapper+struct Percentage {

A simple example might be a property wrapper for when you always want to be given a lowercased string.

func example(@Lowercased _ urlScheme: String) -> Void { ... }

Would the Lowercased initializer be allowed to have a with locale: Locale? = nil default argument?

filip-sakel

comment created time in 17 days

PullRequestReviewEvent

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {++  func modify(+    inSeconds seconds: Int,+    block: @escaping (inout Clamped<Int>) -> Void+  ) { ... }+  +}+++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to access+    // count through 'wrappedValue'.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:++```swift+struct MyView: View {++  // A simple Shopping Item that includes+  // a 'quantity' and a 'name' property.+  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach(0 ..< shoppingItems.count) { index in+  +      TextField("Enter the item's name...", $shoppingItems[index].name)+      +    }+  }+  +}+```++we would – with an appropriate initializer – be able to simplify the above code, reducing boilerplate as a result:++```swift+struct MyView: View {++  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach($shoppingItems) { @Binding shoppingItem in+    +      TextField("Enter the item's name...", $shoppingItem.name)+      +    }+  }+  +}+```+++## Proposed solution++We propose to extend the contexts were application of property-wrapper types is permitted. Namely, application of such types will be allowed on function and closure parameters:+++## Detailed design++Property wrappers are essentially sugar wrapping a given property with compiler synthesized code. This proposal retains this principle employing the following rules for transformation.++### Property Wrappers on Function Parameters++Function parameters marked with a set of compatible property-wrapper custom attributes must conform to the following rules:++1. Property wrapper function parameters must support initialization through their `wrappedValue` type. Therefore, all property-wrapper types must provide a suitable `init(wrappedValue:)`.+2. Each `wrappedValue` getter shall be `nonmutating`.+3. Default values for such parameters must be expressed in terms of the innermost `wrappedValue` type.++Transformation of property-wrapper parameters will be performed as such:++1. The external parameter name will remain unchanged.+2. The internal parameter name will be prefixed with an underscore.+3. The parameter will be bound to the backing property wrapper type.+4. A local computed property representing  `wrappedValue` will be synthesized by the compiler and named per the original (non-prefixed) parameter name. The accessors will mirror the `wrappedValue` accessors. A setter will only be synthesized for the local property if the `wrappedValue` setter is `nonmutating`, or if the wrapper is a reference type.+5. If the property wrapper defines a `projectedValue`, a local computed property representing  `projectedValue` will be synthesized by the compiler and named per the original parameter name prefixed with a dollar sign (`$`). The same accessor rules for `wrappedValue` apply to `projectedValue`.+6. When passing an argument to a property wrapper parameter, the compiler will wrap the argument in the appropriate `init(wrappedValue:)` call.++#### Transformation Example:++```swift+@propertyWrapper+struct Percentage {++  init(wrappedValue: Int) { ... }+    +    +  var wrappedValue: Int {+    get { ... }+    set { ... }+  }+  +}++func reportProgress(+  @Percentage of progress: Int+) { ... }+++reportProgress(of: 50)+```++In the above code, the `reportProgress(of:)` function and its caller are equivalent to:++```swift+func reportProgress(of _progress: Percentage) {++  var progress: Int {+    get { _progress.wrappedValue }+    // The setter accessor is not synthesized+    // because the setter of Percentage's  +    // 'wrappedValue' is mutating.+  }+++  ...+  +}+++reportProgress(of: Percentage(wrappedValue: 50))+```++#### Restrictions on Property Wrapper Function Parameters++##### `@autoclosure`++Function parameters with a property wrapper custom attribute cannot have an `@autoclosure` type. `@autoclosure` is unnecessary for the wrapped value itself because the wrapped value argument at the call-site will always be wrapped in a call to `init(wrappedValue:)`, which already can support `@autoclosure` arguments. Using `@autoclosure` for the backing wrapper type would be misleading, because the type spelled out for the parameter would not be the true autoclosure type. Consider the `reportProgress` example from above with an `@autoclosure` parameter:++```swift+func reportProgress(+  @Percentage progress: @autoclosure () -> Int+) { ... }+++reportProgress(of: 50)+```+The above code would be transformed to:+```swift+func reportProgress(+  progress _progress: @autoclosure () -> Percentage<Int>+) { ... }+++reportProgress(of: Percentage(wrappedValue: 50))+```+The changing type of the `@autoclosure` is incredibly misleading, as it's not obvious that `@autoclosure` applies to the backing wrapper rather than the wrapped value. Therefore, using `@autoclosure` for a property wrapper function parameter will be a compiler error.+++### Property Wrappers on Closure Parameters++Since a property wrapper custom attribute is applied directly to the declaration that will be wrapped, application of a property wrapper type is only available within a closure expression. That is, the signature of a function that contains a closure cannot include the property wrapper attibute. Instead the application of the attrbute will be up to the caller of the function, which supplies the closure argument.
Since a property wrapper custom attribute is applied directly to the declaration that will be wrapped, application of a property wrapper type is only available within a closure expression. That is, the signature of a function that contains a closure cannot include the property wrapper attribute. Instead the application of the attribute will be up to the caller of the function, which supplies the closure argument.
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {++  func modify(+    inSeconds seconds: Int,+    block: @escaping (inout Clamped<Int>) -> Void+  ) { ... }+  +}+++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to access+    // count through 'wrappedValue'.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:++```swift+struct MyView: View {++  // A simple Shopping Item that includes+  // a 'quantity' and a 'name' property.+  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach(0 ..< shoppingItems.count) { index in+  +      TextField("Enter the item's name...", $shoppingItems[index].name)+      +    }+  }+  +}+```++we would – with an appropriate initializer – be able to simplify the above code, reducing boilerplate as a result:++```swift+struct MyView: View {++  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach($shoppingItems) { @Binding shoppingItem in+    +      TextField("Enter the item's name...", $shoppingItem.name)+      +    }+  }+  +}+```+++## Proposed solution++We propose to extend the contexts were application of property-wrapper types is permitted. Namely, application of such types will be allowed on function and closure parameters:+++## Detailed design++Property wrappers are essentially sugar wrapping a given property with compiler synthesized code. This proposal retains this principle employing the following rules for transformation.++### Property Wrappers on Function Parameters++Function parameters marked with a set of compatible property-wrapper custom attributes must conform to the following rules:++1. Property wrapper function parameters must support initialization through their `wrappedValue` type. Therefore, all property-wrapper types must provide a suitable `init(wrappedValue:)`.+2. Each `wrappedValue` getter shall be `nonmutating`.+3. Default values for such parameters must be expressed in terms of the innermost `wrappedValue` type.++Transformation of property-wrapper parameters will be performed as such:++1. The external parameter name will remain unchanged.+2. The internal parameter name will be prefixed with an underscore.

Use terms from the API Design Guidelines?

1. The argument label will remain unchanged.
2. The parameter name will be prefixed with an underscore.
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {++  func modify(+    inSeconds seconds: Int,+    block: @escaping (inout Clamped<Int>) -> Void+  ) { ... }+  +}+++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to access+    // count through 'wrappedValue'.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:++```swift+struct MyView: View {++  // A simple Shopping Item that includes+  // a 'quantity' and a 'name' property.+  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach(0 ..< shoppingItems.count) { index in+  +      TextField("Enter the item's name...", $shoppingItems[index].name)+      +    }+  }+  +}+```++we would – with an appropriate initializer – be able to simplify the above code, reducing boilerplate as a result:++```swift+struct MyView: View {++  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach($shoppingItems) { @Binding shoppingItem in+    +      TextField("Enter the item's name...", $shoppingItem.name)+      +    }+  }+  +}+```+++## Proposed solution++We propose to extend the contexts were application of property-wrapper types is permitted. Namely, application of such types will be allowed on function and closure parameters:
We propose to extend the contexts where application of property-wrapper types is permitted. Namely, application of such types will be allowed on function and closure parameters:
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {++  func modify(+    inSeconds seconds: Int,+    block: @escaping (inout Clamped<Int>) -> Void+  ) { ... }+  +}+++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to access+    // count through 'wrappedValue'.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:++```swift+struct MyView: View {++  // A simple Shopping Item that includes+  // a 'quantity' and a 'name' property.+  @State +  private var shoppingItems: [Item]+++  var body: some View {+    ForEach(0 ..< shoppingItems.count) { index in+  +      TextField("Enter the item's name...", $shoppingItems[index].name)+      +    }+  }+  +}+```++we would – with an appropriate initializer – be able to simplify the above code, reducing boilerplate as a result:

Em dashes?

we would — with an appropriate initializer — be able to simplify the above code, reducing boilerplate as a result:
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:++```swift+extension Percentage {++  func modify(+    inSeconds seconds: Int,+    block: @escaping (inout Clamped<Int>) -> Void+  ) { ... }+  +}+++let myPercentage = Percentage(percent: 50)++myPercentage+  .modify(inSeconds: 3) { percent in+    percent.wrappedValue = 100+    //    ^~~~~~~~~~~~ +    // Again, we have to access+    // count through 'wrappedValue'.+  }+```++In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [Function Builders](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:
In fact, establishing custom behavior on closure parameters is really powerful. For example, if such a feature were supported, it could be used in conjunction with [result builders](https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md) to expose data managed by a 'component' type. For instance, in SwiftUI [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) could leverage this feature to expose the mutable state of its data source to its 'content' closure. This would enable users to more easily work with the data source itself inside the closure instead of accessing the original property, which is particularly painful when working with collections, as shown in this example:
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:
Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively, to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to properties at local or type scope, shattering the illusion that they helped realize in the first place:
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }
  mutating func adding(_ offset: Int) {
    percent += offset
    // Great!
  }
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.
As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the `@Clamped` attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.
Property wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md), and have since become a popular feature, abstracting away common accessor patterns for properties. Currently, applying a property wrapper is permitted on properties at local or type scope. However, with increasing adoption, demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }

To match the 0 ... 100 usage, and the existing clamped(to:) API:

struct Clamped<Bound: Comparable> {

  init(
    wrappedValue: Bound,
    to limits: ClosedRange<Bound>
  ) { ... }
  
  
  var wrappedValue: Bound { 
    get { ... }
    set { ... }
  }
filip-sakel

comment created time in 17 days

Pull request review commentapple/swift-evolution

[Proposal] Extend Property Wrappers to Function and Closure Parameters

+# Extend Property Wrappers to Function and Closure Parameters++* Proposal: [SE-NNNN](NNNN-extend-property-wrappers-to-function-and-closure-parameters.md)+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)+* Review Manager: TBD+* Status: **Awaiting implementation**+++## Introduction++Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md), and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending _where_ property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.+++## Motivation++Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. Therefore, library authors can expose complex behavior through easily understandable property-wrapper types in an efficient manner. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) respectively to expose elaborate behavior through a succint interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to type properties, shattering the illusion that they helped realize in the first place:++```swift+@propertyWrapper+struct Clamped<Value: Comparable> {++  init(+    wrappedValue: Value,+    to range: Range<Value>+  ) { ... }+  +  +  var wrappedValue: Value { +    get { ... }+    set { ... }+  }+  +}+++struct Percentage {++  @Clamped(to: 0 ... 100)+  var percent = 0+     +     +  mutating func increment() {+    percent += 1+    // Great!+  }++  mutating func adding(_ offset: Int) {+    percent += min(100, max(0, offset))+    //         ^~~~~~~~~~~~~~~~~~~~~~~~+    // We are forced to manually adjust 'percent' +    // instead of utilizing the abstraction +    // property wrappers offer.+  }++  mutating func adding(_ offset: Clamped<Int>) {+    //                   ^~~~~~~~~~~~~~~~~~~~+    // Unfortunately, we can't use +    // '@Clamped(to: 0 ... 100)' here.+    +    percent += offset.wrappedValue+    //               ^~~~~~~~~~~~~+    // We must access 'wrappedValue' manually.+  }+  +}+```++As seen in the above example, it is quite awkward and unintuitive that property wrappers cannot be applied to function parameters. In this case, a property wrapper parameter would be useful for expressing and enforcing invariants about the `offset` argument to the `adding` method on `Percentage`. Inability to allow the property wrapper attribute on the `offset` parameter causes the API author to choose between making invariant checking an implementation detail, or forcing the invariant checking on every caller of the API.++This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters nor can code be seperated into functions that accept property wrapper syntax:
This limitation in expressivity is emphasized by the fact that property wrappers were originally sought out to abstract away such patterns.  As a result, elegant APIs are undermined by this limitation. Not only is this limiting users by forcing them to carefully read documentation, which may not cover a specific use case, to make sure no invariants have been violated, but it also limits API authors in what they can create. That is, API authors can't use property-wrapper types in closure parameters, nor can code be separated into functions that accept property wrapper syntax:
filip-sakel

comment created time in 17 days

PullRequestReviewEvent
PullRequestReviewEvent

fork benrimmington/swift-algorithms

Swift Algorithms is an open-source package of sequence and collection algorithms, along with their related types.

fork in 17 days

startedapple/swift-algorithms

started time in 17 days

startedapple/swift-argument-parser

started time in 17 days

startedapple/swift-atomics

started time in 17 days

startedapple/swift-format

started time in 17 days

more