Re: [swift-corelibs-dev] Proposal: add `noescape` attribute to public API (particularly libdispatch)

[Jacob Bandes-Storch via swift-corelibs-dev]

Alright, I've written up a proposal:
https://github.com/apple/swift-evolution/pull/40

Feedback welcome!

Jacob

On Sat, Dec 5, 2015 at 2:25 PM, Jacob Bandes-Storch 
wrote:

> On Sat, Dec 5, 2015 at 1:40 PM, Tony Parker 
> wrote:
>
>> One topic I wanted to discuss was finding a comprehensive list of API
>> that needs the attribute.
>>
>
> On this subject, here are some other APIs which could use the annotation.
> Again, I think these should be annotated even in the C/Objective-C headers,
> so they can benefit C/Objective-C callers as well.
>
> - bsearch, heapsort, qsort, mergesort, psort, and their _b variants
>
> "passing test" methods:
> - -[{NSArray,NSOrderedSet} indexOfObjectPassingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsPassingTest:]
> - -[{NSArray,NSOrderedSet} indexOfObjectsAtIndexes:passingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsAtIndexes:passingTest:]
> - -[SCNNode childNodesPassingTest:]
> - -[SCNSceneSource entriesPassingTest:]
> - -[AVAudioUnitComponentManager componentsPassingTest:]
> - -[NSIndexSet indexPassingTest:]
> - -[NSIndexSet indexWithOptions:passingTest:]
> - -[NSIndexSet indexesPassingTest:]
> - -[NSIndexSet indexesWithOptions:passingTest:]
> - -[NSIndexSet indexInRange:options:passingTest:]
> - -[NSIndexSet indexesInRange:options:passingTest:]
> - -[NSSet objectsPassingTest:]
> - -[NSSet objectsWithOptions:passingTest:]
> - -[NSDictionary keysOfEntriesPassingTest:]
> - -[NSDictionary keysOfEntriesWithOptions:passingTest:]
>
> "using comparator" methods:
> - -[NSArray indexOfObject:inSortedRange:options:usingComparator:]
> - -[NSArray sortedArrayUsingComparator:]
> - -[NSArray sortedArrayWithOptions:usingComparator:]
> - -[NSDictionary keysSortedByValueUsingComparator:]
> - -[NSDictionary keysSortedByValueWithOptions:usingComparator:]
> - -[NSMutableArray sortUsingComparator:]
> - -[NSMutableArray sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortRange:options:usingComparator:]
>
>  (and some of these have "usingFunction" variants)
>
> "enumerate using block" methods:
> - -[NSTableView enumerateAvailableRowViewsUsingBlock:]
> - -[SKPhysicsWorld enumerateBodiesAtPoint:usingBlock:]
> - -[SKPhysicsWorld enumerateBodiesInRect:usingBlock:]
> - -[NSData enumerateByteRangesUsingBlock:]
> - -[SCNNode enumerateChildNodesUsingBlock:]
> - -[SCNNode enumerateChildNodesWithName:usingBlock:]
> - -[NSIndexSet enumerateIndexesUsingBlock:]
> - -[NSIndexSet enumerateIndexesWithOptions:usingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsUsingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsWithOptions:usingBlock:]
> - -[NSString enumerateLinesUsingBlock:]
> - -[NSString enumerateSubstringsInRange:options:usingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsUsingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesUsingBlock:]
> - -[NSIndexSet enumerateRangesWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesInRange:options:usingBlock:]
> - -[MPMediaEntity enumerateValuesForProperties:usingBlock:]
> - -[NSMetadataQuery enumerateResultsUsingBlock:]
> - -[NSMetadataQuery enumerateResultsWithOptions:usingBlock:]
>
> misc:
> - -[NSDocument performSynchronousFileAccessUsingBlock:]
>
> Wow, that's more than I expected to find! This is obviously beyond the
> scope of just libdispatch, and I think a lot of these should probably
> change upstream, in their original frameworks, internally (not something
> that community members can really contribute to).
>
> Arguably, the "enumerateXUsingBlock:" pattern should be bridged to Swift
> as something SequenceType-ish which can be `for-in`ed.
>
> Jacob Bandes-Storch
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Joakim Hassila via swift-corelibs-dev]

