Hi Slava,
> On 22 Dec 2017, at 7:13 am, Slava Pestov wrote:
>
> Hi Johannes,
>
> Thanks for reviewing this proposal!
>
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution
>> wrote:
>
>> The library I'm working on will presumably
> On 21 Dec 2017, at 4:06 pm, Johannes Weiß via swift-evolution
> wrote:
>
>>
>> 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
&g
> 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:
>
> https://github.com/apple/swift-evolution/blob/master/proposal
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,
>
> Associated type inferenc
+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 thoughts nicely. I think “flatMap” in its current fo
> 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 recursion mechanism and then
>> `fix` can be useful I’
> On 28 Oct 2017, at 10:14 pm, John McCall wrote:
>
>
>> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution
>> wrote:
>>
>> Hi Mike,
>>
>>> On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote:
>>>
>>> on Date: Fri,
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 terms of recursion you can fiddle it:
> >
> > struct RecursiveClosure {
> >
> 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, it will make closures
> bett
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 to discuss a small language change. I vaguely remember
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 AnyObject is a source of imp
+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 available on
> values of type Strin
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 f
> 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:
>>
>> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts
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 t
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 r
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 af
O it shouldn't 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ß vi
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 I
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
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 r
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 sup
22 matches
Mail list logo