> On Jun 10, 2017, at 2:42 PM, Paul Cantrell via swift-evolution
> wrote:
>
> Being able to specify things about closure capturing at the API level could
> do wonders for Siesta — though its problems may be beyond the scope of what’s
> proposed here (or what’s workable at all).
>
> Siesta ex
Being able to specify things about closure capturing at the API level could do
wonders for Siesta — though its problems may be beyond the scope of what’s
proposed here (or what’s workable at all).
Siesta exposes this API call:
someResource.addObserver(owner: self) { // (1)
[weak se
If weak closures ever become a thing, I do think that the implicit strong
promotion of the closure's captures should never happen and instead, the
closure should be manually optional-unwrapped before it's called, so that the
existing safety guarantees of weak object references would persist.
>
Just a few more replies from John McCall:
You want to invalidate the closure value based on whether any of its captures
have been invalidated.
It’s an interesting idea, but it’s quite complex because an invalidatable
closure is definitely a different sort of thing from a normal one.
So like yo
Well I simply reused the existing keywords as part of the closure type to
demonstrate the idea here as easy as possible.
About the _true_ weak/unowned closures. First I asked John McCall on twitter
about this whole idea. Here is his reply about the _true_ weak closures:
You mean a weak referenc
I don't think it's a good idea to make the `weak`-ness of the closure part of
the type system.
The current approach to `weak/unowned` is that it's a storage class that
applies to the variable, not the value.
This makes sense because you don't *use* a weak reference, you only *store* it
weakly.
I
Hi Matthew,
Thank you for the hint. Indeed, at first glance your proposal is very similar
to my thinking. I’ll try to dive deeper into your proposal and find out more
about the discussion behind it when I get some more time for that.
We could collaborate on a revision for Swift 5 if you would l
Hi Adrian, this is pretty similar to the Guarded Closures proposal I drafted in
February. This proposal needs a revision incorporating discussion feedback and
some new ideas. If you’re interested, here’s a link to the original discussion
thread:
https://lists.swift.org/pipermail/swift-evoluti
Agree with Gor, this can work nicely with ownership concept.Though it will
require a lot of compiler analysis, I think as Swift’s goal is to be a safer
language, still worth it.
I like this idea. But yes, we need a more detail proposal, this need a lot of
work.
On 2017年6月10日 -0700 AM10:49, Gor
The benefit that I can see here is the ability to guarantee memory safety on
API level, by way of specifying weak closure members. Previously, there way no
conceivable way of knowing that because a closure can essentially capture
whatever it wants (even the very object it's stored in), so this w
Hello Evolution,
I’d like to pitch a new idea and see where it would go. Recently I tapped into
a small trap and just now realized that even that non-escaping should have been
the default for closures (SE–0103) there is an exception for that. Apparently
generics don’t follow that rule and a clo
11 matches
Mail list logo