Hi Daniel,


> On 7 dec. 2015, at 23:11, Daniel A. Steffen  wrote:
>
> FWIW I’ve updated the macosforge svn repo trunk to match with github 
> swift-corelibs-libdispatch trunk (sans the PRs, excecpt for my buildsystem 
> one), but going forward we are likely going to retire the macosforge 
> repository in favor of the github one.

That seems very reasonable and would make sense I think, there doesn’t seem to 
be much rationale for overlap.

>
>>
>> I have a few questions on how (particularly Apple folks) view this going 
>> forward:
>>
>> First, the previous port to Linux/Solaris of libdispatch was dependent on 
>> libkqueue and more importantly on libpthread_workqueue (to have some 
>> heuristics for managing the number of threads when lacking kernel support).
>>
>> How do you view this, would you consider integrating support for 
>> libpthread_workqueue, or would you have another preference for how to manage 
>> this on other platforms (Linux for starters, but essentially any lacking the 
>> pthread_workqueue interface)?
>
> yes, staying with libpthread_workqueue is the focus of the current Linux 
> porting effort, but it may make sense to move to something more native over 
> time, e.g. like on FreeBSD where a version of the kernel workqueue was 
> implemented natively.

Ok, that’s great - previously there was a discussion to actually integrate 
libpthread_workqueue at least directly into the libdispatch project to reduce 
the number of dependencies to get a reasonably working libdispatch running - 
currently Mark Heily put it up on GitHub as well at 
https://github.com/mheily/libpwq - it has been quite dormant for the last few 
years, but I think that is largely due to things working reasonably well.

So would such more close integration be desirable to make things build more out 
of the box, or would you prefer to only use it if found during build time on 
the current host? (I would probably prefer the first option, as it essentially 
just provides support for functionality that the underlying platform lacks - 
the current libpwq supports a few platforms…).

> Secondly, we have extended the public libdispatch API internally with one 
> more flavor of dispatching, let’s call it ‘dispatch_async_inline’ - the 
> semantics being ‘perform the processing of the work synchronously if we 
> wouldn’t block the calling thread, if we would block, instead perform the 
> work as a normal dispatch_async’.
>>
>> Would such a change be considered to be integrated, or should we keep our 
>> internal diffs indefinitely? Just to understand if it is worth the effort 
>> with a nicely packaged pull request or not...
>>
>> The rationale for the API is that we are quite latency sensitive and want to 
>> use inline processing up until the point where we can’t keep up with the 
>> available work, at which point we would switch to asynchronous processing 
>> seamlessly (we have multiple producers). This means that the thread calling 
>> this API can be stolen for a significant amount of time (emptying the queue 
>> it was assigned to), but when the system is under ‘light' load, we don’t 
>> need to incur the wakeup penalty for a completely asynchronous dispatch.
>
> sounds familiar, have we talked to about this in the past somewhere ?

Well, it could well be that we touched upon it on the old libdispatch mailing 
list a few years ago (I did change my surname from Johansson -> Hassila as well 
as the company mail address, so it might have thrown things off for you :-). I 
did primarily spend some time in helping clean things up for usage on Solaris 
at that time though.

>
> we actually have something quite similar internal to the library already: 
> _dispatch_barrier_trysync_f
>
>   
> https://github.com/apple/swift-corelibs-libdispatch/blob/master/src/queue.c#L3089
>
> but it currently (intentionally) ignores anything about the target queue 
> hierarchy of the queue passed in (e.g. it will allow the sync even if the 
> target queue is busy or suspended), so is not suitable as a general facility.
>
> There are various technical reasons why we don’t believe this primitive in 
> all generality is a good idea, Pierre is writing up an email about that so I 
> won’t go into details here.

Thanks! I will reply to that separately.

Cheers,

Joakim




This e-mail is confidential and may contain legally privileged information. It 
is intended only for the addressees. If you have received this e-mail in error, 
kindly notify us immediately by telephone or e-mail and delete the message from 
your system.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSAttributedString attributesAtIndex return an optional.

[Brent Royal-Gordon via swift-corelibs-dev]

> 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 the length of the string.

