Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

> On Sep 20, 2017, at 16:15, Dave DeLong  wrote:
> 
> Hi Jordan,
> 
> One thing I’m still not clear on exhaustive vs non-exhaustive…
> 
> What will stop a developer from releasing an exhaustive enum in version 1 of 
> their library, and then adding a new case in version 2?
> 
> With ABI stability and libraries getting updated independently of apps, this 
> can be a major problem.

We have some ideas to deal with this, though nothing promised yet:

- A checker that can compare APIs across library versions, using swiftmodule 
files or similar.
- Encoding the layout of a type in a symbol name. We could have clients link 
against this symbol so that they’d fail to launch if it changes, or just check 
the list of exported symbols to make sure it didn’t change.

The feature’s useful even if we have to do it by hand for now, but it’s a good 
question to ask. I’ll mention this in the proposal under “Future directions”.

Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Remove ownership keyword support in protocols

[Drew Crawford via swift-evolution]

+1


On September 20, 2017 at 3:11:58 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of “SE-0186: Remove ownership keyword support in protocols” begins 
now and runs through September 27.

The proposal is available here:

   
https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md

Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

   https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

 Proposal link:  
https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md
 ….
 Reply text
 ...
 Other replies

## What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

* What is your evaluation of the proposal?

* Is the problem being addressed significant enough to warrant a change to 
Swift?

* Does this proposal fit well with the feel and direction of Swift?

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?


Thanks,
Ted Kremenek
Review Manager
___
swift-evolution-announce mailing list
swift-evolution-annou...@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] (core library) modern URL types

[Taylor Swift via swift-evolution]

great work! it looks like there is quite a lot of duplicated work going on
here though which is unfortunate. how do we reconcile these 2
implementations?

On Thu, Sep 21, 2017 at 12:16 PM, Aleksey Mashanov <
aleksey.masha...@gmail.com> wrote:

> I have an alternative implementation of a URI (a superset of URL). It is
> quite ready to use but still requires some polishing and adding of
> additional specific URI schemes.
> It is designed primarily for server side usage but can be useful on a
> client too. The main goals of the design is correctness (according to
> RFC3986 and RFC7230) and efficiency.
>
> You can take a look at it here: https://github.com/my-mail-ru/swift-URI
>
> 2017-08-21 7:38 GMT+03:00 Taylor Swift via swift-evolution <
> swift-evolution@swift.org>:
>
>> Okay so a few days ago there was a discussion
>> 
>> about getting pure swift file system support into Foundation or another
>> core library, and in my opinion, doing this requires a total overhaul of
>> the `URL` type (which is currently little more than a wrapper for
>> NSURL), so I’ve just started a pure Swift URL library project at <
>> https://github.com/kelvin13/url>.
>>
>> The library’s parsing and validation core (~1K loc pure swift) is already
>> in place and functional; the goal is to eventually support all of the
>> Foundation URL functionality.
>>
>> The new `URL` type is implemented as a value type with utf8 storage
>> backed by an array buffer. The URLs are just 56 bytes long each, so they
>> should be able to fit into cache lines. (NSURL by comparison is over 128
>> bytes in size; it’s only saved by the fact that the thing is passed as a
>> reference type.)
>>
>> As I said, this is still really early on and not a mature library at all
>> but everyone is invited to observe, provide feedback, or contribute!
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: [stdlib] Error recovery hook, PR #12025

[Joe Groff via swift-evolution]

> On Sep 21, 2017, at 12:14 AM, John Holdsworth via swift-evolution 
>  wrote:
> 
> Hi S/E,
> 
> I’ve raised a rather speculative PR suggesting a hook be added to stdlib
> that would allow users to experiment with error recovery in their apps.
> I’ve been asked to put it forward on Swift Evolution to gather opinions
> from the wider community about such a design.
> 
> https://github.com/apple/swift/pull/12025 
> 
> 
> Ultimately, it comes down to being able to do something like this:
> 
> do {
> try Fortify.exec {
> var a: String!
> a = a!
> }
> }
> catch {
> NSLog("Caught exception: \(error)")
> }
> 
> This was primarily intended for user in "Swift on the server" but could also
> help avoid crashes in the mobile domain. The rationale and mechanics
> are written up at the following url:
> 
> http://johnholdsworth.com/fortify.html 
> 
> 
> I'll accept this won’t be everybody’s cup of tea but at this stage this is
> only an opt-in facilitating patch. Developers need not subject their apps
> to this approach which requires a separate experimental implementation.
> 
> The recovery is reasonably well behaved except it will not recover 
> objects and system resources used in intermediate frames, It’s not
> as random as something like, for example, trying to cancel a thread.
> 
> The debate about whether apps should try to soldier on when something
> is clearly amiss is a stylistic one about which there will be a spectrum of
> opinions. The arguments weigh more in favour in the server domain.

