profile
viewpoint
Jake Petroules jakepetroules @Apple San Francisco Bay Area http://www.jakepetroules.com/ Software Engineer at Apple, working on Xcode and build systems.

bdkjones/CodeKit2 102

CodeKit 2 Beta

jakepetroules/littlebirdy 43

PDF password removal utility

jakepetroules/wherefrom 29

Displays the URL a file was downloaded from by reading OS X extended file attributes.

jakepetroules/Filesystem 8

Simple app for iOS, macOS, tvOS, and watchOS that detects whether the filesystem is APFS or HFS

lunarcloud/qt-enhanced-project-template 3

Qt project template wizard for starting new projects that are deployable and cross-platform. A great way to jumpstart a project.

jakepetroules/Amalgamate 2

C library and GUI application for creating and editing Apple .DS_Store files (work in progress)

jakepetroules/owlmail 2

This is an application for Keene State College (www.keene.edu) students to receive near real-time alerts when they receive emails. As KSC uses the CampusCruiser system, it is not possible to use regular email clients such as Microsoft Outlook and Mozilla Thunderbird, so this provides a solution. KSC Email Tracker allows the user to enter his or her MyKSC username and password in the options dialog. The program will use the credentials to automatically log the user in to the MyKSC email system. Every 60 seconds, the program will check the user’s inbox, and will pop up a small dialog in the lower right hand corner of the screen to notify the user that an email message has arrived. The program can also be set not to display alerts for certain individual messages. This can be useful if a user wants to leave messages in the unread state but not be continually alerted about them. Additionally, the Windows version of the application allows users to set the program to start up with their computer so that it is always on.

jakepetroules/usbcreator 2

Bootable USB creation tool for macOS

msorvig/qt-osx-testbench 2

Testing embedding of raster, OpenGL and Qt Quick windows

jakepetroules/jakes-3d-mmo 1

Foundations of a toy 3D MMORPG that I wrote around 2007 or 2008

push eventapple/swift

Karoy Lorentey

commit sha 3910f5a5a4cf552b6eb76ecd93eaf0207962ebe8

mailmap: Fix parse issue

view details

Karoy Lorentey

commit sha f569be2abcefebf3f339cb8782244f99ec9e1c21

Merge pull request #34484 from apple/malmap-parse mailmap: Fix parse issue

view details

push time in 2 minutes

delete branch apple/swift

delete branch : malmap-parse

delete time in 2 minutes

PR merged apple/swift

mailmap: Fix parse issue

There is a stray angle bracket that confuses some git commands.

+1 -1

4 comments

1 changed file

lorentey

pr closed time in 2 minutes

pull request commentapple/swift

[Sema] Always look through optionals for unresolved member lookup

@swift-ci please test source compatibility

Jumhyn

comment created time in 6 minutes

pull request commentapple/swift

[Sema] Always look through optionals for unresolved member lookup

@swift-ci please test

Jumhyn

comment created time in 6 minutes

pull request commentapple/swift

[Concurrency] Disallow 'async' and non-async overloading.

@swift-ci please smoke test macOS

DougGregor

comment created time in 7 minutes

push eventapple/swift

Varun Gandhi

commit sha 39de3d4692567f56a7e061899218bb3d43a144f7

[SILGen] Fix Clang type for foreign completion handler impl.

view details

swift-ci

commit sha 6a799857f5d1fb6ec5c1e752feec153f6f4cdbb9

Merge pull request #34942 from varungandhi-apple/vg-silgen-fix-clang-type-foreign-completion-handler

view details

swift_jenkins

commit sha 131d299035823b6fff812c28eadeaab6b560a9bf

Merge remote-tracking branch 'origin/main' into next

view details

push time in 8 minutes

pull request commentapple/swift

[SILGen] Make sure enum element is always cleaned up.

@gottesmm can you take another look at this when you have a minute?

zoecarver

