> On Nov 28, 2017, at 8:00 AM, Tony Parker wrote:
>
> Why does it imply a run loop rather than one of many multithreading
> possibilities (dispatch queue, starting one more thread, etc)? And even if it
> did use run loops, why is that a problem?
The problem is simply that we're discussing usi
> On Nov 27, 2017, at 11:01 PM, Brent Royal-Gordon
> wrote:
>
> We aren't today
Sorry, this part of the sentence got mangled in editing. What I meant to say
is, script-style programs currently don't run under a runloop, so if this API
is being designed for scripting use, a completion handler
> On Nov 27, 2017, at 3:50 PM, Tony Parker via swift-corelibs-dev
> wrote:
>
> I was thinking of perhaps a completion handler version, with the expectation
> that once async/await style completions land it would be pretty easy to use
> in a kind of straight-line mechanism.
A completion handle
> On Nov 19, 2017, at 7:01 PM, Abhi Beckert wrote:
>
> First of all, I disagree with Brent's assessment that we shouldn't have a
> variant that "simply shells out". Even though this use case is "discouraged"
> in other languages, I think in practice it definitely has a place.
If you really wan
> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev
> wrote:
>
> It does seem like there is a possibility of some better convenience API here.
>
> Any ideas on what form it would take? A class method on Process that returns
> the output, maybe?
`Process.run(_:arguments:terminat
> On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev
> wrote:
>
> I was just wondering if there are plans to bring NSString functions
> manipulating paths into the native String class. (such as lastPathComponent,
> pathComponents etc...)
> Because even if we can always make an ex
> On Feb 23, 2017, at 8:35 AM, Karl Wagner via swift-corelibs-dev
> wrote:
>
> Would it be possible to make a cancelable version of
> DispatchQueue.concurrentPerform, allowing you to abort any
> yet-to-be-scheduled blocks?
>
> The use-case is for when you’re concurrently performing a job and
> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev
> wrote:
>
> Is there any way that we could support asynchronous operations in
> swift-corelibs-foundation, in the absence of KVO?
Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods
just to `Operati
> On Aug 3, 2016, at 8:39 PM, Fernando Rodríguez via swift-corelibs-dev
> wrote:
>
> I'm having some trouble understanding what on Earth SwiftShims are. The name
> probably makes it obvious to native English speakers, but it's not helping
> me...
>
> Could someone please enlighten me?
"Shim
> In the past bare strings were acceptable for postNotificationName and
> addObserverForName. Yet now constructing a Notification and
> Notification.Name seem to be a bit unwieldy. Example:
>
> let ConnectedNotification=
> Notification(name:Notification.Name(rawValue:"ConnectedNotificatio
> #if os(Linux)
> print("Let's change those carriage returns...")
> processedString = string.replacingOccurrences(of: "\r\n", with:
> "\n")
> #else
> processedString = string.replacingOccurrences(of: "\r\n", with:
> "\n")
> #endif
> And
> Sorry, I said NSProgress but I meant NSPredicate. I personally can't even
> imagine what a alternative API for NSPredicate would look like 🤔
Use reflection.
Match against only dictionaries with string keys.
Match against only objects conforming to some dictionary-with-string-keys-like
protoc
> This may be better suited to swift-evolution or users list, but regarding
> fatalError do you have any techniques for testing this behavior?
I believe the Swift compiler’s tests run code it expects to trap in a separate
process and verify that the other process trapped. We may want to think ab
> This may be better for the swift-evolution list, but I really do not like the
> fact that subscripting is a "hard" error. I think the language should have as
> little hard errors as possible to improve on how much the compiler can check
> for you.
I think the idea is that, if you’re subscript
> Been playing around with NSAttributedString and cannot decide on the best way
> to implement the (attributesAtIndex: effectiveRange) and other methods with
> similar functionality.
>
> In the ObjC world I would expect an empty NSDictionary even in cases where
> the location is greater than th
> NSDate (and dates/timestamps in general) is a poor choice for Strideable,
> because, DST.
> A Calendar using this interface for a repeating event would be broken using
> this. Or you would break anyone who really wants to iterate every fixed 86400
> seconds.
Sometimes you want to add an inter
> I think it's a good idea to conform NSDate to the Comparable protocol, so
> instead of using:
>
> if someDate.compare(today) == .OrderedAscending { }
>
> Developers can easily compare using compare dates using comparison operators:
>
> if someDate < today { }
I would also suggest we add Stri
17 matches
Mail list logo
