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

IMHO, The fact that URL has distinct interfaces for ‘scheme', ‘user', ‘host', ‘port', ‘query', and ‘fragment’ (all of which are either irrelevant or invalid for addressing local files) should be an indication that it’s maybe not the best primary interface for directly modeling filesystem

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 22, 2017, at 9:32 AM, Joe Groff via swift-evolution > wrote: > >>> async as a subtype of throws instead of orthogonal to it >>> >>> I’ve been thinking a lot about this since the proposal came out and I see a >>> few serious disadvantages at making async a

Re: [swift-evolution] Is there a simple way to go from Codable to Any and vice versa?

> On Aug 22, 2017, at 12:32 PM, Youming Lin via swift-evolution > wrote: > > Hi all > > With Swift 4 Codable support, we can now do the following conversions: > Codable <-> Data using JSONEncoder/JSONDecoder > Any <-> Data using JSONSerialization > > Not sure if I

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

Yep, I agree. My early thoughts on this included ideas around a “Container” for a path, but I ended up at the point that it wasn’t a useful abstraction (that I could see), because a container was really just a different AbsolutePath “prefix”. I toyed around with the idea of something like:

Re: [swift-evolution] [Pitch] Adding accessibility specifiers to @available

Whew! Thanks for the heads-up before my prototype hits merge-conflict madness. :) On Tue, Aug 22, 2017 at 1:16 PM Ben Rimmington wrote: > > On 22 Aug 2017, at 17:08, Tony Allevato wrote: > > > > A few months ago (before Swift 5 chatter started), I pitched an idea to >

Re: [swift-evolution] [Pitch] Adding accessibility specifiers to @available

> On 22 Aug 2017, at 17:08, Tony Allevato wrote: > > A few months ago (before Swift 5 chatter started), I pitched an idea to > improve the use of @availability in third-party code by eliminating > deprecation warnings in same-file references. We had some good discussion > there about who

Re: [swift-evolution] SE-184 Improved Pointers

This is an excellent, thoroughly thought out, and well written proposal! I’m eager to see these improvements land. > On Aug 22, 2017, at 11:33 AM, Taylor Swift wrote: > > > > On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick >

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

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

[swift-evolution] Is there a simple way to go from Codable to Any and vice versa?

Hi all With Swift 4 Codable support, we can now do the following conversions: 1. Codable <-> Data using JSONEncoder/JSONDecoder 2. Any <-> Data using JSONSerialization Not sure if I missed something obvious, but is there a simple way to do Codable <-> Any conversions? I can do Codable

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

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

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

Since an absolute URI is still relative to root, I feel like there should be a way to finagle relative and absolute URIs into a single type. > On Aug 22, 2017, at 2:37 PM, Taylor Swift via swift-evolution > wrote: > > So are you saying we need three distinct “URI”

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

So are you saying we need *three* distinct “URI” types for local-absolute, local-relative, and remote? That’s a lot of API surface to support. On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong wrote: > I completely agree. URL packs a lot of punch, but IMO it’s the wrong >

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick wrote: > > On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of >> `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for

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

There’s also a library somewhat similar to PathKit called FileKit (https://github.com/nvzqz/FileKit ). FileKit has some functionality I’m not sure how I feel about, such as different types based on the type of data in the file. It also uses a lot of Foundation

Re: [swift-evolution] [Concurrency] Async/Await

Just to get it out of the way and to put the issue down... assuming we could get something like Promises and Futures, how much experience do people have with how async and await + Promises are changing the asynchronous by nature JavaScript? What in there really does not work and should one of

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 21, 2017, at 10:21 PM, David Hart wrote: > > Sorry for the shameless bump :-/ but I’d love to get some answers so I can > better understand the proposal and participate in the discussions. > >> On 21 Aug 2017, at 07:58, David Hart via swift-evolution >>

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

I completely agree. URL packs a lot of punch, but IMO it’s the wrong abstraction for file system paths. I maintain an app that deals a lot with file system paths, and using URL has always felt cumbersome, but String is the absolute wrong type to use. Lately as I’ve been working on it, I’ve

Re: [swift-evolution] [Concurrency] async/await + actors

On Mon, Aug 21, 2017 at 4:09 PM, Karim Nassar via swift-evolution < swift-evolution@swift.org> wrote: > Thought about it in more depth, and I’m now firmly in the camp of: > ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think > the slight call-site reduction in typed

[swift-evolution] [Pitch] Adding accessibility specifiers to @available

Hi all, A few months ago (before Swift 5 chatter started), I pitched an idea to improve the use of @availability in third-party code by eliminating deprecation warnings in same-file references . We had some good

Re: [swift-evolution] [Concurrency] async/await + actors

Alternatively, until futures are a thing, you can call `beginAsync` twice to start to async tasks: func process() -> Void { beginAsync { let dataResource = await loadWebResource("bigData.txt") // } print("BigData Scheduled to

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 21, 2017, at 10:47 PM, Jonathan Hull via swift-evolution > wrote: > > I am finding that I DO NOT understand beginAsync. At first I thought it was > the async/await version of 'do{}’, but as others are giving examples which > use it in different ways, I

Re: [swift-evolution] [Concurrency] async/await + actors

>> On Aug 21, 2017, at 1:56 PM, John McCall wrote: >> >> Personally, I think these sources of confusion are a good reason to keep the >> feature separate. >> >> The idea of using await! to block a thread is interesting but, as you say, >> does not fit with the general

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of > `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the typical > use case and doesn't appear to solve any important use

[swift-evolution] [Concurrency] do async

I have seen a lot of examples which use both do and beginAsync: beginAsync { do { try await foo() } catch let e { //Handle Error } } I twitch every time I see this, because I thought

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:00 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > >> >> On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: >> >> New draft of the proposal is

Re: [swift-evolution] SE-184 Improved Pointers

On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > > On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md> > >