Thanks for raising this topic! Graceful partial recovery is important and 
useful, and although we've tended to invoke "actors" as the vague savior that 
will answer all the questions in this space, I think we can provide useful 
functionality with a smaller scope that won't interfere with future directions. 
At a language level, questions to answer include:

- What can we guarantee about the process state after a trap?
- What does the interface for setting up a trap handler look like?

Instead of thinking of a trap as completely invalidating and ending the program 
like we do today, we can think of it as deadlocking the current execution 
context (setting aside for a moment the question of what "execution context" 
means), as if it got stuck in an infinite loop. As you noted, this means we 
can't reclaim any memory, locks, or other resources currently being held by the 
trapped context, but other contexts can continue executing. In fantasy actor 
land, the definition of "execution context" would ideally be "current actor"; 
in the world today, we have a few choices. We could say that a trap takes down 
the current thread, though that might be a bit too much for single-threaded or 
workqueue-based architectures. Another alternative is to delimit the scope 
affected by a trap with a setjmp/longjmp-like mechanism, sort of like what you 
have, though that then requires care to ensure that state "above" the trap line 
isn't entangled with the invalidated state "below" the trap line.

That leads into the question of what the interface for handling a trap should 
look like. Personally, I don't think trying to turn fatal errors into 
exceptions is the right answer, since that makes it way too easy to do the 
kinds of harmful things people do with Java runtime errors, SEH, etc. to 
swallow and ignore serious problems. I think it'd be better to have an 
interface that's clearly tuned toward supervisory reaction to unexpected 
failure, rather than one for routine handling of expected errors.  It also 
potentially creates safety problems for the ownership model. It's tempting to 
think of the block passed to your `Fortify.exec` as nonescaping, but that's 
problematic with inouts:

var x: Int
do {
try execWhileTurningTrapsIntoErrors {
foo(&x)
}
} catch {
print(x)
}

func foo(x: inout Int) { fatalError() }

The compiler will reason that x is statically exclusively held only during the 
call to `foo`, but that's not really the case—foo trapped and deadlocked in the 
middle of the access, and we essentially left it hanging and went and ran our 
catch handler with the inout access still active.

If we were to say that a trap takes down the current thread, then we could have 
a signal-like interface for installing a handler that's the last thing to run 
on the thread before taking it down, like this:

func ifTrapOccursOnCurrentThread(_ do: @escaping () -> ())

ifTrapOccursOnCurrentThread {
  supervisor.notifyAboutTrap(on: pthread_self())
}
doStuff()

A scoped handler could still be made to work, with an interface something like 
this:

func run(_ body: @escaping () -> (), withTrapHandler: () -> ())