Personally, if I indexed past the end of an attributed string, I would expect a 
precondition to fail and (since Swift can't catch assertion failures) my app to 
crash. (And from what I can tell, the Apple Foundation versions of these APIs 
do not return an optional.)

(Sorry about the duplicate, James—didn’t hit Reply All when I should have.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Joakim Hassila via swift-corelibs-dev]

Hi Pierre,

Thanks for the good explanation, will try to respond inline below:

On 7 dec. 2015, at 23:10, Pierre Habouzit 
mailto:phabou...@apple.com>> wrote:

Hi Joakim, Kevin,

[ Full disclosure, I made that reply in rdar://problem/16436943 and your use 
case was slightly different IIRC but you’re right it’s a close enough problem ]

Dispatch internally has a notion of something that does almost that, called 
_dispatch_barrier_trysync_f[1]. However, it is used internally to serialize 
state changes on sources and queues such as setting the target queue or event 
handlers.

The problem is that this call bypasses the target queue hierarchy in its 
fastpath, which while it’s correct when changing the state of a given source or 
queue, is generally the wrong thing to do. Let’s consider this code assuming 
the dispatch_barrier_trysync()


dispatch_queue_t outer = dispatch_queue_create("outer", NULL);
dispatch_queue_t inner = dispatch_queue_create("inner", NULL);
dispatch_set_target_queue(outer, inner);

dispatch_async(inner, ^{
// write global state protected by inner
});
dispatch_barrier_trysync(outer, ^{
// write global state protected by inner
});


Then if it works like the internal version we have today, the code above has a 
data race, which we’ll all agree is bad.
Or we do an API version that when the queue you do the trysync on is not 
targetted at a global root queue always go through async, and that is weird, 
because the performance characteristics would completely depend on the target 
queue hierarchy, which when layering and frameworks start to be at play, is a 
bad characteristic for a good API.

Yes, we could currently assume that we only targeted a root queue for our use 
case, so our implementation has this limitation (so it is not a valid general 
solution as you say).

It would perhaps be a bit strange to have different performance characteristics 
depending on the target queue hierarchy as you say, but there are already some 
performance differences in actual behavior if using e.g. an overcommit queue vs 
a non, so perhaps another option would be to have this as an optional queue 
attribute instead of an additional generic API (queue attribute ’steal calling 
thread for inline processing of requests if the queue was empty when 
dispatching’) …?


Or we don’t give up right away when the hierarchy is deep, but then that means 
that dispatch_trysync would need to be able to unwind all the locks it took, 
and then you have ordering issues because enqueuing that block that couldn’t 
run synchronously may end up being after another one and break the FIFO 
ordering of queues. Respecting this which is a desired property of our API and 
getting an efficient implementation are somehow at odds.

Yes, agree it is a desirable property of the API to retain the ordering.

The other argument against trysync that way, is that during testing trysync 
would almost always go through the non contended codepath, and lead developers 
to not realize that they should have taken copies of variables and the like 
(this is less of a problem on Darwin with obj-c and ARC), but trysync running 
on the same thread will hide that. except that once it starts being contended 
in production, it’ll bite you hard with memory corruption everywhere.

Less of an issue for us as we depend on the _f interfaces throughout due to 
portability concerns, but fair point.

Technically what you’re after is that bringing up a new thread is very costly 
and that you’d rather use the one that’s asyncing the request because it will 
soon give up control. The wake up of a queue isn’t that expensive, in the sense 
that the overhead of dispatch_sync() in terms of memory barriers and locking is 
more or less comparable. What’s expensive is creating a thread to satisfy this 
enqueue.

Yes, in fact, bringing up a new thread is so costly that we keep a pool around 
in the libpwq implementation. Unfortunately we would often see double-digit 
microsecond latency incurred by this, which is unacceptable for us, so we had 
to (for some configurations/special deployments) have a dedicated spin thread 
that will grab the next queue to work on (that cut down the latency with a 
factor of 10 or so) and the next thread woken from the thread pool would take 
over a spinner…

In my opinion, to get the win you’re after, you’d rather want an async() 
version that if it wakes up the target queue hierarchy up to the root then you  
want to have more resistance in bringing up a new thread to satisfy that 
request. Fortunately, the overcommit property of queues could be used by a 
thread pool to decide to apply that resistance. There are various parts of the 
thread pool handling (especially without kernel work queues support) that could 
get some love to get these exact benefits without changing the API.

That would indeed be a very interesting idea, the problem is that the thread 
using ‘dispatch_barrier_trysync’ is not r

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Pierre Habouzit via swift-corelibs-dev]

