profile
viewpoint

apple/swift-format 1123

Formatting technology for Swift source code

tkremenek/swift 5

The Swift Programming Language

tkremenek/swift-corelibs-foundation 1

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

tkremenek/swift-package-manager 1

The Package Manager for the Swift Programming Language

tkremenek/rouge 0

A pure Ruby code highlighter that is compatible with Pygments

tkremenek/swift-corelibs-xctest 0

The XCTest Project, A Swift core library for providing unit test support

tkremenek/swift-lldb 0

This is the version of LLDB that supports the Swift programming language & REPL.

tkremenek/swift-source-compat-suite 0

The infrastructure and project index comprising the Swift source compatibility suite.

issue commentapple/swift-service-discovery

K8s-based service discovery

Sounds good, looking forward to it 👍

m0wfo

comment created time in an hour

Pull request review commentapple/swift-evolution

[Concurrency] Task Local Values

 A task local key declaration nested under in the `TaskLocalValues` and consists  > This design may remind you of SwiftUI's `@Environment` concept, and indeed the shape of how values are declared is fairly similar. However, it differs tremendously in *where* the child/parent relationship is expressed. In a later section we'll make a more detailed comparison with SwiftUI. -Next, in order to access the value one has to `await Task.local(_:)` it:+Next, in order to access the value one has to `Task.local(_:)` it:  ```swift-func printRequestID() async {-  let id = await Task.local(\.requestID) ?? "<unknown>"+func asyncPrintRequestID() async {+  let id = Task.local(\.requestID)   print("request-id: \(id)") }-``` -Since it is not known statically if the value will be present or not, the returned value is an `Optional<String>`.+func syncPrintRequestID() async {

Yes thanks!

ktoso

comment created time in 4 hours

Pull request review commentapple/swift-evolution

[Concurrency] Task Local Values

+# Task Local Values++* Proposal: [SE-NNNN](NNNN-task-local.md)+* Authors: [Konrad 'ktoso' Malawski](https://github.com/ktoso)+* Review Manager: TBD+* Status: Awaiting review+* Implementation: [apple/swift#34722](https://github.com/apple/swift/pull/34722)++## Table of Contents++* [Introduction](#introduction)+* [Motivation](#motivation)+* [Proposed solution](#proposed-solution)+  * [Task Local Values](#task-local-values-1)+* [Detailed design](#detailed-design)+  * [Declaring task-local values](#declaring-task-local-values)+  * [Binding task-local values](#binding-task-local-values)+    * [Binding values for the duration of a child-task](#binding-values-for-the-duration-of-a-child-task)+  * [Task-local value lifecycle](#task-local-value-lifecycle)+  * [Reading task-local values](#reading-task-local-values)+    * [Reading task-local values: implementation details](#reading-task-local-values-implementation-details)+  * [Similarities and differences with SwiftUI Environment](#similarities-and-differences-with-swiftui-environment)+* [Prior Art](#prior-art)+  * [Kotlin: CoroutineContext[T]](#kotlin-coroutinecontextt)+  * [Java/Loom: Scope Variables](#javaloom-scope-variables)+  * [Go: explicit context passing all the way](#go-explicit-context-passing-all-the-way)+* [Rejected Alternatives](#rejected-alternatives)+  * [Plain-old Thread Local variables](#plain-old-thread-local-variables)+  * [Dispatch Queue Specific Values](#dispatch-queue-specific-values)+* [Intended use-cases](#intended-use-cases)+  * [Use case: Distributed Tracing &amp; Contextual Logging](#use-case-distributed-tracing--contextual-logging)+    * [Contextual Logging](#contextual-logging)+    * [Function Tracing](#function-tracing)+    * [Distributed Tracing](#distributed-tracing)+    * [Future direction: Function wrapper interaction](#future-direction-function-wrapper-interaction)+  * [Use case: Mocking internals (Swift System)](#use-case-mocking-internals-swift-system)+  * [Use case: Progress Monitoring](#use-case-progress-monitoring)+  * [Use case: Executor configuration](#use-case-executor-configuration)+* [Future Directions](#future-directions)+  * [Tracing annotations with Function Wrappers](#tracing-annotations-with-function-wrappers)+* [Revision history](#revision-history)+* [Source compatibility](#source-compatibility)+* [Effect on ABI stability](#effect-on-abi-stability)+* [Effect on API resilience](#effect-on-api-resilience)++## Introduction++With Swift embracing asynchronous functions and actors, asynchronous code will be everywhere. ++Therefore, the need for debugging, tracing and otherwise instrumenting asynchronous code becomes even more necessary than before. At the same time, tools which instrumentation systems could have used before to carry information along requests -- such as thread locals or queue-specific values -- are no longer compatible with Swift's Task-focused take on concurrency.++Previously, tool developers could have relied on thread-local or queue-specific values as containers to associate information with a task and carry it across suspension boundaries. However, these mechanisms do not compose well in general, have known "gotchas" (e.g., forgetting to carefully maintain and clear state from these containers after a task has completed to avoid leaking them), and do not compose at all with Swift's task-first approach to concurrency. Furthermore, those mechanisms do not feel "right" given Swift's focus on Structured Concurrency, because they are inherently unstructured.++This proposal defines the semantics of _Task Local Values_. That is, values which are local to a `Task`.++Task local values set in a task _cannot_ out-live the task, solving many of the pain points relating to un-structured primitives such as thread-locals, as well as aligning this feature closely with Swift's take on Structured Concurrency.++Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/pitch-task-local-values/42829/15)++## Motivation++Task Local Values are a significant improvement over thread-local storage in that it is a better fit for Swift's concurrency model because it takes advantage of its structured nature. In existing code, developers have used thread-local or queue-specific values to associate state with each thread/queue, however the exact semantics of those mechanisms made it difficult and error prone in reality.++Specifically, previously developers could have used thread-local or queue-specific values to achieve some of these features, however the exact semantics of those made it difficult and error prone in reality. ++> The use of thread-locals in highly asynchronous libraries is generally frowned upon because it is so difficult to get right, and generally only adds to the confusion rather than helping one achieve transparent context propagation. +> +> This is why currently [Swift Distributed Tracing](https://github.com/apple/swift-distributed-tracing) had to revert to using explicit context passing, making asynchronous APIs even more verbose than they already are.+++Finally, those mechanisms are outright incompatible with asynchronous code that hops between execution contexts, which also includes Swift's async/await execution semantics which guarantee specific _executors_ or _actors_ to be used for execution, however never guarantees any specific queue or thread use at all.++> For discussion about alternative approaches to this problem please refer to [Prior Art](#prior-art) and [Alternatives Considered](#alternatives-considered).++## Proposed solution++### Task Local Values++Tasks already require the capability to "carry metadata with them," and that metadata used to implement both cancellation, deadlines as well as priority propagation for a `Task` and its child tasks. Specifically Task API's exhibiting similar behavior are: `Task.currentPriority()`, `Task.currentDeadline()` and `Task.isCancelled()`. Task local values do not directly use the same storage mechanism, as cancellation and priority is somewhat optimized because _all_ tasks carry them, but the semantics are the same.++We propose to expose the Task's internal ability to "carry metadata with it" via a Swift API, *aimed for library and instrumentation authors* such that they can participate in carrying additional information with Tasks, the same way as Tasks already do with priority and deadlines and other metadata.++Task local values may only be accessed from contexts that are running in a task: asynchronous functions. As such all operations, except declaring the task-local value's handle are asynchronous operations.++Declaring a task local value begins with declaring a `TaskLocalKey` that will be used to retrieve it from the task:++```swift+extension TaskLocalValues {+  +    public struct RequestIDKey: TaskLocalKey {+      public static var defaultValue: String { "<no-request-id>" } +      +      // alternatively, one may declare a nil default value:+      //     public static var defaultValue: String? { nil } +    }+    public var requestID: RequestIDKey { .init() }+  +}+```++A task local key declaration nested under in the `TaskLocalValues` and consists of two things:++- a `TaskLocalKey` type declaration, where the `defaultValue`'s type is used to infer the type of the task local value+  - depending on the value, one might opt for declaring the type as `Optional` or not, for example if a good "empty" default value exists for the type+- a computed property `requestID` which returning the key - it is only used to lookup the key, and no set operation is necessary for it (unlike in SwiftUI's Environment model, due to differences in how the values are actually looked up). ++> This design may remind you of SwiftUI's `@Environment` concept, and indeed the shape of how values are declared is fairly similar. However, it differs tremendously in *where* the child/parent relationship is expressed. In a later section we'll make a more detailed comparison with SwiftUI.++Next, in order to access the value one has to `Task.local(_:)` it:++```swift+func asyncPrintRequestID() async {+  let id = Task.local(\.requestID)+  print("request-id: \(id)")+}++func syncPrintRequestID() async {
func syncPrintRequestID() {

yes thanks!

ktoso

comment created time in 5 hours

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 struct TextEditor { } ``` +### Extending property wrappers to patterns++Property-wrapper backing-storage initialization in the the pattern of a closure argument was supported in first revision. Building on this syntax, the core team suggested the extension of property-wrapper application to places where patterns exist. Of course, the design has been amended so as to preserve the expectation that the backing storage be private; extending property wrappers to patterns, though, is still a viable future direction. ++Enabling the application of property wrappers where patterns are available is quite straightforward and could be introduced in as part of two separate features. The first could be to enable utility wrappers –– such as `@Asserted` –– in patterns. The second could be enabling projected-value initialization, which would facilitate intuitive and effortless access to property wrappers in native language constructs, as shown below:

It's pretty clear that this future direction would involve a lot of design work. I think trying to get into that design here is distracting, so I think we should simplify the section and just say that it was suggested as a design for closures, we chose not to go with that design because it makes more sense for closures to behave the same way as functions, but property wrappers in patterns is still something that could be pursued in the future

filip-sakel

comment created time in 5 hours

pull request commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

@xAlien95 Yes, I rewrote a for-loop into this while-loop forgetting to add an iterator and "start" is a typo.

Thanks!

filip-sakel

comment created time in 8 hours

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 struct TextEditor { } ``` +### Extending property wrappers to patterns++Property-wrapper backing-storage initialization in the the pattern of a closure argument was supported in first revision. Building on this syntax, the core team suggested the extension of property-wrapper application to places where patterns exist. Of course, the design has been amended so as to preserve the expectation that the backing storage be private; extending property wrappers to patterns, though, is still a viable future direction. ++Enabling the application of property wrappers where patterns are available is quite straightforward and could be introduced in as part of two separate features. The first could be to enable utility wrappers –– such as `@Asserted` –– in patterns. The second could be enabling projected-value initialization, which would facilitate intuitive and effortless access to property wrappers in native language constructs, as shown below:

Sorry for taking so long to reply!

What type is the user providing on the right side?

The user is providing the wrapped value's type; I'll clarify that.

Is this initializing a new property wrapper, or "binding" userRatings to the wrapped value of an existing property wrapper?

That's what I meant by two features: the first feature is initializing a new property wrapper that wraps a given value extracted by the pattern; the second is binding the wrapped declaration to an existing property wrapper.

I thought the goal of property wrappers in patterns was the latter.

I think it could be both; being able to apply a wrapper to a value extracted by a pattern (i.e. a value extracted by the pattern found in guard let) would too be immensely useful. For instance, application of a wrapper to the entire –– "non-extracted" –– value is sometimes pointless (it does not make sense to apply @Lowercased to a String?-bound declaration).

Do you think the feature should be separated into two different future directions?

filip-sakel

comment created time in 8 hours

created tagapple/swift-tools-support-core

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

Contains common infrastructural code for both SwiftPM and llbuild.

created time in 10 hours

created tagapple/swift-syntax

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

SwiftPM package for SwiftSyntax library.

created time in 10 hours

created tagapple/swift-xcode-playground-support

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

Logging and communication to allow Swift toolchains to communicate with Xcode.

created time in 10 hours

created tagapple/swift-integration-tests

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

Automated tests for validating the generated Swift snapshots behave correctly

created time in 10 hours

created tagapple/swift-corelibs-libdispatch

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

created time in 10 hours

created tagapple/swift-corelibs-xctest

tagswift-5.4-DEVELOPMENT-SNAPSHOT-2021-01-23-a

The XCTest Project, A Swift core library for providing unit test support

created time in 10 hours

issue closedapple/swift-service-discovery

K8s-based service discovery

Hey all, sorry for posting here but I couldn't find a good sub-category for service discovery on the swift server forum- just a heads up that we've started on an implementation (albeit an alpha-ish one) based on the protocols in this library to solve our problem of pod discovery in a Kubernetes environment. We also had to roll our own one-class fixed-list implementation for local dev where a k8s api is not available, not sure if there's a better way of doing that.

Anyway, progress so far, FWIW is here, if there's any community appetite for this then we're ok with scheduling some time to update documentation, e.t.c.

closed time in 11 hours

m0wfo

issue commentapple/swift-service-discovery

K8s-based service discovery

@ktoso @yim-lee Found some time to add some documentation and start integration testing this- I guess I'll close this as either tuplestream/swift-k8s-service-discovery or the Swift Forum is a better place to discuss future changes.

m0wfo

comment created time in 11 hours

pull request commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

@lattner If you mean me, then yes, Wednesday works!

filip-sakel

comment created time in 12 hours

pull request commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

@lattner Yes, that works for me. I'll make sure this is merged by Wednesday.

filip-sakel

comment created time in 13 hours

Pull request review commentapple/swift-evolution

[Concurrency] Task Local Values

 A task local key declaration nested under in the `TaskLocalValues` and consists  > This design may remind you of SwiftUI's `@Environment` concept, and indeed the shape of how values are declared is fairly similar. However, it differs tremendously in *where* the child/parent relationship is expressed. In a later section we'll make a more detailed comparison with SwiftUI. -Next, in order to access the value one has to `await Task.local(_:)` it:+Next, in order to access the value one has to `Task.local(_:)` it:  ```swift-func printRequestID() async {-  let id = await Task.local(\.requestID) ?? "<unknown>"+func asyncPrintRequestID() async {+  let id = Task.local(\.requestID)   print("request-id: \(id)") }-``` -Since it is not known statically if the value will be present or not, the returned value is an `Optional<String>`.+func syncPrintRequestID() async {

Is this meant to be non-async?

ktoso

comment created time in 16 hours

push eventapple/swift-http-structured-headers

Fabian Fett

commit sha d4233da1ede19678171e6e6f0c8e003cbb97de7e

Use welcoming language (#8)

view details

push time in 19 hours

PR merged apple/swift-http-structured-headers

Use welcoming language

To comply with the new Swift code of conduct, let's make the language a little more welcoming.

Modifications:

  • Replaced usages of "sanity" with "soundness"
  • Added "sanity" to the list of unacceptable terms.
  • Changed the CI name to soundness

Result:

  • Swift HTTP Structured Headers is nicer.
+18 -3

5 comments

2 changed files

fabianfett

pr closed time in 19 hours

PR opened apple/swift-algorithms

Fix RandomSample crash when 0 was out from random.

Fix https://github.com/apple/swift-algorithms/issues/69 .

I changed the random ranges from [0, 1) to (0, 1] . w must not be 0 so fixed nextW too. (in log(1 - w), log(1) is 0 so zero division happens.)

Checklist

  • [x] I've added at least one test that validates that my change is working, if appropriate
  • [x] I've followed the code style of the rest of the project
  • [x] I've read the Contribution Guidelines
  • [x] I've updated the documentation if necessary
+7 -2

0 comment

2 changed files

pr created time in 20 hours

issue openedapple/swift-algorithms

randomSample crashes randomly

randomSample may have crash in case of 0 was out from Double.random(in: 0..<1). log(0) is invalid because the domain of log(x) is 0 < x. It seems that Double.log(0.0) produces -inf.

(lldb) po Double.log(0.0)
-inf

-inf cannot cast to Int so the next crash happens.

Swift Algorithms version: 0.0.2 Swift version: Paste the output of swift --version here

Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0

Checklist

  • [x] If possible, I've reproduced the issue using the main branch of this package
  • [x] I've searched for existing GitHub issues

Steps to Reproduce

I can reproduce this behavior from the code below.

var generator = SplitMix64(seed: 0x61c8864680b583eb) // this generator outs `0` first.
_ = c.randomSample(count: k, using: &generator) // crash!

Expected behavior

Does not crash.

Actual behavior

pasted screeenshot above.

created time in 20 hours

delete branch apple/swift-distributed-tracing-baggage-core

delete branch : wip-soundness

delete time in 21 hours

push eventapple/swift-distributed-tracing-baggage-core

Konrad `ktoso` Malawski

commit sha 79f17a16dd2be224faadb4584d782294cc6a8d90

use inclusive language (#5) * use inclusive language * Update scripts/validate_language.sh Co-authored-by: Yim Lee <yim_lee@apple.com> Co-authored-by: Yim Lee <yim_lee@apple.com>

view details

push time in 21 hours

PR merged apple/swift-distributed-tracing-baggage-core

Reviewers
use inclusive language

This removes use of "sanity" and adds the language check.

I don't have enough admin powers on this repo to unset the pull request validation (sanity) from being required (and mark the soundness one instead).

+38 -6

1 comment

5 changed files

ktoso

pr closed time in 21 hours

push eventapple/swift-distributed-tracing-baggage-core

Konrad `ktoso` Malawski

commit sha 9131f82d3b563963538081aa6343dc2f43ed7656

Update scripts/validate_language.sh Co-authored-by: Yim Lee <yim_lee@apple.com>

view details

push time in 21 hours

push eventapple/swift-distributed-tracing-baggage-core

Konrad `ktoso` Malawski

commit sha 91e4102dcb932267b8e6c62537e1f92086730578

Update scripts/validate_language.sh Co-authored-by: Yim Lee <yim_lee@apple.com>

view details

push time in 21 hours

delete branch apple/swift-distributed-tracing-baggage

delete branch : wip-soundness

delete time in 21 hours

push eventapple/swift-distributed-tracing-baggage

Konrad `ktoso` Malawski

commit sha f97653343165f918e258ab5b413993c85089d29a

use inclusive language (#10) * depend on 0.1.0 baggage core * use inslucive language * Update scripts/validate_language.sh Co-authored-by: Yim Lee <yim_lee@apple.com> Co-authored-by: Yim Lee <yim_lee@apple.com>

view details

push time in 21 hours

PR merged apple/swift-distributed-tracing-baggage

Reviewers
use inclusive language

This removes use of "sanity" and adds the language check.

I don't have enough admin powers on this repo to unset the pull request validation (sanity) from being required (and mark the soundness one instead).

+39 -7

1 comment

6 changed files

ktoso

pr closed time in 21 hours

push eventapple/swift-distributed-tracing-baggage

Konrad `ktoso` Malawski

commit sha 399bfbddbe9c06cd1267372199c7078ddf861c49

Update scripts/validate_language.sh Co-authored-by: Yim Lee <yim_lee@apple.com>

view details

push time in a day

more