Re: [swift-evolution] [Rejected] SE-0030 Property Behaviors

When will be a good time to discuss this proposal again? Em qua, 24 de fev de 2016 às 04:14, Douglas Gregor via swift-evolution < swift-evolution@swift.org> escreveu: > The review of SE-0030 “Property Behaviors” ran from February 10...23, > 2016. The proposal in its current form is *rejected*:

Re: [swift-evolution] Swift 5: start your engines

My 2c: Revisit: SE-0030 Property Behaviors Very cool feature, and will help implement new thinks after that! Including async and await maybe! Em ter, 8 de ago de 2017 às 13:23, Ted Kremenek via swift

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

Based on these same concerns, how to do this using async/await ? func process() -> Void) { loadWebResource("bigData.txt") { dataResource in // } printf("BigData Scheduled to load") loadWebResource("smallData.txt") { dataResource in // } printf(

Re: [swift-evolution] New async keyword usage

Interesting, its syntax seems to improve the "fire and forget" issue. @IBAction func buttonClicked() { async downloadAndUpdateImageView() } In this case, the return Future also does not need to be produced as one of the compiler optimization. Also, func someAsyncFunc() async -> User {

Re: [swift-evolution] New async keyword usage

Makes sense. But if i'm reading its right (and the original proposal too), in this case we don't have only a syntax sugar, we actually gain another ways to use. First, because Future actually need another proposal, and beginAsync (to me) does not apear to be that rare! "Fire and Forget" is pretty

Re: [swift-evolution] New async keyword usage

Chris's proposal is very explicit about the advantages of the async/await over the Future/Task, we don't need to rephrase here. The most obvious advantage of course is because "await" does not block the execution (Future.get() does). And the whole proposal about async/await/actors is very, very go

Re: [swift-evolution] await keyword "scope"

"Try" does the same, but I do not know anyone who prefers to repeat the same keyword several times. return try func0(try func1(), try func2()) I do not think there's any value in knowing how many interim steps also need "await" ... In practice, you have to wait for everyone anyway. Em seg, 28

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

And that's why I (and others) are suggesting: func processImageData1a() async -> Image { let dataResource = async loadWebResource("dataprofile.txt") // No future type here... Just another way to call dispatch_async under the hood. let imageResource = async loadWebResource("imagedata.dat")

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

We don't need to this now! Again: (Using proposal words) "It is important to understand that this is proposing compiler support that is completely concurrency runtime-agnostic. This proposal does not include a new runtime model (like "actors") - it works just as well with GCD as with pthreads or

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

In this example i think we lose clarity, just looking for the code we cant know if this two line will run on parallel or not! Also, image.get blocks the thread, in this case we need the await anyway! And `async` can throws too... So the error handler can be pretty similar. let image = async prepro

Re: [swift-evolution] [Concurrency] modifying beginAsync, suspendAsync to support cancellation

I dont like the idea of beginAsync, suspendAsync be a standard library functions to support a language level resource. beginAsync can be only `async` and suspendAsync can be "await resync" (something like that). Saing that, cancel a operations is not that simple! Abrupt abort any thread can leav

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

fault image will be used. With async/await the code for downloadImage and > downloadText will have to start timers and throw if the timers timeout. > Nothing to do in the Future version, it handles timeout for you. > > Neither or the above versions have cancel or control over the que

Re: [swift-evolution] [Concurrency] A slightly different perspective

Tanks Jonathan, As you may already know, I am a great advocate of this feature. I will not repeat my explanations and examples that I gave in the other threads. But I think you got the idea right. Even without any kind of optimization, I believe there is a clear gain in this approach. But I think

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

Hello, I have a little question about the actors. On WWDC 2012 Session 712 one of the most important tips (for me at least) was: Improve Performance with Reader-Writer Access Basically: • Use concurrent subsystem queue: DISPATCH_QUEUE_CONCURRENT • Use synchronous concurrent “reads”: dispatch_syn

Re: [swift-evolution] [Concurrency] A slightly different perspective

de set de 2017 às 14:53, Michel Fortin escreveu: > > > Le 4 sept. 2017 à 10:01, Wallacy via swift-evolution < > swift-evolution@swift.org> a écrit : > > > > func processImageData1a() async -> > > Image { > > let dataResource = async loadWebReso

Re: [swift-evolution] [Concurrency] A slightly different perspective

c/await leads to people writing things equivalent to using > the global queue the way you suggest, we failed from a system performance > perspective. > > -Pierre > > On Sep 4, 2017, at 12:55 PM, Wallacy via swift-evolution < > swift-evolution@swift.org> wrote: > &g

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

a big refactory is needed to solve something that has not been considered now. Okay to start small, I'm just trying to better visualize what may be necessary in the future to make sure that what has been done now will be compatible. Thanks. Em seg, 4 de set de 2017 às 16:06, Pierre Habou

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

Fair enough! Tranks! Em ter, 5 de set de 2017 às 13:48, Pierre Habouzit escreveu: > On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution < > swift-evolution@swift.org> wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > rele

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

This is the only part of the proposal that i can't concur! ^async^ at call side solve this nicely! And Pierre also showed how common people are doing it wrong! And will make this wrong using Futures too. func doit() async { let dataResource = async loadWebResource("dataprofile.txt”) let imageReso

Re: [swift-evolution] await keyword "scope"

Em ter, 12 de set de 2017 às 16:48, Adam Kemp via swift-evolution < swift-evolution@swift.org> escreveu: > > I think that decision makes sense for try/throws, but I feel like the > await keyword is fundamentally different from that. The pitfalls of not > understanding how the code is transformed a

Re: [swift-evolution] await keyword "scope"

"No, the order of execution is well-defined. The problem isn’t in which order the arguments are executed. The problem is when that evaluation happens with respect to when we return to the run loop. That’s an entirely new problem with async/await. In Swift today it is not possible to write code that

Re: [swift-evolution] Question about async await

Good article. Thanks. Em sex, 22 de set de 2017 às 14:24, Kenny Leung via swift-evolution < swift-evolution@swift.org> escreveu: > Here’s more stuff I found on how this could work. It’s slowly becoming > less murky to me. > > http://blog.stephencleary.com/2013/11/there-is-no-thread.html > > -Kenny

[swift-evolution] Property Behaviors and Swift 4.0 Stage 1.

Is Property Behaviors considered for Stage 1? https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md Because the project roadmap says: The high-priority features supporting Stage 1's source and ABI stability goals are: ... Resilience: resilience provides a

Re: [swift-evolution] [Draft] Mixins

FWIW: Im working on a proposal to cover this points, using protocols a few days. One or two days i will post... Em qui, 21 de abr de 2016 09:27, Tal Atlas via swift-evolution < swift-evolution@swift.org> escreveu: > I agree that the solution to any of these problems would be better done > with i

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I wrote a proposal few weeks ago about "Complete Composition Model" in Swift, but still not finish (too many details)... In my proposal, i thought about the problem in this topic. However after thinking more generally, I found it best to solve in other direction: - Every time one default protocol

Re: [swift-evolution] Extending init checks for property initialization

Why not use the Designated Initializers and Convenience Initializers ? private var videoPlayer: AVPlayer private var videoPlayerLayer: AVPlayerLayer required overri

Re: [swift-evolution] [Pitch] Memos for Struct Calculated Properties

We already have lazy properties to get what you are describing. But we need to wait for the Properties Behavior for the ability to clean a precomputed lazy var. Em sáb, 7 de mai de 2016 11:27, Jonathan Hull via swift-evolution < swift-evolution@swift.org> escreveu: > I saw a message come across a

Re: [swift-evolution] More fine tuning optimization to swift compiler

I believe the -O is already able to loop unroll, but now C-Style loop is gone, and maybe will be more "difficult" to compiler make this optimization, except of course using range literals. Em ter, 9 de ago de 2016 às 13:10, Muse M via swift-evolution < swift-evolution@swift.org> escreveu: > -Oloo

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

You don't need to act like a jerk. It's really difficult ask to you follow the past discussions? Compositions type are "generally" well accepted for this community, but has some problems to be solved first. Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution < swift-evolution@sw

Re: [swift-evolution] ABI in Layman's terms?

Just to put in perspective: If we don't define now (probably we won't) how to add storage properties to existing types and/or define storage properties in protocols, we will never get this? I remember long time ago, Greg Parker presented some new refcount representation, and one of advantages is s

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Also, the number of "Views" is pretty important to know! It's a complementary information to indicate community engagement. Em dom, 21 de ago de 2016 às 14:33, Muhammad Mominul Huque Nahid via swift-evolution escreveu: > +1 for discourse > > To me mailing list is a bit old. Discourse is more app

Re: [swift-evolution] Partial list of open Swift 3 design topics

And something about Property Behaviors? It's a very good proposal, and can solve many problems cited in other proposals in this list. Em qua, 22 de jun de 2016 às 22:08, Chris Lattner via swift-evolution < swift-evolution@swift.org> escreveu: > Hi everyone, > > Here is a partial list of the open

Re: [swift-evolution] [Review] Require self for accessing instance members

* What is your evaluation of the proposal? Against. * Is the problem being addressed significant enough to warrant a change to Swift? I do not believe that this is the best way to solve the problem described. * Does this proposal fit well with the feel and direction of Swift? I don't th

Re: [swift-evolution] Coroutine for Swift

FWIW: https://github.com/Zewo/Venice On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > I just want a wide public concern in swift community with this > implementation. > Should we have a proposal about @goto and @label as workaround? Just a

Re: [swift-evolution] Immutable Structures

*"To me documentation plus the type signatures are generally enough. However I could probably still agree with you if mutating was also used in classes. What's the point of having it only on structures?"* Because, structs ARE immutable by default. The mutating keyword says to holding variable to c

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

How to differentiate these functions? class A{ func someFunc(a: Int) -> Int{ return 0; } func someFunc(a: Int) -> Double{ return 0; } func someFunc(a: Double) -> Int{ return 0; } func someFunc(a: Double) -> Double{ return 0; } func

Re: [swift-evolution] Lambda function syntax

So how do you expect me to type "naturally" the character λ? Not all keyboards are equal, are different languages around the world, with different keyboard layouts. However in all I can type "in" but not this symbol that can only reproduce by copying and pasting. Em dom, 27 de dez de 2015 às 21:

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

signature at some point. Em dom, 27 de dez de 2015 às 23:11, Michel Fortin escreveu: > Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution < > swift-evolution@swift.org> a écrit : > > Even with backticks would not be possible. > > > > You may need to reference the

Re: [swift-evolution] Lambda function syntax

Sorry, i misread you mail. Em dom, 27 de dez de 2015 às 23:20, Developer escreveu: > Oh my, no. I don't intend Swift to become the λ calculus, I was merely > making an analogy (and a joke, 3 replies ago). In the same way that λ is > the simplest set of rules embodying the powerful construct ab

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

And if we only make the actual type inference more powerful? Using the examples on proposal: extension UIView { func insertSubview(view: UIView, at index: Int) func insertSubview(view: UIView, aboveSubview siblingSubview: UIView) func insertSubview(view: UIView, belowSubview siblingSubview:

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

"In the context of this proposal, I think of backticks as delimiters around a generalized name. It's a generalization of today's notion that it's an escaped identifier; more like an escaped name." backticks are just a "hack", with the proposal 0001 (Allow (most) keywords as argument labels), your

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

FWIW: In cases like this, just remember call ".reverse()" and remove from the back. var array = [ "", "a", "b", "c", "", "d" ] for (index, element) in array.enumerate().reverse() { if element == "" { array.removeAtIndex(index) } } print(array) // ["a", "b", "c", "d"] zip is useful

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I have to say, I'm not very happy with the progress of this topic .. Let me explain: I'm Swift user from day 1. A few weeks after, even with the limitations of language, had an application in production. One of the "cool" features that regularly use in my application is the "file private" access l

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> escreveu: > With these names we lose consistency. The current scheme makes it very > clear that each next level is a subset of the previous level. With > "internal", fileprivate looks out of place. >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Just as note, i think the sintax should be: 0...9 0..<9 0>..9 0>.<9 Because the intention is produce a number bigger than 0 (start). So greater than zero less than nine. Em sex, 8 de abr de 2016 22:50, Michel Fortin via swift-evolution < swift-evolution@swift.org> escreveu: > Le 8 avr. 2016 à

Re: [swift-evolution] Enums and Source Compatibility

@Slava If my understanding is correct. If I compile my application with the x.y.z version of a Apple System Framework (like Cocoa). And this framework is updated, several calls from my application to the "new" framework version x.z.a behave like in the x.y.z version for compatibility issues right?

Re: [swift-evolution] continuations - "extensions on steroids" idea

Like Adam said, this make much more sense than "classprivate./typeprivate"... +1 for me. You just create another 'bucket'! ;) Em ter, 31 de out de 2017 às 08:19, Mike Kluev via swift-evolution < swift-evolution@swift.org> escreveu: > On 31 October 2017 at 06:57, Goffredo Marocchi wrote: > >> I

Re: [swift-evolution] continuations - "extensions on steroids" idea

Partial (like in C#) is good enough. Em qua, 1 de nov de 2017 às 09:52, Mike Kluev via swift-evolution < swift-evolution@swift.org> escreveu: > class ViewController { > part DataSource > ... > } > > part DataSource of ViewController: UITableViewDataSource { > > } > > Mike > > ___

Re: [swift-evolution] Adding Result to the Standard Library

If my memory does not fail, there has also been a discussion about adding a "payload" to the optional types that fit into that context. Something like: //Current enum Optional{ case Some(T) case None } // Adding enum Optional{ case Some(T) case None(Error) //Maybe adding support functions t

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

The Compatibility Suite is a good start, but I agree that something a bit more centralized has its benefits. To be perfect, Compatibility Suite and Swift Package Manager need to work "together" to offer something simple like nodejs npm and a friendly (and central) interface to not only find these

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

@Félix Fischer Yes, I wanted to say central index. I chose the wrong term. Actually I could have summed it up like this: - Central Index - SwiftPM to download/search using this index like npm/nuget - GStreamer organization Style. I do not agree with Ted that only a few projects should be ranked,

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

Em qua, 8 de nov de 2017 às 17:58, Ted Kremenek escreveu: > > On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution < > swift-evolution@swift.org> wro

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

great point about shouting out on the mailing list for a > project and getting no real response. I’m getting optimistic that we can > move to a forum soon; could we use that forum in a way to help facilitate > something like what you are proposing? > > > On Nov 8, 2017, at 4:3

Re: [swift-evolution] async void

Before i make a comment on this topic i need to confirm something: On original proposal, this: func processImageData1(completionBlock: (result: Image) -> Void) { loadWebResource("dataprofile.txt") { dataResource in loadWebResource("imagedata.dat") { imageResource in decode

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution < swift-evolution@swift.org> escreveu: > On Mon, 13 Nov 2017 22:30:25 +0100 David Hart wrote: > >> > On 13 Nov 2017, at 05:52, Slava Pestov wrote: >> > >> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

I will be on vacation after December 1, so I will have some time to help if needed. Em qua, 15 de nov de 2017 às 21:39, Nicole Jacque via swift-dev < swift-...@swift.org> escreveu: > As Ted Kremenek has previously announced, we are in the process of moving > the Swift mailing lists to Discourse. P

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

I vote for “mapNonNil”, “mapDroppingNil” or “unwrappingMap”(or some variations using unwrap). It’s not pretty, but does the job! Em qua, 15 de nov de 2017 às 22:36, Greg Parker via swift-evolution < swift-evolution@swift.org> escreveu: > On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolutio

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

Let’s think I little. If the ideia is choose the best name to explain the function: If the function drop the nil values and after that does a map operation. Names like dropNilAndMap make sense, right? But we are talking about functions that mimics the berraviour of Functional programming language

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

I think is that's why some folks ask for count be UInt (or UInt64 when appropriate) some time ago. I dont know how solve this, but appear to be less painful than current IndexDistance. Em qua, 29 de nov de 2017 às 14:46, Ben Cohen via swift-evolution < swift-evolution@swift.org> escreveu: > You

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

Distances, yes... *Count*, not necessarily. Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu escreveu: > Distance must be signed, so it cannot be UInt. > On Wed, Nov 29, 2017 at 11:14 Wallacy wrote: > >> I think is that's why some folks ask for count be UInt (or UInt64 when >> appropriate) some t

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

May the question is a little silly. But can this proposal be made on top of property behaviors? ( or the inverse). We already talk about *new kinds* of getters and setters, possibly new sintaxes to call then... I don’t now, maybe I’m overlooking the problem, but feels that , wherever we choose he

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

Is possible to make the compile check what is used inside of == and then provide the hash value? And if compile cannot check (for whatever reason) what’s properties is used inside == then raise a compile error? Em sex, 15 de dez de 2017 às 15:58, Joe Groff via swift-evolution < swift-evolution@swif

Re: [swift-evolution] Enums and Source Compatibility

Actually this make much more sense than original proposal. Good call! Just to check... Its not better this? public enum HomeworkExcuse { case eatenByPet default case thoughtItWasDueNextWeek} If i understood correctly, if the enum is not exhaustible, must be considered as this default valu

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

If I understand this correctly. This is exactly the same argument in favor to maintain the ABI unstable and always bundle the standard library and the runtime with the app. Another alternative is, not only, separate the standard library on small pieces, but also dynamic link this specific version

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

This. I asked that already and they not understand me very well. I see no reason for each app to have its own version of "deprecated lib". Also we can keep the libswiftCore_4.1.dylib, libswiftCore_5.0.dylib, libswiftCore_5.1.dylib etc on the SO too. The default target must be libswiftCore.dylib,