> On Dec 8, 2015, at 6:11 AM, Joakim Hassila via swift-corelibs-dev 
>  wrote:
> 
> Hi Daniel,
> 
> 
>> On 7 dec. 2015, at 23:11, Daniel A. Steffen  wrote:
>> 
>> FWIW I’ve updated the macosforge svn repo trunk to match with github 
>> swift-corelibs-libdispatch trunk (sans the PRs, excecpt for my buildsystem 
>> one), but going forward we are likely going to retire the macosforge 
>> repository in favor of the github one.
> 
> That seems very reasonable and would make sense I think, there doesn’t seem 
> to be much rationale for overlap.
> 
>> 
>>> 
>>> I have a few questions on how (particularly Apple folks) view this going 
>>> forward:
>>> 
>>> First, the previous port to Linux/Solaris of libdispatch was dependent on 
>>> libkqueue and more importantly on libpthread_workqueue (to have some 
>>> heuristics for managing the number of threads when lacking kernel support).
>>> 
>>> How do you view this, would you consider integrating support for 
>>> libpthread_workqueue, or would you have another preference for how to 
>>> manage this on other platforms (Linux for starters, but essentially any 
>>> lacking the pthread_workqueue interface)?
>> 
>> yes, staying with libpthread_workqueue is the focus of the current Linux 
>> porting effort, but it may make sense to move to something more native over 
>> time, e.g. like on FreeBSD where a version of the kernel workqueue was 
>> implemented natively.
> 
> Ok, that’s great - previously there was a discussion to actually integrate 
> libpthread_workqueue at least directly into the libdispatch project to reduce 
> the number of dependencies to get a reasonably working libdispatch running - 
> currently Mark Heily put it up on GitHub as well at 
> https://github.com/mheily/libpwq - it has been quite dormant for the last few 
> years, but I think that is largely due to things working reasonably well.
> 
> So would such more close integration be desirable to make things build more 
> out of the box, or would you prefer to only use it if found during build time 
> on the current host? (I would probably prefer the first option, as it 
> essentially just provides support for functionality that the underlying 
> platform lacks - the current libpwq supports a few platforms…).

Hi,

FWIW, this is my personal, let’s call it enlightened, opinion, based on my 
knowledge of dispatch and my past extensive system programming experience with 
Linux before I joined Apple.

I think that long term, the best way to maintain a Linux libdispatch port is to 
go away from the libkqueue that tries to emulate kqueue fully, where dispatch 
only needs a small subset of the surface of kqueue. Given how source.c is 
written today, this is not a very small undertaking, but eventually dispatch 
source map to epoll_ctl(EPOLLONESHOT) very very well.

Given our experience with the work queue subsystem in Darwin, I think that it 
would make sense to integrate both projects together, as work queue are not 
that useful if you don’t have dispatch with it, and having it separate gives 
you all the woes of a stable interface, which you don’t really care for in the 
first place. It’s probably much better to integrate it and not care about 
backward and forward compatibility and make it a private library of dispatch on 
linux. And to not be tied to a given interface at all.

I also think that having a minimal kernel support for thread pool management 
isn’t that hard to write as a kernel module, I had started to work on this a 
very long time ago, using the KVM scheduling hooks that let you know when a 
thread blocks and/or becomes runnable[1]. Threads would declare to that 
interface that they are work queue threads, and get load information that the 
thread pool can use to regulate. It’s old code, maybe (probably?) not the right 
way to do it, but that’s an example of things you can do if you move away from 
the contrived interface from what libpthread_workqueue exposes. My idea 
required a linux adjustment that I posted to the LKML at the time 
(http://lkml.iu.edu/hypermail/linux/kernel/1112.2/00235.html) not sure if it 
ever made it to mainline (looks like it didn’t).


[1] 
http://git.madism.org/?p=~madcoder/pwqr.git;a=blob;f=kernel/pwqr.c;h=6d822ea6bca40a2ba8de3965526f33b4a98b8649;hb=HEAD


-Pierre
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Pierre Habouzit via swift-corelibs-dev]

