> On Nov 14, 2016, at 11:07 AM, Jordan Rose via swift-evolution
> wrote:
>
> This doesn’t seem unreasonable, but I’m not sure if that makes it reasonable.
> :-) What’s your use case? The stripped-down code seems like it could use any
> unique key, including #function.
>
> Jordan
One use ca
Currently, APIs that get imported with COpaquePointer make Swift *less* safe
than C. Fixing this seems like a breaking change, since it would change the
meaning of existing code that uses COpaquePointer.
As a motivating example consider:
import Darwin
var state = copyfile_state_alloc()
print
> On May 20, 2016, at 10:35 AM, Chris Lattner via swift-evolution
> wrote:
>
> I don’t think that would fly :-). That said, has anyone considered requiring
> a keyword on the method in the protocol extension that makes it explicit that
> the dispatch is non-dynamic?
This would be fabulous.
> On Mar 23, 2016, at 10:36 PM, Chris Lattner wrote:
> I understand that Jordan withdrew his objection later (because no overload is
> required) but it still isn't clear to me that autoreleasepool should return a
> value.
>
> Here’s my thought process: autoreleasepool is *intentionally* lookin
> On Mar 21, 2016, at 9:37 AM, Jordan Rose wrote:
>
> -1 for the signature change. The most common case of autoreleasepool does not
> return a value and has a multi-statement body that prevents the result type
> from being inferred. This needs to continue to work:
>
> autoreleasepool {
> fo