comment created time in 14 minutes

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials with Fixed Associated Types++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)++## Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.++## Motivation++Existential types are types synthesized by the compiler that can wrap any value of a type which conforms to a given _protocol_, _class_, or _composition of the above_. They are an incredibly useful feature in Swift for specific use cases that involve dynamicity. Thus, by being able to wrap different types that conform to a specified protocol, users and, more often, library authors can alleviate a lot of boilerplate code. That is, in certain use cases creating a custom existential type can be quite a daunting task due to its complexity; not to mention, that it introduces a lot of difficult-to-understand and hard-to-maintain code.+++### Heterogenous Collections++Such use cases that involve dynamicity can be heterogenous collections. That is, collections that need to take any type conforming to a given set of constraints involve, by their nature, some sort of existential type. For example:++```swift+protocol User { ++  associatedtype ID : Hashable +++  var id: ID { get }++  var username: String { get } ++} +```++So, now we want to make business users and regular users that use different types of `ID`s:++```swift+struct BussinessUser : User {++  struct BusinessID : Hashable { ++    var organisationName: String++    var organisationId: UUID ++  } +++  var id: BusinessID++  var username: String    +  +}++struct RegularUser : User {++  // We’ll just use a regular unique+  // identifier for such users.+  var id: UUID ++  var username: String    +  +}+```++Great! Now let’s create a list of our users:++```+let userList = [User]() ❌+// Error: Protocol ‘User’ can only be used as a generic +// constraint because it has Self or associated type requirements.+```++As you can see, the current limitations on existential types prohibit the creation of our `userList`. As a result, we’ll need to create our own, manually-written existential type for `User`, which is a tedious task that requires some level experience. Moreover, the creation of custom existential types.+++### Existential Type Synthesis for Library Authors++Libraries often need to provide custom existential types for commonly-used protocols, when synthesis is not available. However, that  introduces hard-to-understand and difficult-to-maintain boilerplate code into the codebase. As a result, library authors have to spend valuable time on creating, documenting and maintaining such code, which can be easily synthesized by the compiler. For instance, SwiftUI (a popular UI framework from Apple) relies heavily on the ubiquitous [`View`](https://developer.apple.com/documentation/swiftui/view) protocol. This `View` protocol has a public interface that approximately looks like this:++```swift+public protocol View {++  static func _makeView(view: _GraphValue<Self>, inputs: _ViewInputs) -> _ViewOutputs++  static func _makeViewList(view: _GraphValue<Self>, inputs: _ViewListInputs) -> _ViewListOutputs++  static func _viewListCount(inputs: _ViewListCountInputs) -> Int?+++  associatedtype Body : View++  @ViewBuilder var body: Body { get }++}+```++From the interface of `View`, we can infer that SwiftUI uses some hidden, underscore-prefixed requirements internally for rendering. Thus, the associate type `Body` is likely not necessary for drawing; yet, it prevents the compiler from creating an existential type for `View`, forcing the authors to create their own such type: [`AnyView`](https://developer.apple.com/documentation/swiftui/anyview). Furthermore, another notable example is the [`Hashable`](https://developer.apple.com/documentation/swift/hashable) protocol in the Swift standard library. Consequently, this may lead authors to inconvenient workarounds. One such workaround is splitting their protocols into two distinct ones – so as to separate associated types from hidden requirements; unfortunately, this creates a complicated API, which is likely to confuse users. Otherwise, they can do what was discussed above: create a custom existential type; it creates, though, boilerplate, which is clearly undesirable. +++### Inconsistent Language Semantics ++The compiler offers existential types for all protocols except for ones that reference `Self` in a [non-covariant](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)) position or/and ones that have associated type requirements. However, that is incohesive as `Self` can be thought of as an associated type on its own, because it's can't be known solely from the context of a protocol; thus, giving `Self` and associated types different rules for synthesis of an existential type seems rather unintuitive. Furthermore, current semantics can promt library authors to avoid refining their protocols with other useful protocols in fear of their refined protocol not qualifying for the automatically generated existential type. Consider the following `Animal` protocol:++```swift+protocol Identifiable {++  associatedtype ID : Hashable+++  var id: ID { get }++}+++protocol Animal : Identifiable where ID == String {++  var name: String { get }+  +  var speciesName: String { get }+  +  +  var isPet: Bool { get }++}++extension Animal {++  var id: String {+    name+  }++}+```++In the above case, the `Identifiable` inheritence is very useful. Namely, without any cost to the conforming type, `Animnal` can easily refine [`Identifiable`](https://github.com/apple/swift-evolution/blob/main/proposals/0261-identifiable.md) and gain powerful functionality, as a result. For instance, SwiftUI's [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) view relies on its data source conforming to `Identifiable`, in which case having such a conformance for free on `Animal`-conforming types is very convenient. Lastly, it's also important to note that in the above example the associated type `ID` is fixed to `String`; therefore, the current limitation seems even more unnecessarily restrictive and further exacerbates the confusion surrounding existential types. +++## Proposed Solution++We propose to enable synthesis of existential types for all protocols, in spite of their requirements. Thus, compositions which include protocols that could – before this proposal – not be used as types, will along with these protocols get compiler-generated existential types. Thus code similar to the following will become valid.++```swift+protocol Animal : Identifiable where ID == String {++  ...++}++struct Dog : Animal { ... }++struct Cat : Animal { ... }+++let myPets: [Animal] = [+  Dog(named: "Alex"),+  Cat(named: "Leo")+] ✅++myPets.first!.name ℹ️+// Output: Alex+```+++## Detailed Design++### Availability of Existential Type++Namely, under the new rules, we propose that a compiler-generated existential be offered for:++1. a protocol, no matter its requirements;+2. a protocol-with-protocol composition; and +3. a protocol-with-class composition.

Updated to this:

Namely, under the new rules, we propose that a compiler-generated existential be offered for protocols and protocol compositions no matter their requirements.

filip-sakel

comment created time in 16 minutes

pull request commentapple/swift

[nfc] Remove unused variable "loc".

@swift-ci please smoke test and merge.

zoecarver

comment created time in 17 minutes

PR opened apple/swift

Reviewers
[nfc] Remove unused variable "loc".

Fixes a warning for unused variable in OwnershipModelEliminator.

+0 -1

0 comment

1 changed file

pr created time in 18 minutes

pull request commentapple/swift

[cxx-interop] Add support for templated member functions.

@swift-ci please test Windows.

zoecarver

comment created time in 21 minutes

pull request commentapple/swift

[cxx-interop] Add support for templated member functions.

@swift-ci please test Windows.

zoecarver

comment created time in 22 minutes

pull request commentapple/swift

[cxx-interop] Support class template specializations in namespaces.

@swift-ci please test Windows.

zoecarver

comment created time in 23 minutes

pull request commentapple/swift

[cxx-interop] Support class template specializations in namespaces.

@swift-ci please smoke test OS X.

zoecarver

comment created time in 24 minutes

pull request commentapple/swift

[Property Wrappers] Support property wrappers on function and closure parameters

macOS Toolchain Download Toolchain Git Sha - 101fcbc6e26de355d0486f9807441d934931f2dd

Install command tar -zxf swift-PR-34272-802-osx.tar.gz --directory ~/

hborla

comment created time in 25 minutes

pull request commentapple/swift

[cxx-interop] Support class template specializations in namespaces.

@swift-ci please smoke test.

zoecarver

comment created time in 26 minutes

pull request commentapple/swift

[Sema] Always look through optionals for unresolved member lookup

@xedin Updated per your comment! Would you mind kicking off the tests on this?

Jumhyn

comment created time in 26 minutes

Pull request review commentapple/swift

[cxx-interop] Support class template specializations in namespaces.

 namespace {         }       } +      // If this record is declared inside of a nominal type (i.e. a namespace+      // or another struct), then make sure to add it as a member of that+      // declaration.+      if (auto nominalDecl =+              dyn_cast<NominalTypeDecl>(result->getDeclContext()))+        nominalDecl->addMember(result);

Also (kind of unrelated) I'm going to put up a patch to refactor the namespace logic in addAllMembers.

zoecarver

comment created time in 27 minutes

Pull request review commentapple/swift

[cxx-interop] Support class template specializations in namespaces.

 namespace {         }       } +      // If this record is declared inside of a nominal type (i.e. a namespace+      // or another struct), then make sure to add it as a member of that+      // declaration.+      if (auto nominalDecl =+              dyn_cast<NominalTypeDecl>(result->getDeclContext()))+        nominalDecl->addMember(result);

So, I did some investigation, and you're right. This was the source of the assertion we're hitting. The issue is that this only needs to be here for class template specializations because they're not added in loadAllMembers. So, I removed the addMember here and moved it to a new ClassTemplateVisitor member. Let me know what you think.

zoecarver

comment created time in 28 minutes

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials with Fixed Associated Types++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)++## Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.++## Motivation++Existential types are types synthesized by the compiler that can wrap any value of a type which conforms to a given _protocol_, _class_, or _composition of the above_. They are an incredibly useful feature in Swift for specific use cases that involve dynamicity. Thus, by being able to wrap different types that conform to a specified protocol, users and, more often, library authors can alleviate a lot of boilerplate code. That is, in certain use cases creating a custom existential type can be quite a daunting task due to its complexity; not to mention, that it introduces a lot of difficult-to-understand and hard-to-maintain code.+++### Heterogenous Collections++Such use cases that involve dynamicity can be heterogenous collections. That is, collections that need to take any type conforming to a given set of constraints involve, by their nature, some sort of existential type. For example:

Yeah, but we should probably find a definition, as readers might not know what we mean.

filip-sakel

comment created time in 28 minutes

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials with Fixed Associated Types++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)++## Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.++## Motivation++Existential types are types synthesized by the compiler that can wrap any value of a type which conforms to a given _protocol_, _class_, or _composition of the above_. They are an incredibly useful feature in Swift for specific use cases that involve dynamicity. Thus, by being able to wrap different types that conform to a specified protocol, users and, more often, library authors can alleviate a lot of boilerplate code. That is, in certain use cases creating a custom existential type can be quite a daunting task due to its complexity; not to mention, that it introduces a lot of difficult-to-understand and hard-to-maintain code.+++### Heterogenous Collections++Such use cases that involve dynamicity can be heterogenous collections. That is, collections that need to take any type conforming to a given set of constraints involve, by their nature, some sort of existential type. For example:

Boxing/erasure mechanism?

Yes. But is there a formal definition we could link to so as to aid readers unfamiliar with the terminology?

filip-sakel

comment created time in 32 minutes

PR opened apple/swift

[Experimental][Runtime] Experiments in protocol conformance precaching.

Draft PR, just playing with some ideas for now.

+109 -1

0 comment

1 changed file

pr created time in 33 minutes

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials with Fixed Associated Types++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)++## Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.++## Motivation++Existential types are types synthesized by the compiler that can wrap any value of a type which conforms to a given _protocol_, _class_, or _composition of the above_. They are an incredibly useful feature in Swift for specific use cases that involve dynamicity. Thus, by being able to wrap different types that conform to a specified protocol, users and, more often, library authors can alleviate a lot of boilerplate code. That is, in certain use cases creating a custom existential type can be quite a daunting task due to its complexity; not to mention, that it introduces a lot of difficult-to-understand and hard-to-maintain code.

I think omitting some of the sentence connectors makes for a more streamline reading experience.

Okay, I'll remove them.

Did you mean type erasure?

Yeah, but I think the notion of compiler-generated and user-written existentials is easy to grasp.; not to mention that, at least in my opinion, it draws a simple distinction between the two. However, if you think that it will confuse the reader then I don't mind changing it to "type erasure" instead.

Another con would be additional API/ABI surface and ensuing resilience limitations.

Great point! I'll add it to the proposal.

filip-sakel

comment created time in 34 minutes

PR opened apple/swift

Reviewers
Change tensorflow link to point to `main`

<!-- What's in this pull request? --> S4TF repos are moving to main as default. This change updates a link.

+1 -1

0 comment

1 changed file

pr created time in 36 minutes

push eventapple/swift

Varun Gandhi

commit sha 39de3d4692567f56a7e061899218bb3d43a144f7

[SILGen] Fix Clang type for foreign completion handler impl.

view details

swift-ci

commit sha 6a799857f5d1fb6ec5c1e752feec153f6f4cdbb9

Merge pull request #34942 from varungandhi-apple/vg-silgen-fix-clang-type-foreign-completion-handler

view details

push time in 36 minutes

PR merged apple/swift

[SILGen] Fix Clang type for foreign completion handler impl.

Already approved earlier as second commit in #34914. Splitting out for convenience.

+51 -2

1 comment

1 changed file

varungandhi-apple

pr closed time in 36 minutes

Pull request review commentapple/swift

[Sema] Always look through optionals for unresolved member lookup

 Type SemaTest::getStdlibType(StringRef name) const {   return Type(); } +NominalTypeDecl *SemaTest::getStdlibNomicalTypeDecl(StringRef name) const {+  auto typeName = Context.getIdentifier(name);++  auto *stdlib = Context.getStdlibModule();++  llvm::SmallVector<ValueDecl *, 4> results;+  stdlib->lookupValue(typeName, NLKind::UnqualifiedLookup, results);++  if (results.size() != 1)+    return nullptr;++  if (auto *NTD = dyn_cast<NominalTypeDecl>(results.front()))

This could be simplified down to return dyn_cast...

Jumhyn

comment created time in 42 minutes

push eventapple/swift

Brent Royal-Gordon

commit sha 9936c861c7a2f5bffa03a2365ed5e3993ed0f7d1

Fix Mac Catalyst test dependency failures A CMake refactoring in apple/swift#34859 caused failures in Mac Catalyst configurations which are not tested in open source. This commit corrects these issues. Fixes rdar://71897958.

view details

Brent Royal-Gordon

commit sha ca02ef28fe399dec7684b991e1c8d5d4d07959dc

Merge pull request #34932 from brentdax/rdar-71897958 Fix Mac Catalyst test dependency failures

view details

swift_jenkins

commit sha 6212eabd205efa9f1bd24e87c69c0730ab67940f

Merge remote-tracking branch 'origin/main' into next

view details

push time in 39 minutes

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials with Fixed Associated Types++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)++## Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.

yields the following error:

I think that adding "following" is redundant; that's the function of the colon. If you think, though, that "following" makes this significantly clearer, then go ahead and change it, I don't have any strong opinions about it either.

protocols with requirements meeting certain criteria

That's much clearer, thank you!

Perhaps we should be a tad more specific and mention that – instead of the protocol itself – the error will now affect the ability to invoke protocol members in accordance with the criteria.

You're right, that would be more accurate.

Do you think the following looks better?

Swift currently offers the ability for protocols with requirement meeting certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error: [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint, and instead constraint the availability of protocol members.

filip-sakel

comment created time in 42 minutes

more