-Pierre

> On Dec 8, 2015, at 7:34 AM, Joakim Hassila via swift-corelibs-dev 
>  wrote:
> 
> Hi Pierre,
> 
> Thanks for the good explanation, will try to respond inline below:
> 
>> On 7 dec. 2015, at 23:10, Pierre Habouzit > > wrote:
>> 
>> Hi Joakim, Kevin,
>> 
>> [ Full disclosure, I made that reply in rdar://problem/16436943 
>>  and your use case was slightly different IIRC but 
>> you’re right it’s a close enough problem ]
>> 
>> Dispatch internally has a notion of something that does almost that, called 
>> _dispatch_barrier_trysync_f[1]. However, it is used internally to serialize 
>> state changes on sources and queues such as setting the target queue or 
>> event handlers.
>> 
>> The problem is that this call bypasses the target queue hierarchy in its 
>> fastpath, which while it’s correct when changing the state of a given source 
>> or queue, is generally the wrong thing to do. Let’s consider this code 
>> assuming the dispatch_barrier_trysync()
>> 
>> 
>> dispatch_queue_t outer = dispatch_queue_create("outer", NULL);
>> dispatch_queue_t inner = dispatch_queue_create("inner", NULL);
>> dispatch_set_target_queue(outer, inner);
>> 
>> dispatch_async(inner, ^{
>> // write global state protected by inner
>> });
>> dispatch_barrier_trysync(outer, ^{
>> // write global state protected by inner
>> });
>> 
>> 
>> Then if it works like the internal version we have today, the code above has 
>> a data race, which we’ll all agree is bad.
>> Or we do an API version that when the queue you do the trysync on is not 
>> targetted at a global root queue always go through async, and that is weird, 
>> because the performance characteristics would completely depend on the 
>> target queue hierarchy, which when layering and frameworks start to be at 
>> play, is a bad characteristic for a good API.
> 
> Yes, we could currently assume that we only targeted a root queue for our use 
> case, so our implementation has this limitation (so it is not a valid general 
> solution as you say). 
> 
> It would perhaps be a bit strange to have different performance 
> characteristics depending on the target queue hierarchy as you say, but there 
> are already some performance differences in actual behavior if using e.g. an 
> overcommit queue vs a non, so perhaps another option would be to have this as 
> an optional queue attribute instead of an additional generic API (queue 
> attribute ’steal calling thread for inline processing of requests if the 
> queue was empty when dispatching’) …?

My point is, adding API to dispatch is not something we do lightly. I’m not 
keen on an interface that only works for base queues. Mac OS and iOS code where 
dispatchy code is pervasive, more than 2 queue deep queues hierarchy is very 
common typically.

>> Or we don’t give up right away when the hierarchy is deep, but then that 
>> means that dispatch_trysync would need to be able to unwind all the locks it 
>> took, and then you have ordering issues because enqueuing that block that 
>> couldn’t run synchronously may end up being after another one and break the 
>> FIFO ordering of queues. Respecting this which is a desired property of our 
>> API and getting an efficient implementation are somehow at odds.
> 
> Yes, agree it is a desirable property of the API to retain the ordering.
> 
>> The other argument against trysync that way, is that during testing trysync 
>> would almost always go through the non contended codepath, and lead 
>> developers to not realize that they should have taken copies of variables 
>> and the like (this is less of a problem on Darwin with obj-c and ARC), but 
>> trysync running on the same thread will hide that. except that once it 
>> starts being contended in production, it’ll bite you hard with memory 
>> corruption everywhere.
> 
> Less of an issue for us as we depend on the _f interfaces throughout due to 
> portability concerns, but fair point.
> 
>> Technically what you’re after is that bringing up a new thread is very 
>> costly and that you’d rather use the one that’s asyncing the request because 
>> it will soon give up control. The wake up of a queue isn’t that expensive, 
>> in the sense that the overhead of dispatch_sync() in terms of memory 
>> barriers and locking is more or less comparable. What’s expensive is 
>> creating a thread to satisfy this enqueue.
> 
> Yes, in fact, bringing up a new thread is so costly that we keep a pool 
> around in the libpwq implementation. Unfortunately we would often see 
> double-digit microsecond latency incurred by this, which is unacceptable for 
> us, so we had to (for some configurations/special deployments) have a 
> dedicated spin thread that will grab the next queue to work on (that cut down 
> the latency with a factor of 10 or so) and the next thread woken from the 
> thread pool would take over a spinner…
> 
>> In my opinion, to get the win you’re after, you’d rather want an

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