run({
  doStuf

Re: [swift-evolution] (core library) modern URL types

[Aleksey Mashanov via swift-evolution]

I have an alternative implementation of a URI (a superset of URL). It is
quite ready to use but still requires some polishing and adding of
additional specific URI schemes.
It is designed primarily for server side usage but can be useful on a
client too. The main goals of the design is correctness (according to
RFC3986 and RFC7230) and efficiency.

You can take a look at it here: https://github.com/my-mail-ru/swift-URI

2017-08-21 7:38 GMT+03:00 Taylor Swift via swift-evolution <
swift-evolution@swift.org>:

> Okay so a few days ago there was a discussion
> 
> about getting pure swift file system support into Foundation or another
> core library, and in my opinion, doing this requires a total overhaul of
> the `URL` type (which is currently little more than a wrapper for NSURL),
> so I’ve just started a pure Swift URL library project at <
> https://github.com/kelvin13/url>.
>
> The library’s parsing and validation core (~1K loc pure swift) is already
> in place and functional; the goal is to eventually support all of the
> Foundation URL functionality.
>
> The new `URL` type is implemented as a value type with utf8 storage backed
> by an array buffer. The URLs are just 56 bytes long each, so they should be
> able to fit into cache lines. (NSURL by comparison is over 128 bytes in
> size; it’s only saved by the fact that the thing is passed as a reference
> type.)
>
> As I said, this is still really early on and not a mature library at all
> but everyone is invited to observe, provide feedback, or contribute!
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

[Georgios Moschovitis via swift-evolution]

+1

Btw, I kinda like the `Flow` name (or even `Observable`). Don’t like 
`ReactiveStream` at all.

-g.

> On 19 Sep 2017, at 3:59 AM, Howard Lovatt via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> http://www.reactive-streams.org/ 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Resources

[Karl Wagner via swift-evolution]

Hi everybody!

I’m really happy that Swift 4 is out, and it’s great that there’s already so 
much active discussion about Swift 5 (concurrency, etc). I find I’m running in 
to language roadblocks less and less, and the improvements to the generics 
system have really improved a lot of my code. It’s really enjoyable to program 
in Swift, so thanks to everybody who made it possible.

When I think about what’s missing from Swift, I think of modules. We all like 
to write modular code, and aside from the entire discussion about submodules, 
the way that you glue separate modules together in to an application is 
supposed to be via the package manager. For Swift 5, I would personally really 
like it if we could flesh out the package manager a bit more so that it can 
really be the basis of a thriving Swift developer community in production 
environments.

The thing that hits me the most with SwiftPM currently is that it doesn’t 
support resources, and it has very limited support for cross-platform modules 
(the type of thing you’re likely to have as a Model or Model Controller layer). 
Without support for bundled application resources, there’s no way for the 
package manager to support GUI apps or frameworks and unit-tests can’t reliably 
point to bundled test resources.

I have some ideas about ways we could improve the situation, but first I 
thought I’d send this out for some community feedback. Do you think SwiftPM is 
as important as I do for v5? Which improvements would give you the most benefit?

- Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] (core library) modern URL types

[Thorsten Seitz via swift-evolution]

Thanks!

-Thorsten

> Am 21.09.2017 um 10:07 schrieb Jonathan Hull :
> 
> Looks like the author posted a free copy of the paper here:
> http://www.hirschfeld.org/writings/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf
> 
> Thanks,
> Jon
> 
>> On Sep 20, 2017, at 10:03 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> 
>>> Am 24.08.2017 um 23:07 schrieb Eagle Offshore via swift-evolution 
>>> :
>>> 
>>> I liked the polymorphic identifiers paper presented at Dynamic Languages 
>>> Symposium 2013.
>>> 
>>> http://dl.acm.org/citation.cfm?doid=2508168.2508169
>>> 
>>> There's a lot of power in URI's that remains largely untapped in most 
>>> systems.
>>> 
>>> There's not a great reason for this heterogeneity other than historical 
>>> baggage.
>>> 
>>> Properly done, URI's can unify keypaths, user defaults, environment 
>>> variables, files, network stores, databases, etc.
>> 
>> Would you mind summarizing the idea as the paper is not freely available?
>> 
>> -Thorsten
>> 
>> 
 On Aug 22, 2017, at 12:52 PM, Félix Cloutier via swift-evolution 
  wrote:
 
 Just leaving it out here that the iOS/macOS app experience with paths is 
 likely to be very different from the server (or system program) 
 experience. Most of your paths are relative to a container because the 
 effective root of your data is the container. I would tend to believe that 
 a lot of your paths, not while fully static, could be expressed with 
 something like "${DOCUMENTS}/static/part", where ${DOCUMENTS} is the only 
 thing that effectively changes. A system-level program just happens to use 
 / as its prefix.
 
 Most platforms already have some notion of file domains, which are really 
 just path prefixes (the user's home folder, the file system root, the 
 network root, etc). I think that some level of support for these would be 
 desirable (would it be only a set of functions that return different path 
 prefixes). It's also my humble opinion that tilde expansion should be part 
 of a larger shell expansion feature to avoid surprises.
 
 I think that I support the conclusion.
 
 Félix
 
> Le 22 août 2017 à 12:02, Dave DeLong  a écrit :
> 
 
> I suppose, if you squint at it weirdly.
> 
> My current Path API is a “Path” protocol, with “AbsolutePath” and 
> “RelativePath” struct versions. The protocol defines a path to be an 
> array of path components. The only real difference between an 
> AbsolutePath and a RelativePath is that all file system operations would 
> only take an AbsolutePath. A URL would also only provide an AbsolutePath 
> as its “path” bit.
> 
> public enum PathComponent {
> case this // “."
> case up   // “..” 
> case item(name: String, extension: String?)
> }
> 
> public protocol Path {   
> var components: Array { get }
> init(_ components: Array) // used on protocol 
> extensions that mutate paths, such as appending components
> }
> 
> public struct AbsolutePath: Path { }
> public struct RelativePath: Path { }
> 
> By separating out the concept of an Absolute and a Relative path, I can 
> put additional functionality on each one to make semantic sense (you 
> cannot concatenate two absolute paths, but you can concat any path with a 
> relative path, for example). Or all file system operations must take an 
> AbsolutePath. 
> 
> One of the key things I realized is that a “Path” type should not be 
> ExpressibleByStringLiteral, because you cannot statically determine if a 
> Path should be absolute or relative. However, one of the initializers for 
> an AbsolutePath would handle things like expanding a tilde, and both 
> types try to reduce a set of components as much as possible (by filtering 
> out “.this” components, and handling “.up” components where possible, 
> etc). Also in my experience, it’s fairly rare to want to deal with a 
> known-at-compile-time, hard-coded path. Usually you’re dealing with paths 
> relative to known “containers” that are determined at runtime (current 
> user’s home folder, app’s sandboxed documents directory, etc).
> 
> Another thing I’ve done is that no direct file system operations exist on 
> AbsolutePath (like “.exists” or “.createDirectory(…)” or whatever); those 
> are still on FileManager/FileHandle/etc in the form of extensions to 
> handle the new types. In my app, a path is just a path, and it only has 
> meaning based on the thing that is using it. An AbsolutePath for a URL is 
> used differently than an AbsolutePath on a file system, although they are 
> represented with the same “AbsolutePath” type.
> 
> I’m not saying this is a perfect API of course, or even that a 
> hypothetical stdlib-provid

Re: [swift-evolution] (core library) modern URL types

[Jonathan Hull via swift-evolution]

Looks like the author posted a free copy of the paper here:
http://www.hirschfeld.org/writings/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf

Thanks,
Jon

> On Sep 20, 2017, at 10:03 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
> Am 24.08.2017 um 23:07 schrieb Eagle Offshore via swift-evolution 
> mailto:swift-evolution@swift.org>>:
> 
>> I liked the polymorphic identifiers paper presented at Dynamic Languages 
>> Symposium 2013.
>> 
>> http://dl.acm.org/citation.cfm?doid=2508168.2508169 
>> 
>> There's a lot of power in URI's that remains largely untapped in most 
>> systems.
>> 
>> There's not a great reason for this heterogeneity other than historical 
>> baggage.
>> 
>> Properly done, URI's can unify keypaths, user defaults, environment 
>> variables, files, network stores, databases, etc.
> 
> Would you mind summarizing the idea as the paper is not freely available?
> 
> -Thorsten
> 
> 
>>> On Aug 22, 2017, at 12:52 PM, Félix Cloutier via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Just leaving it out here that the iOS/macOS app experience with paths is 
>>> likely to be very different from the server (or system program) experience. 
>>> Most of your paths are relative to a container because the effective root 
>>> of your data is the container. I would tend to believe that a lot of your 
>>> paths, not while fully static, could be expressed with something like 
>>> "${DOCUMENTS}/static/part", where ${DOCUMENTS} is the only thing that 
>>> effectively changes. A system-level program just happens to use / as its 
>>> prefix.
>>> 
>>> Most platforms already have some notion of file domains, which are really 
>>> just path prefixes (the user's home folder, the file system root, the 
>>> network root, etc). I think that some level of support for these would be 
>>> desirable (would it be only a set of functions that return different path 
>>> prefixes). It's also my humble opinion that tilde expansion should be part 
>>> of a larger shell expansion feature to avoid surprises.
>>> 
>>> I think that I support the conclusion.
>>> 
>>> Félix
>>> 
>>> Le 22 août 2017 à 12:02, Dave DeLong >> > a écrit :
>>> 
 I suppose, if you squint at it weirdly.
 
 My current Path API is a “Path” protocol, with “AbsolutePath” and 
 “RelativePath” struct versions. The protocol defines a path to be an array 
 of path components. The only real difference between an AbsolutePath and a 
 RelativePath is that all file system operations would only take an 
 AbsolutePath. A URL would also only provide an AbsolutePath as its “path” 
 bit.
 
 public enum PathComponent {
 case this // “."
 case up   // “..” 
 case item(name: String, extension: String?)
 }
 
 public protocol Path {   
 var components: Array { get }
 init(_ components: Array) // used on protocol 
 extensions that mutate paths, such as appending components
 }
 
 public struct AbsolutePath: Path { }
 public struct RelativePath: Path { }
 
 By separating out the concept of an Absolute and a Relative path, I can 
 put additional functionality on each one to make semantic sense (you 
 cannot concatenate two absolute paths, but you can concat any path with a 
 relative path, for example). Or all file system operations must take an 
 AbsolutePath. 
 
 One of the key things I realized is that a “Path” type should not be 
 ExpressibleByStringLiteral, because you cannot statically determine if a 
 Path should be absolute or relative. However, one of the initializers for 
 an AbsolutePath would handle things like expanding a tilde, and both types 
 try to reduce a set of components as much as possible (by filtering out 
 “.this” components, and handling “.up” components where possible, etc). 
 Also in my experience, it’s fairly rare to want to deal with a 
 known-at-compile-time, hard-coded path. Usually you’re dealing with paths 
 relative to known “containers” that are determined at runtime (current 
 user’s home folder, app’s sandboxed documents directory, etc).
 
 Another thing I’ve done is that no direct file system operations exist on 
 AbsolutePath (like “.exists” or “.createDirectory(…)” or whatever); those 
 are still on FileManager/FileHandle/etc in the form of extensions to 
 handle the new types. In my app, a path is just a path, and it only has 
 meaning based on the thing that is using it. An AbsolutePath for a URL is 
 used differently than an AbsolutePath on a file system, although they are 
 represented with the same “AbsolutePath” type.
 
 I’m not saying this is a perfect API of course, or even that a 
 hypothetical stdlib-provided Path should mimic this. I’m just saying tha

[swift-evolution] Pitch: [stdlib] Error recovery hook, PR #12025

[John Holdsworth via swift-evolution]

Hi S/E,

I’ve raised a rather speculative PR suggesting a hook be added to stdlib
that would allow users to experiment with error recovery in their apps.
I’ve been asked to put it forward on Swift Evolution to gather opinions
from the wider community about such a design.

https://github.com/apple/swift/pull/12025 


Ultimately, it comes down to being able to do something like this:

do {
try Fortify.exec {
var a: String!
a = a!
}
}
catch {
NSLog("Caught exception: \(error)")
}

This was primarily intended for user in "Swift on the server" but could also
help avoid crashes in the mobile domain. The rationale and mechanics
are written up at the following url:

http://johnholdsworth.com/fortify.html 

I'll accept this won’t be everybody’s cup of tea but at this stage this is
only an opt-in facilitating patch. Developers need not subject their apps
to this approach which requires a separate experimental implementation.

The recovery is reasonably well behaved except it will not recover 
objects and system resources used in intermediate frames, It’s not
as random as something like, for example, trying to cancel a thread.

The debate about whether apps should try to soldier on when something
is clearly amiss is a stylistic one about which there will be a spectrum of
opinions. The arguments weigh more in favour in the server domain.

Over to you,

John

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution