Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey, > [...] > I see it as my responsibility to know exactly what code I’m pulling into my > package. In my view, it’s absolutely unsafe to trust other people’s code. > Even when they mean no harm, trusting them to properly apply SemVer is the > same issue. maybe we should have the tooling

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hi Eloy, > > [...] >> I have no idea how well it works but if we'll end up relying on proper >> semantic versioning, tool support sounds like a good idea to me. > > This is what I was referring to when I mentioned that automation can only > take you so far. It is easily possible to do a patch

Re: [swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

Hi John, > [...] >> This is a pitch to make [`errno`][1]-setting functions properly usable, as >> in having a guarantee to get the correct `errno` value on failure of a >> [system call][2]. Currently, functions which set `errno` are just exported >> in the Darwin/Glibc modules with (as far as

Re: [swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

be exported to Swift as its value is undefined almost(?) everywhere. [4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html [5]: http://man7.org/linux/man-pages/man3/errno.3.html All the best, Johannes > On 2 Nov 2016, at 1:12 pm, Johannes Weiß via swift-evolution >

Re: [swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

Hi Joe, >> I just realised, that the problem is slightly worse than I originally >> described. I believed that successful calls in between the actual call the >> programmer wanted to make and capturing `errno` are not a problem. >> >> But POSIX seems to suggest [4] that "The setting of errno

[swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

Hey swift-evolution, First of all apologies, this is not a full proposal yet, it's meant to kick off a discussion on how to resolve the issue. # Make `errno`-setting functions more usable from Swift ## Introduction This is a pitch to make [`errno`][1]-setting functions properly usable, as in

Re: [swift-evolution] typed throws

Hi John, tl;dr I think throws should be optionally typed. Ie. `func someSyscall(...) throws(POSIXError) -> Int` should be just as legal as `func doSomeFancyCocoaOperation() throws -> Void`. > [...] >> Here is where I think things stand on it: >> - There is consensus that untyped throws is the

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

Hi Chris & swift-evo, (Given the already lengthy thread I tried to separate my points and keep them reasonably short to allow people to skip points they don't care about. I'm very happy to expand on the points.) Thanks very much for writing up your thoughts/proposal, I've been waiting to see

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

> On 11 Sep 2017, at 10:04 pm, Adam Kemp via swift-evolution > wrote: > > > >> On Sep 11, 2017, at 1:15 PM, Kenny Leung via swift-evolution >> wrote: >> >> I found a decent description about async/await here: >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 and agree with Stephen on why > On 8 Nov 2017, at 8:17 am, Stephen Celis via swift-evolution > wrote: > > +1 > >> On Nov 7, 2017, at 6:23 PM, John McCall wrote: >> >> • What is your evaluation of the proposal? > > BJ summarized my

Re: [swift-evolution] [RFC] Associated type inference

Hi Douglas, First of all, thanks very much for looking into this seemingly dark corner of the compiler. This caused us a lot of trouble already. Comments inline. > On 1 Dec 2017, at 12:28 am, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, >

Re: [swift-evolution] Making capturing semantics of local

> On 28 Oct 2017, at 10:14 pm, John McCall <rjmcc...@apple.com> wrote: > > >> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi Mike, >> >>> On 27 Oct 2017, at 7:05 pm, Mi

Re: [swift-evolution] Making capturing semantics of local functions explicit

Hi, > On 25 Oct 2017, at 6:01 pm, John McCall via swift-evolution > wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> wrote: >> I got bit again by a sneaky memory leak concerning local functions and would >> like

Re: [swift-evolution] Opaque Pointers in Swift

Hi Cory, I think we're dealing with two separate issues here. 1) that all forward declared struct pointers get imported as an OpaquePointer which makes us lose all type-safety 2) that it's a fairly frequent case that C libraries evolve from 'pointers to fully declared structs' to 'pointers to

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

+1, it's currently really non-obvious where these automatic bridges are happening which keeps costing me time. > On 24 Oct 2017, at 11:00 pm, Slava Pestov via swift-evolution > wrote: > > Hi, > > Members of NSString, except those defined in Foundation, are

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

yes, please. Especially having quite a long time (4.1 until 5.0) where this works but issues a warning sounds like a great transition plan. > On 24 Oct 2017, at 11:02 pm, Slava Pestov via swift-evolution > wrote: > > Hi all, > > Dynamic dispatch of methods through

Re: [swift-evolution] Making capturing semantics of local

> On 29 Oct 2017, at 3:01 pm, Mike Kluev wrote: > >> On 29 October 2017 at 14:02, Johannes Weiß wrote: >> >> Definitely not arguing with that. But there are (valid?) cases when you want >> a recursive closure which doesn’t have a native

Re: [swift-evolution] Making capturing semantics of local

> On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution > wrote: > > > Closures cannot replace all uses of local functions. Local functions can be > > recursive, and have a generic parameter list. > > My response would be add these featurtes to closures,

Re: [swift-evolution] Making capturing semantics of local

Hi Mike, > On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: > > on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß > wrote: > > > On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution > > wrote: > > > > In

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Slava, > On 22 Dec 2017, at 7:13 am, Slava Pestov <spes...@apple.com> wrote: > > Hi Johannes, > > Thanks for reviewing this proposal! > >> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution >> <swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE-0193 - Cross-module inlining and specialization" begins now > and runs through January 5, 2018. > > The proposal is available here: > >

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On 21 Dec 2017, at 4:06 pm, Johannes Weiß via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The review of "SE