[Pierre Habouzit via swift-corelibs-dev]

> On Dec 8, 2015, at 9:05 AM, Daniel A. Steffen via swift-corelibs-dev 
>  wrote:
> 
>> 
>> On Dec 8, 2015, at 6:11, Joakim Hassila  wrote:
>> 
>> Hi Daniel,
>> 
>> 
>>> On 7 dec. 2015, at 23:11, Daniel A. Steffen  wrote:
>>> 
>>> FWIW I’ve updated the macosforge svn repo trunk to match with github 
>>> swift-corelibs-libdispatch trunk (sans the PRs, excecpt for my buildsystem 
>>> one), but going forward we are likely going to retire the macosforge 
>>> repository in favor of the github one.
>> 
>> That seems very reasonable and would make sense I think, there doesn’t seem 
>> to be much rationale for overlap.
>> 
>>> 
 
 I have a few questions on how (particularly Apple folks) view this going 
 forward:
 
 First, the previous port to Linux/Solaris of libdispatch was dependent on 
 libkqueue and more importantly on libpthread_workqueue (to have some 
 heuristics for managing the number of threads when lacking kernel support).
 
 How do you view this, would you consider integrating support for 
 libpthread_workqueue, or would you have another preference for how to 
 manage this on other platforms (Linux for starters, but essentially any 
 lacking the pthread_workqueue interface)?
>>> 
>>> yes, staying with libpthread_workqueue is the focus of the current Linux 
>>> porting effort, but it may make sense to move to something more native over 
>>> time, e.g. like on FreeBSD where a version of the kernel workqueue was 
>>> implemented natively.
>> 
>> Ok, that’s great - previously there was a discussion to actually integrate 
>> libpthread_workqueue at least directly into the libdispatch project to 
>> reduce the number of dependencies to get a reasonably working libdispatch 
>> running - currently Mark Heily put it up on GitHub as well at 
>> https://github.com/mheily/libpwq - it has been quite dormant for the last 
>> few years, but I think that is largely due to things working reasonably well.
>> 
>> So would such more close integration be desirable to make things build more 
>> out of the box, or would you prefer to only use it if found during build 
>> time on the current host? (I would probably prefer the first option, as it 
>> essentially just provides support for functionality that the underlying 
>> platform lacks - the current libpwq supports a few platforms…).
> 
> That seems like a good idea in principle, I agree that it makes good 
> technical sense given libdispatch is presumably the only client of this 
> library, but short term continuing to keep it separate will likely be easiest 
> (for boring non-technical reasons)
> 
> In particular I’ll have to figure out what the situation would be with us 
> continuing to take changes internally from the github repo after importing a 
> whole contributed project into it (as opposed to incremental patches to the 
> existing sourcebase), ideally I would really prefer to not significantly 
> diverge from our internal repo to make that process as straightforward as 
> possible (essentially a git merge…)

That is a good point.

Merging the codebases doesn’t necessarily require that they live in the same 
source repository though. I’m just arguing that if the worqueue 
code/emulation/layer is meant to only have dispatch as a client it allows for 
something more flexible.

-Pierre

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

[swift-corelibs-dev] Implicit conversions between types will be disabled in Foundation

[Philippe Hausler via swift-corelibs-dev]

After seeing numerous failures in type conversions that work in the Mac OS X 
Xcode project target but don’t work in the Linux target, we have come to the 
conclusion that implicit conversions are going to have to be disabled for now.

I have a change incoming that will require all conversions such as `let dict: 
NSDictionary = [“foo” : “bar”]` to use the bridge method to convert. This is 
just an interim solution until we can get better support on the linux side from 
the compiler to enable implicit conversion between object types and struct 
types (which is handled by the protocol _ObjectiveCBridgeable). The change adds 
a new protocol `_ObjectTypeBridgeable` that still has the functionality so that 
once the compiler can support this feature on linux targets we can re-enable 
implicit conversions.

I would strongly suggest that anyone currently developing build against this 
change to ensure that any implicit conversions are made explicitly.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSAttributedString attributesAtIndex return an optional.

[Ross Kimes via swift-corelibs-dev]

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. It seems like a holdover from C to me. Having those be crashing errors 
makes it difficult to scan for code that is handling errors poorly (you can't 
just look for try! or !). There is nothing that looks like it could be 
dangerous in subscripting.

I would much prefer these types of things throw errors. Since straight 
subscripting also seems like a last resort in other parts of the language, 
having an 'throws' version would encourage usage of APIs that don't involve 
straight subscripting.

So in this particular case I would prefer retuning a non-optional dictionary 
(because empty dictionaries are a valid set of attributes) and throw an error 
for going out of bounds.

(Sorry for the double email Kevin. Forgot to switch the recipient before 
replying.)

Ross

> On Dec 8, 2015, at 2:05 PM, Kevin Ballard via swift-corelibs-dev 
>  wrote:
> 
> I agree that precondition is appropriate here. Swift has Optionals and
> throws, yes, but Swift also uses preconditions to do things like range
> checks on subscripting. I believe the general rule is that if something
> is a programmer error, it should be a hard failure (i.e. a
> precondition/assert/fatalError), and throws should only be used for
> "soft" errors. So subscripting past the end of a collection is a
> programmer error, but e.g. trying to decode a non-JSON string as JSON
> with NSJSONSerialization is a "soft" error.
> 
> Also, as an aside, when an API returns a type that already has a notion
> of an empty value (e.g. a Dictionary has [:]), then you should only wrap
> it in an Optional if there's a specific reason to differentiate between
> an empty value and no value at all. In the case of attributesAtIndex,
> I'd expect it to return a non-optional Dictionary, because every valid
> index does have a notion of attributes, even if the attribute set is
> empty at that location. And passing an invalid index is a programmer
> error and should use precondition.
> 
> -Kevin Ballard
> 
> On Tue, Dec 8, 2015, at 07:59 AM, Philippe Hausler via
> swift-corelibs-dev wrote:
>> NSException != throw in swift…
>> NSExceptions should be treated as assert, fatalError, or precondition
>> (precondition in this case is probably preferred)
>> 
>> 
>>> On Dec 8, 2015, at 7:31 AM, James Lee via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> 
 
 Personally, if I indexed past the end of an attributed string, I would 
 expect a precondition to fail and (since Swift can't catch assertion 
 failures) my app to crash. (And from what I can tell, the Apple Foundation 
 versions of these APIs do not return an optional.)
 
 -- 
 Brent Royal-Gordon
 Architechies
 
>>> 
>>> It is worth noting that the current OSX documentation does raise an 
>>> NSRangeException in the case discussed above. With the throw capabilities 
>>> in Swift 2 this makes sense.
>>> 
>>> As you have said, it seems a lot of Foundation API's do not return 
>>> Optionals. I feel this a hangover from ObjC where an empty object (in this 
>>> case an NSDictionary) would be returned. To me this is what Optionals are 
>>> there to replace. 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSAttributedString attributesAtIndex return an optional.

[Brent Royal-Gordon via swift-corelibs-dev]

> 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 subscripting incorrectly, chances are you 
didn’t anticipate the possibility that your subscript might fail and probably 
didn’t write code that’s prepared to handle that error. If you did anticipate 
that possibility, you would have made sure there was a range check in the first 
place.

Ultimately, since Swift.org Foundation is meant to present the same interface 
as Apple Foundation, I don’t think we have much of a choice about this anyway. 
Apple Foundation’s version of this method is non-optional and non-throwing. If 
we deviate from that, we lose compatibility.

-- 
Brent Royal-Gordon
Architechies

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