Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Florent Vilmart via swift-evolution]

Object that are functions too, Amazing! I wanted that in Javascript for a while!

On Nov 10, 2017, 1:04 PM -0500, Joe Groff via swift-evolution 
, wrote:
> I don't like the idea of some calls having wildly different semantics from 
> others; it's difficult enough to tell what exactly a call might be doing 
> already. Since we also lack the more obvious static "Callable" protocol idea 
> to give even well-typed call syntax to user-defined types, this also seems 
> like it'd be easily abused for that purpose too.
>
> I think a much better general solution to the problem of "make dynamic 
> systems interact with type systems" is something like F#'s type providers 
> which lets you write your own importers that look at dynamic information from 
> a database, dynamic language VM, or some other system and generate type 
> information usable by the compiler. Integration at the importer level could 
> let you produce more well-typed Swift declarations by looking at the runtime 
> information you get by importing a Python module.
>
> -Joe
>
> > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution 
> >  wrote:
> >
> > Hello all,
> >
> > I have a couple of proposals cooking in a quest to make Swift interoperate 
> > with dynamically typed languages like Python better. Instead of baking in 
> > hard coded support for one language or the other, I’m preferring to add a 
> > few small but general purpose capabilities to Swift. This is the first, 
> > which allows a Swift type to become “callable”.
> >
> > The proposal is here:
> > https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d
> >
> > I’ve also attached a snapshot below, but it will drift out of date as the 
> > proposal is refined. Feedback and thoughts are appreciated, thanks!
> >
> > -Chris
> >
> >
> >
> >
> >
> > Introduce user-defined dynamically "callable" types
> >
> > • Proposal: SE-
> > • Author: Chris Lattner
> > • Review Manager: TBD
> > • Status: Awaiting implementation
> > Introduction
> >
> > This proposal introduces a new DynamicCallable protocol to the standard 
> > library. Types that conform to it are "callable" with the function call 
> > syntax. It is simple syntactic sugar which allows the user to write:
> >
> > a = someValue(keyword1: 42, "foo", keyword2: 19)
> > and have it be interpreted by the compiler as:
> >
> > a = someValue.dynamicCall(arguments
> > : [
> > (
> > "keyword1", 42), ("", "foo"), ("keyword2", 19
> > )
> > ])
> >
> > Other languages have analogous features (e.g. Python "callables"), but the 
> > primary motivation of this proposal is to allow elegant and natural 
> > interoperation with dynamic languages in Swift.
> >
> > Swift-evolution thread: Discussion thread topic for that proposal
> >
> > Motivation
> >
> > Swift is well known for being exceptional at interworking with existing C 
> > and Objective-C APIs, but its support for calling APIs written in scripting 
> > langauges like Python, Perl, and Ruby is quite lacking. These languages 
> > provide an extremely dynamic programming model where almost everything is 
> > discovered at runtime.
> >
> > Through the introduction of this proposal, and the related 
> > DynamicMemberLookupProtocol proposal, we seek to fix this problem. We 
> > believe we can make many common APIs feel very natural to use directly from 
> > Swift without all the complexity of implementing something like the Clang 
> > importer. For example, consider this Python code:
> >
> > class Dog
> > :
> >
> > def __init__(self, name
> > ):
> >
> > self.name =
> > name
> >
> > self.tricks = [] # creates a new empty list for each dog
> >
> >
> >
> > def add_trick(self, trick
> > ):
> >
> > self.tricks.append(trick)
> > we would like to be able to use this from Swift like this (the comments 
> > show the corresponding syntax you would use in Python):
> >
> > // import DogModule
> > // import DogModule.Dog as Dog // an alternate
> > let Dog = Python.import(“DogModule.Dog")
> >
> > // dog = Dog("Brianna")
> > let dog = Dog("Brianna")
> >
> > // dog.add_trick("Roll over")
> > dog.add_trick("Roll over")
> >
> > // dog2 = Dog("Kaylee").add_trick("snore")
> > let dog2 = Dog("Kaylee").add_trick("snore")
> > Of course, this would also apply to standard Python APIs as well. Here is 
> > an example working with the Python pickleAPI and the builtin Python 
> > function open:
> >
> > // import pickle
> > let pickle = Python.import("pickle"
> > )
> >
> >
> > // file = open(filename)
> > let file = Python.open
> > (filename)
> >
> >
> > // blob = file.read()
> > let blob = file.read
> > ()
> >
> >
> > // result = pickle.loads(blob)
> > let result = pickle.loads(blob)
> > This can all be expressed today as library functionality written in Swift, 
> > but without this proposal, the code required is unnecessarily verbose and 
> > gross. Without it (but with the related dynamic member lookup proposal) the 
> > code would have a method name (like 

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Florent Vilmart via swift-evolution]

I really like this idea of scoped import, but I’m not sure it’s part of 
anything supported widely. I was about to suggest ‘namespaces’ but that’s not a 
thing in swift.

On Nov 9, 2017, 17:06 -0500, Rod Brown <rodney.bro...@icloud.com>, wrote:
>
> > On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution 
> > <swift-evolution@swift.org> wrote:
> >
> > Hi Florent,
> >
> > We definitely thought about this while designing the set of types with the 
> > Codable proposals.
> >
> > One serious concern was just how much API surface area there already is 
> > with Codable. If we open up the internal classes as well, we risk confusing 
> > the majority of people who are just adopting Codable with APIs that are 
> > intended only for the minority of people who are trying to create their own 
> > custom encoders and decoders.
> >
> > Any thoughts on how to mitigate this?
> >
> > - Tony
>
> I’ve been curious for some time about if we can do something about an opt-in 
> import in Swift?
>
> For example, currently UIGestureRecognizer in UIKit has “subclass only” 
> methods that are protected and opt in. Importing UIKit itself doesn’t bring 
> it in, and instead you need to specifically import 
> UIKit.UIGestureRecognizerSubclass.
>
> I realise this is a standalone case, but I’m wondering whether we can 
> generalise this into something we can propose, to actively support nested 
> scopes in the same way?
>
> This would lend well to disclosing the internals like this. It would avoid 
> users jumping straight for the internal types because they wouldn’t be there 
> with “import Foundation” - it would require something eg “import 
> Foundation.xyz”.
>
> Was this part of an earlier discussion of modules etc?
>
> - Rod
>
> >
> > > On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution 
> > > <swift-evolution@swift.org> wrote:
> > >
> > > At Swift Summit, we discussed with Joe and Jordan about opening up the 
> > > Encoder/Decoder classes in order to make the work of an encoder designer 
> > > easier.
> > >
> > > As I was working on an API project, I found myself into the situation of 
> > > needing to tweak so slightly the encoding strategy this required a full 
> > > copy/paste of the JSONEncoder.swift file and playing with the internals. 
> > > I also wanted to implement a simple QueryStringEncoder/Decoder that would 
> > > properly encode / decode a query string.
> > >
> > > The internally defined classes are proven a very powerful tool of 
> > > reflection as well, being able to collect / untransform a series of 
> > > containers safely into a strongly typed swift object.
> > >
> > > The pitch:
> > >
> > > - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
> > > - Make _JSONEncoder / _JSONDecoder open classes
> > > - Mark public all container implementations of UnkeyedEncodingContainers 
> > > etc...
> > > - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
> > > conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
> > > Encoder.
> > >
> > > Opening those API's isn't for the general Codable implementation, the 
> > > JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
> > > amount of boiler plate one would need to implement in order to provide 
> > > different serialization mechanism / strategy.
> > >
> > >
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Florent Vilmart via swift-evolution]

At Swift Summit, we discussed with Joe and Jordan about opening up the 
Encoder/Decoder classes in order to make the work of an encoder designer easier.

As I was working on an API project, I found myself into the situation of 
needing to tweak so slightly the encoding strategy this required a full 
copy/paste of the JSONEncoder.swift file and playing with the internals. I also 
wanted to implement a simple QueryStringEncoder/Decoder that would properly 
encode / decode a query string.

The internally defined classes are proven a very powerful tool of reflection as 
well, being able to collect / untransform a series of containers safely into a 
strongly typed swift object.

The pitch:

- Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
- Make _JSONEncoder / _JSONDecoder open classes
- Mark public all container implementations of UnkeyedEncodingContainers etc...
- Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
Encoder.

Opening those API's isn't for the general Codable implementation, the 
JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
amount of boiler plate one would need to implement in order to provide 
different serialization mechanism / strategy.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Florent Vilmart via swift-evolution]

Given the evolution of the past 30 years, I'd say yes, vi will still be a thing 
in a 100 years.

On 30 août 2017 18:39 -0400, John Pratt via swift-evolution 
, wrote:
> Well, here is one question: 100 years from now do you think all computers
> should use vi?
>
> At what point would people ever have anything that ever slightly resembles
> something advanced?
>
> Do you ever want anything that
> slightly resembles science fiction, ever, in society? Or should everyone be
> using vi for the rest of civilization?
>
>
> > On Aug 30, 2017, at 5:32 PM, Eagle Offshore  wrote:
> >
> > While I am in theory a fan of literate programming and enjoy integrated 
> > programming environments when they are integrated into a complete literate 
> > system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In 
> > practice if its just a language and not a complete holistic system, and I 
> > can't command the entire thing with God's own editor (I speak of vi - 
> > because its "there" and it is the only editor guaranteed to be "there" on 
> > any system I am ever likely to try to access), I'm not gonna use it.
> >
> > Just my $0.02
> >
> > > On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution 
> > >  wrote:
> > >
> > > I sent a postal envelope to the Swift team with an article I wrote, 
> > > arguing that
> > > symbols and graphics would push the programming language forward.
> > >
> > > Wouldn’t it be nice to have an actual multiplication matrix broken out 
> > > into code,
> > > instead of typing, “matrix()”?  It seems to me Swift has the chance to do 
> > > that.
> > >
> > > Also: why does "<==" still reside in code as "less than or equal to” when
> > > there is a unicode equivalent that looks neat?
> > >
> > > Why can’t the square of x have a superscript of 2 instead of having 
> > > “pow(x,2)?
> > > I think this would make programming much easier to deal with.
> > >
> > > I expound on this issue in my article:
> > >
> > > http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
> > >
> > > Thank you for reading.
> > >
> > >
> > > -John
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Florent Vilmart via swift-evolution]

It actually removes the need of implementing a future library, with proper 
extension of collection types, we’ll be able to implement collect, zip, race, 
map, flatMap etc... most probably part of the Stdlib

On Aug 28, 2017, 21:25 -0400, Howard Lovatt via swift-evolution 
, wrote:
> I don't really get your point ListenableFuture is a Future, so anything using 
> ListenableFuture is using Future. As I said in the original message "... 
> there are a lot of libraries built on top of basic futures ...".
>
> I am pointing out that people actually use Future in Java as the building 
> block, e.g. ListenableFuture. Therefore Swift would benefit from something 
> comparable and if async/await doesn't lead to a better future than you can 
> code using GCD then there is no point.
>
>   -- Howard.
>
> > On 29 August 2017 at 07:14, Jean-Daniel  wrote:
> > >
> > > > Le 28 août 2017 à 06:14, Howard Lovatt via swift-evolution 
> > > >  a écrit :
> > > >
> > > > One of the biggest incumbents in this space on the server side is Java 
> > > > and its concurrency is based on futures and works very well (though 
> > > > there are a lot of libraries built on top of basic futures).
> > >
> > > Most server side libraries don’t use Java Future as they force blocking 
> > > at some point to get the future result. They instead have there own 
> > > implementation that provide async completion handler (ListenableFuture, 
> > > …), which result in the pattern we are trying to avoid with coroutine and 
> > > async/await.  This is not a very good example.
> > >
> > > > > On 28 August 2017 at 12:35, Florent Vilmart  
> > > > > wrote:
> > > > > > Adam, you’re completely right, languages as c# and JS have been 
> > > > > > through the path before, (callback, Promises , async/await) I 
> > > > > > believe Chris’s goal it to avoid building a promise implementation 
> > > > > > and go straight to a coroutines model, which is more deeply 
> > > > > > integrated with the compiler. I don’t see a particular trade off, 
> > > > > > pursuing that route, and the main benefit is that coroutines can 
> > > > > > power any asynchronous metaphor (Signals, Streams, Futures, 
> > > > > > Promises etc...) which is not true of Futures so i would tend to 
> > > > > > think that for the long run, and to maximize usability, 
> > > > > > async/await/yield would probably be the way to go.
> > > > > >
> > > > > > On Aug 27, 2017, 22:22 -0400, Adam Kemp , 
> > > > > > wrote:
> > > > > > > As has been explained, futures can be built on top of async/await 
> > > > > > > (or the other way around). You can have the best of both worlds. 
> > > > > > > We are not losing anything by having this feature. It would be a 
> > > > > > > huge improvement to have this as an option.
> > > > > > >
> > > > > > > However, using futures correctly requires more nested closures 
> > > > > > > than you have shown in your examples to avoid blocking any 
> > > > > > > threads. That's why you're not seeing the advantage to 
> > > > > > > async/await. You're comparing examples that have very different 
> > > > > > > behaviors.
> > > > > > >
> > > > > > > That said, I have also expressed my opinion that it is better to 
> > > > > > > build async/await on top of futures rather than the other way 
> > > > > > > around. I believe it is more powerful and cleaner to make 
> > > > > > > async/await work with any arbitrary future type (via a protocol). 
> > > > > > > The alternative (building futures on top of async/await) requires 
> > > > > > > more code when the two are mixed. I very much prefer how it's 
> > > > > > > done in C#, where you can freely mix the two models without 
> > > > > > > having to resort to ad-hoc wrappers, and you can use async/await 
> > > > > > > with any futures implementation you might already be using.
> > > > > > >
> > > > > > > I really think we should be having more discussion about the 
> > > > > > > tradeoffs between those two approaches, and I'm concerned that 
> > > > > > > some of the opinions about how C# does it are not based on a 
> > > > > > > clear and accurate understanding of how it actually works in that 
> > > > > > > language.
> > > > > > >
> > > > > > > --
> > > > > > > Adam Kemp
> > > > > > >
> > > > > > > On Aug 27, 2017, at 6:02 PM, Howard Lovatt 
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > The async/await is very similar to the proposed Future (as I 
> > > > > > > > posed earlier) with regard to completion-handler code, they 
> > > > > > > > both re-write the imported completion-handler function using a 
> > > > > > > > closure, the relevant sentence from the Async Proposal is:
> > > > > > > >
> > > > > > > > > quote_type
> > > > > > > > > "Under the hood, the compiler rewrites this code using nested 
> > > > > > > > > closures ..."
> > > > > > > >
> > > > > > > > Unlike the proposed 

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

[Florent Vilmart via swift-evolution]

I can see where you're going with that.
For me, the big unknown (and unspecified so far) is

func process() async -> Image { ... }

let result = process() // what is result? CoroutineType ?

or am I missing something here?

On 28 août 2017 16:07 -0400, Adam Kemp , wrote:
> I think the biggest tradeoff is clearer when you look at the examples from 
> the proposal where futures are built on top of async/await:
>
> > func processImageData1a() async -> Image {
> >   let dataResource  = Future { await loadWebResource("dataprofile.txt") }
> >   let imageResource = Future { await loadWebResource("imagedata.dat") }
> >
> >   // ... other stuff can go here to cover load latency...
> >
> >   let imageTmp    = await decodeImage(dataResource.get(), 
> > imageResource.get())
> >   let imageResult = await dewarpAndCleanupImage(imageTmp)
> >   return imageResult
> > }
>
> With this approach you have to wrap each call site to create a future. 
> Compare to this:
>
> > func processImageData1a() -> Future {
> >   let dataResourceFuture  = loadWebResource("dataprofile.txt”);
> >   let imageResourceFuture = loadWebResource("imagedata.dat”);
> >
> >   // ... other stuff can go here to cover load latency...
> >
> >   let imageTmp    = await decodeImage(await dataResourceFuture, await 
> > imageResourceFuture)
> >   let imageResult = await dewarpAndCleanupImage(imageTmp)
> >   return imageResult
> > }
>
> Here, not only are the explicit wrappers gone, but this function itself can 
> be used with either await or as a future. You get both options with one 
> implementation.
>
> As I’ve mentioned before, C#’s implementation is not tied to any one 
> particular futures implementation. The Task type is commonly used, but 
> async/await does not directly depend on Task. Instead it works with any 
> return type that meets certain requirements (detailed here: 
> https://blogs.msdn.microsoft.com/pfxteam/2011/01/13/await-anything/). Swift 
> could do this using a protocol, which can be retroactively applied using an 
> extension.
>
> Obviously for this to be useful we would need some kind of existing future 
> implementation, but at least we wouldn’t be tied to any particular one. That 
> would mean library maintainers who have already been using their own futures 
> implementations could quickly adopt async/await in their code without having 
> to rewrite their futures library or throw wrappers around every usage of 
> async/await. They could just adopt a protocol (using an extension, even) and 
> get async/await support for free.
>
> The downside is that this feature would be specific to the async/await use 
> case rather than a generic coroutine implementation (i.e., there would have 
> to be a separate compiler transform for yield return). It’s not clear to me 
> why it should be a goal to have just one generic coroutine feature. The 
> real-world usages of async/await and yield return are different enough that 
> I’m not convinced we could have a single compiler feature that meets the 
> needs of both cleanly.
>
> > On Aug 27, 2017, at 7:35 PM, Florent Vilmart  wrote:
> >
> > Adam, you’re completely right, languages as c# and JS have been through the 
> > path before, (callback, Promises , async/await) I believe Chris’s goal it 
> > to avoid building a promise implementation and go straight to a coroutines 
> > model, which is more deeply integrated with the compiler. I don’t see a 
> > particular trade off, pursuing that route, and the main benefit is that 
> > coroutines can power any asynchronous metaphor (Signals, Streams, Futures, 
> > Promises etc...) which is not true of Futures so i would tend to think that 
> > for the long run, and to maximize usability, async/await/yield would 
> > probably be the way to go.
> >
> > On Aug 27, 2017, 22:22 -0400, Adam Kemp , wrote:
> > > As has been explained, futures can be built on top of async/await (or the 
> > > other way around). You can have the best of both worlds. We are not 
> > > losing anything by having this feature. It would be a huge improvement to 
> > > have this as an option.
> > >
> > > However, using futures correctly requires more nested closures than you 
> > > have shown in your examples to avoid blocking any threads. That's why 
> > > you're not seeing the advantage to async/await. You're comparing examples 
> > > that have very different behaviors.
> > >
> > > That said, I have also expressed my opinion that it is better to build 
> > > async/await on top of futures rather than the other way around. I believe 
> > > it is more powerful and cleaner to make async/await work with any 
> > > arbitrary future type (via a protocol). The alternative (building futures 
> > > on top of async/await) requires more code when the two are mixed. I very 
> > > much prefer how it's done in C#, where you can freely mix the two models 
> > > without having to resort to ad-hoc wrappers, and you can use async/await 
> > 

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

[Florent Vilmart via swift-evolution]

Adam, you’re completely right, languages as c# and JS have been through the 
path before, (callback, Promises , async/await) I believe Chris’s goal it to 
avoid building a promise implementation and go straight to a coroutines model, 
which is more deeply integrated with the compiler. I don’t see a particular 
trade off, pursuing that route, and the main benefit is that coroutines can 
power any asynchronous metaphor (Signals, Streams, Futures, Promises etc...) 
which is not true of Futures so i would tend to think that for the long run, 
and to maximize usability, async/await/yield would probably be the way to go.

On Aug 27, 2017, 22:22 -0400, Adam Kemp , wrote:
> As has been explained, futures can be built on top of async/await (or the 
> other way around). You can have the best of both worlds. We are not losing 
> anything by having this feature. It would be a huge improvement to have this 
> as an option.
>
> However, using futures correctly requires more nested closures than you have 
> shown in your examples to avoid blocking any threads. That's why you're not 
> seeing the advantage to async/await. You're comparing examples that have very 
> different behaviors.
>
> That said, I have also expressed my opinion that it is better to build 
> async/await on top of futures rather than the other way around. I believe it 
> is more powerful and cleaner to make async/await work with any arbitrary 
> future type (via a protocol). The alternative (building futures on top of 
> async/await) requires more code when the two are mixed. I very much prefer 
> how it's done in C#, where you can freely mix the two models without having 
> to resort to ad-hoc wrappers, and you can use async/await with any futures 
> implementation you might already be using.
>
> I really think we should be having more discussion about the tradeoffs 
> between those two approaches, and I'm concerned that some of the opinions 
> about how C# does it are not based on a clear and accurate understanding of 
> how it actually works in that language.
>
> --
> Adam Kemp
>
> On Aug 27, 2017, at 6:02 PM, Howard Lovatt  wrote:
>
> > The async/await is very similar to the proposed Future (as I posed earlier) 
> > with regard to completion-handler code, they both re-write the imported 
> > completion-handler function using a closure, the relevant sentence from the 
> > Async Proposal is:
> >
> > > quote_type
> > > "Under the hood, the compiler rewrites this code using nested closures 
> > > ..."
> >
> > Unlike the proposed future code the async code is not naturally parallel, 
> > in the running example the following lines from the async code are run in 
> > series, i.e. await blocks:
> >
> > let dataResource  = await loadWebResource("dataprofile.txt")
> > let imageResource = await loadWebResource("imagedata.dat")
> > The equivalent lines using the proposed Future:
> > let dataResource  = loadWebResource("dataprofile.txt")
> > let imageResource = loadWebResource("imagedata.dat")
> > Run in parallel and therefore are potentially faster assuming that 
> > resources, like cores and IO, are available.
> >
> > Therefore you would be better using a Future than an async, so why provide 
> > an async unless you can make a convincing argument that it allows you to 
> > write a better future?
> >
> >   -- Howard.
> >
> > > On 28 August 2017 at 09:59, Adam Kemp  wrote:
> > > > This example still has nested closures (to create a Future), and still 
> > > > relies on a synchronous get method that will block a thread. 
> > > > Async/await does not require blocking any threads.
> > > >
> > > > I’m definitely a fan of futures, but this example isn’t even a good 
> > > > example of using futures. If you’re using a synchronous get method then 
> > > > you’re not using futures properly. They’re supposed to make it easy to 
> > > > avoid writing blocking code. This example just does the blocking call 
> > > > on some other thread.
> > > >
> > > > Doing it properly would show the benefits of async/await because it 
> > > > would require more nesting and more complex error handling. By 
> > > > simplifying the code you’ve made a comparison between proper 
> > > > asynchronous code (with async/await) and improper asynchronous code 
> > > > (your example).
> > > >
> > > > That tendency to want to just block a thread to make it easier is 
> > > > exactly why async/await is so valuable. You get simple code while still 
> > > > doing it correctly.
> > > >
> > > > --
> > > > Adam Kemp
> > > >
> > > > On Aug 27, 2017, at 4:00 PM, Howard Lovatt via swift-evolution 
> > > >  wrote:
> > > >
> > > > > The running example used in the white paper coded using a Future is:
> > > > >
> > > > > func processImageData1() -> Future {
> > > > >     return AsynchronousFuture { _ -> Image in
> > > > >         let dataResource  = loadWebResource("dataprofile.txt") // 
> > > > > dataResource and 

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

[Florent Vilmart via swift-evolution]

Also, as I re-read the proposal, the async/await would be implemented on top of 
low level co-routines instead of the implementation we’ve seen in other 
languages as a ‘child’ of Promises/Futures. So Futures or Promises would be a 
freebee instead of the opposite. Wrapping cancellation would be straightforward 
and independant of the coroutines, and I tend to think now that this approach 
is more powerful than going with async/await as sugar on top of Futures.

On Aug 27, 2017, 19:59 -0400, Adam Kemp , wrote:
> This example still has nested closures (to create a Future), and still relies 
> on a synchronous get method that will block a thread. Async/await does not 
> require blocking any threads.
>
> I’m definitely a fan of futures, but this example isn’t even a good example 
> of using futures. If you’re using a synchronous get method then you’re not 
> using futures properly. They’re supposed to make it easy to avoid writing 
> blocking code. This example just does the blocking call on some other thread.
>
> Doing it properly would show the benefits of async/await because it would 
> require more nesting and more complex error handling. By simplifying the code 
> you’ve made a comparison between proper asynchronous code (with async/await) 
> and improper asynchronous code (your example).
>
> That tendency to want to just block a thread to make it easier is exactly why 
> async/await is so valuable. You get simple code while still doing it 
> correctly.
>
> --
> Adam Kemp
>
> On Aug 27, 2017, at 4:00 PM, Howard Lovatt via swift-evolution 
>  wrote:
>
> > The running example used in the white paper coded using a Future is:
> >
> > func processImageData1() -> Future {
> >     return AsynchronousFuture { _ -> Image in
> >         let dataResource  = loadWebResource("dataprofile.txt") // 
> > dataResource and imageResource run in parallel.
> >         let imageResource = loadWebResource("imagedata.dat")
> >         let imageTmp      = decodeImage(dataResource.get ?? Resource(path: 
> > "Default data resource or prompt user"), imageResource.get ?? 
> > Resource(path: "Default image resource or prompt user"))
> >         let imageResult   =  dewarpAndCleanupImage(imageTmp.get ?? 
> > Image(dataPath: "Default image or prompt user", imagePath: "Default image 
> > or prompt user"))
> >         return imageResult.get ?? Image(dataPath: "Default image or prompt 
> > user", imagePath: "Default image or prompt user")
> >     }
> > }
> >
> > This also avoids the pyramid of doom; the pyramid is avoided by converting 
> > continuation-handlers into either a sync or future, i.e. it is the importer 
> > that eliminates the nesting by translating the code automatically.
> >
> > This example using Future also demonstrates three advantages of Future: 
> > they are naturally parallel (dataResource and imageResource lines run in 
> > parallel), they timeout automatically (get returns nil if the Future has 
> > taken too long), and if there is a failure (for any reason including 
> > timeout) it provides a method of either detecting the failure or providing 
> > a default (get returns nil on failure).
> >
> > There are a three of other advantages a Future has that this example 
> > doesn’t show: control over which thread the Future runs on, Futures can be 
> > cancelled, and debugging information is available.
> >
> > You could imagine `async` as a syntax sugar for Future, e.g. the above 
> > Future example could be:
> >
> > func processImageData1() async -> Image {
> >     let dataResource  = loadWebResource("dataprofile.txt") // dataResource 
> > and imageResource run in parallel.
> >     let imageResource = loadWebResource("imagedata.dat")
> >     let imageTmp      = decodeImage(dataResource.get ?? Resource(path: 
> > "Default data resource or prompt user"), imageResource.get ?? 
> > Resource(path: "Default image resource or prompt user"))
> >     let imageResult   =  dewarpAndCleanupImage(imageTmp.get ?? 
> > Image(dataPath: "Default image or prompt user", imagePath: "Default image 
> > or prompt user"))
> >     return imageResult.get ?? Image(dataPath: "Default image or prompt 
> > user", imagePath: "Default image or prompt user")
> > }
> >
> > Since an async is sugar for Future the async runs as soon as it is created 
> > (as soon as the underlying Future is created) and get returns an optional 
> > (also cancel and status would be still be present). Then if you want 
> > control over threads and timeout they could be arguments to async:
> >
> > func processImageData1() async(queue: DispatchQueue.main, timeout: 
> > .seconds(5)) -> Image { ... }
> >
> > > On Sat, 26 Aug 2017 at 11:00 pm, Florent Vilmart  
> > > wrote:
> > > > Howard, with async / await, the code is flat and you don’t have to 
> > > > unowned/weak self to prevent hideous cycles in the callbacks.
> > > > Futures can’t do that
> > > >
> > > > On Aug 26, 2017, 04:37 -0400, Goffredo 

Re: [swift-evolution] New async keyword usage

[Florent Vilmart via swift-evolution]

One small note on the async keyword, I would put it first unlike throws:

async func myFunc() -> Type {
return await typeProducer()
}

This improves the readability for the consumer .
Also async implies throws as it denotes wrapping an await call, not sure if we 
need to specify it as well.


On Aug 26, 2017, 14:59 -0400, Goffredo Marocchi via swift-evolution 
<swift-evolution@swift.org>, wrote:
>
>
> Sent from my iPhone
>
> On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution 
> <swift-evolution@swift.org> wrote:
>
> > C# had futures (in the form of the Task Parallel Library) before it had 
> > async/await. If you could see how much async/await has revolutionized C# 
> > programming you would not be making this argument. It is night and day. 
> > Asynchronous code is so much clearer with this feature than without. You 
> > can write code the is simpler and safer at the same time.
> >
> > This isn’t an either/or proposition. We should have both, and they should 
> > work together.
> >
>
> +1
>
> > --
> > Adam Kemp
> >
> > On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution 
> > <swift-evolution@swift.org> wrote:
> >
> > > I just don't see that async/await adds enough to warrant a language 
> > > change. You can write Future on top of GCD and a future type can do more, 
> > > like having a cancel, having a timeout, and giving control over what 
> > > thread is used.
> > >
> > >   -- Howard.
> > >
> > > > On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution 
> > > > <swift-evolution@swift.org> wrote:
> > > > > Isn’t async / await an evolution over Promises / Tasks / Futures? 
> > > > > AFAIK in JS, any function that returns a promise can be ‘await’ upon, 
> > > > > and underneath, to be able to await, a function has to return a 
> > > > > promise. Marking a function async in JS, tells the consumer that some 
> > > > > await are going on inside, and it’s impossible to use await outside 
> > > > > of an async marked function. I believe swift is going that direction 
> > > > > too. Futures / Promises are the foundation on which async / await can 
> > > > > truly express as it formalizes the boxing of the result types.
> > > > > What would be interesting is async being based on a protocol 
> > > > > FutureType for example, so you can bring your own library and yet, 
> > > > > leverage async / await
> > > > >
> > > > > On Aug 25, 2017, 20:50 -0400, Jonathan Hull <jh...@gbis.com>, wrote:
> > > > > >
> > > > > > > On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise 
> > > > > > > <trevor.anneden...@icloud.com> wrote:
> > > > > > >
> > > > > > > =
> > > > > > > > Jonathan Hull jhull at gbis.com
> > > > > > > > This looks somewhat similar to a future, but you can’t interact 
> > > > > > > > with it as a separate type of object.  The value above is just 
> > > > > > > > a UIImage, but with a compiler flag/annotation that forces me 
> > > > > > > > to call await on it before it can be accessed/used.  The 
> > > > > > > > compiler has a lot more freedom to optimize/reorganize things 
> > > > > > > > behind the scenes, because it doesn’t necessarily need to make 
> > > > > > > > an intermediate object.
> > > > > > >
> > > > > > > As for the message of Wallacy I'd be interested the pros and cons 
> > > > > > > of hiding the implementation details ! :)
> > > > > > >
> > > > > > >
> > > > > > > > To prove (or potentially disprove) my assertion that this is 
> > > > > > > > not just sugar, how would you accomplish the following under 
> > > > > > > > the current proposal?
> > > > > > > >
> > > > > > > > let a = async longCalculationA()
> > > > > > > > let b = async longCalculationB() //b doesn’t wait for a to 
> > > > > > > > complete before starting
> > > > > > > > let c = async longCalculationC() //c doesn’t wait for a or b
> > > > > > > > let result = await combineCalculations(a: a, b: b, c: c) 
>

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

[Florent Vilmart via swift-evolution]

Howard, with async / await, the code is flat and you don’t have to unowned/weak 
self to prevent hideous cycles in the callbacks.
Futures can’t do that

On Aug 26, 2017, 04:37 -0400, Goffredo Marocchi via swift-evolution 
, wrote:
> With both he now built in promises in Node8 as well as libraries like 
> Bluebird there was ample time to evaluate them and convert/auto convert at 
> times libraries that loved callback pyramids of doom when the flow grows 
> complex into promise based chains. Converting to Promises seems magical for 
> the simple case, but can quickly descend in hard to follow flows and hard to 
> debug errors when you move to non trivial multi path scenarios. JS is now 
> solving it with their implementation of async/await, but the point is that 
> without the full picture any single solution would break horribly in real 
> life scenarios.
>
> Sent from my iPhone
>
> On 26 Aug 2017, at 06:27, Howard Lovatt via swift-evolution 
>  wrote:
>
> > My argument goes like this:
> >
> >   1. You don't need async/await to write a powerful future type; you can 
> > use the underlying threads just as well, i.e. future with async/await is no 
> > better than future without.
> >
> >   2. Since future is more powerful, thread control, cancel, and timeout, 
> > people should be encouraged to use this; instead because async/await are 
> > language features they will be presumed, incorrectly, to be the best way, 
> > consequently people will get into trouble with deadlocks because they don't 
> > have control.
> >
> >   3. async/await will require some engineering work and will at best make a 
> > mild syntax improvement and at worst lead to deadlocks, therefore they just 
> > don't carry their weight in terms of useful additions to Swift.
> >
> > Therefore, save some engineering effort and just provide a future library.
> >
> > To turn the question round another way, in two forms:
> >
> >   1. What can async/wait do that a future can't?
> >
> >   2. How will future be improved if async/await is added?
> >
> >
> >   -- Howard.
> >
> > > On 26 August 2017 at 02:23, Joe Groff  wrote:
> > > >
> > > > > On Aug 25, 2017, at 12:34 AM, Howard Lovatt  
> > > > > wrote:
> > > > >
> > > > >  In particular a future that is cancellable is more powerful that the 
> > > > > proposed async/await.
> > > >
> > > > It's not more powerful; the features are to some degree disjoint. You 
> > > > can build a Future abstraction and then use async/await to sugar code 
> > > > that threads computation through futures. Getting back to Jakob's 
> > > > example, someone (maybe the Clang importer, maybe Apple's framework 
> > > > developers in an overlay) will still need to build infrastructure on 
> > > > top of IBActions and other currently ad-hoc signalling mechanisms to 
> > > > integrate them into a more expressive coordination framework.
> > > >
> > > > -Joe
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] New async keyword usage

[Florent Vilmart via swift-evolution]

Isn’t async / await an evolution over Promises / Tasks / Futures? AFAIK in JS, 
any function that returns a promise can be ‘await’ upon, and underneath, to be 
able to await, a function has to return a promise. Marking a function async in 
JS, tells the consumer that some await are going on inside, and it’s impossible 
to use await outside of an async marked function. I believe swift is going that 
direction too. Futures / Promises are the foundation on which async / await can 
truly express as it formalizes the boxing of the result types.
What would be interesting is async being based on a protocol FutureType for 
example, so you can bring your own library and yet, leverage async / await

On Aug 25, 2017, 20:50 -0400, Jonathan Hull , wrote:
>
> > On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise 
> >  wrote:
> >
> > =
> > > Jonathan Hull jhull at gbis.com
> > > This looks somewhat similar to a future, but you can’t interact with it 
> > > as a separate type of object.  The value above is just a UIImage, but 
> > > with a compiler flag/annotation that forces me to call await on it before 
> > > it can be accessed/used.  The compiler has a lot more freedom to 
> > > optimize/reorganize things behind the scenes, because it doesn’t 
> > > necessarily need to make an intermediate object.
> >
> > As for the message of Wallacy I'd be interested the pros and cons of hiding 
> > the implementation details ! :)
> >
> >
> > > To prove (or potentially disprove) my assertion that this is not just 
> > > sugar, how would you accomplish the following under the current proposal?
> > >
> > > let a = async longCalculationA()
> > > let b = async longCalculationB() //b doesn’t wait for a to complete 
> > > before starting
> > > let c = async longCalculationC() //c doesn’t wait for a or b
> > > let result = await combineCalculations(a: a, b: b, c: c) //waits until a, 
> > > b, and c are all available
> >
> > Would this be implemented differently than with Futures? I don't have much 
> > experience with concurrency, but I don't see how this would be handled 
> > differently than by using Futures, internally ? (at least for this case)
> >
>
> It looks/behaves very similar to futures, but would potentially be 
> implemented differently.  The main difference is that the resulting type is 
> actually the desired type (instead of Future) with a compiler flag 
> saying that it needs to call await to be used.  Behind the scenes, this could 
> be implemented as some sort of future, but the compiler has a lot more 
> freedom to rearrange things to be much more efficient because there is no 
> affordance for the user to introspect or cancel. So for example, it might 
> actually change:
>
> let image = async downloadImage()
> let size = await image.size
>
> to:
>
> let size = await downloadImage().size
>
> This would depend on the other code around it, but the compiler has much more 
> freedom to avoid creating intermediate values, or even to create different 
> types of intermediate values which are more efficient for the situation at 
> hand.
>
> Given that as a base, it would be trivial to create a framework offering true 
> Futures (which allow cancelling, etc…)
>
> Thanks,
> Jon
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] New async keyword usage

[Florent Vilmart via swift-evolution]

On 25 août 2017 18:31 -0400, Jonathan Hull , wrote:
> But then it would need to be called with await under the current proposal, 
> meaning that either:
>
> • b would await the calculation of a
>
> beginAsync {
> let a = await longCalculationA()
> let b = await longCalculationB() //This only calculates when a is finished
> }
why would it? the async modifier could very well be used to transform a sync 
function into an async one, dispatching on a defined queue returning the 
'Future' and resolving once the function completes.

I'm not sure why it's understood as all or nothing, AFAICU, await is just a way 
to block the current queue and wait for a result from an async function.
beginAsync is a way to make sure we don't block the current execution queue.

something like

let a = await async longSynchrounousCall() would block the current execution 
queue (because await) but the execution of the longSynchronousCall() would be 
on a separate queue / block.

The question lays more in where the calls are executed, either they are 
dispatched after, current block is suspended, runloop continues, and then the 
block is re-entered upon returning.  that would lead to some weird executions 
flows.

>
> • or b would be executed while a is awaiting, but a and b would be in 
> different scopes
>
> beginAsync{
> let a = await longCalculationA()
> }
> beginAsync{
> let b = await longCalculationB() //We can’t see ‘a’ anymore
> }
> //We can’t see ‘a’ or ‘b’ here to use them
>
> We could, also implement some sort of future, and then re-write our functions 
> to take advantage of it, but this misses out on numerous compiler 
> optimizations and requires our functions to be written with futures in mind.  
> In my example, the functions can just be written as async, and they don’t 
> care whether they are called with async or await.
>
> Thanks,
> Jon
>
> > On Aug 25, 2017, at 3:13 PM, Florent Vilmart  wrote:
> >
> > be doesn't wait if it's defined as
> >
> > func longCalculationB() async -> SomeType
> >
> > which would be helpful if it's a long calculation,
> >
> > in the case it's
> >
> > func longCalculationB() -> SomeType
> >
> > That would probably be valid to put the async keyword front even though I 
> > would not be a big fan of that as you'd be executing on an indefinite queue 
> > a calculation that may not be thread safe.
> >
> > async would be in that case a wrapper around dispatch_async  + semaphore
> >
> >
> > On 25 août 2017 18:08 -0400, Jonathan Hull , wrote:
> > > Why wouldn’t b wait for a in this example?  If it is using futures, those 
> > > aren’t available in the current proposal.
> > >
> > > > On Aug 25, 2017, at 3:02 PM, Florent Vilmart  
> > > > wrote:
> > > >
> > > > Probably with:
> > > >
> > > > let a = longCalculationA()
> > > > let b = longCalculationB() //b doesn’t wait for a to complete before 
> > > > starting
> > > > let c = longCalculationC() //c doesn’t wait for a or b
> > > > let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits 
> > > > until a, b, and c are all available
> > > >
> > > > On 25 août 2017 17:48 -0400, wrote:
> > > > >
> > > > > let a = async longCalculationA()
> > > > > let b = async longCalculationB() //b doesn’t wait for a to complete 
> > > > > before starting
> > > > > let c = async longCalculationC() //c doesn’t wait for a or b
> > > > > let result = await combineCalculations(a: a, b: b, c: c) //waits 
> > > > > until a, b, and c are all available
> > >
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] New async keyword usage

[Florent Vilmart via swift-evolution]

be doesn't wait if it's defined as

func longCalculationB() async -> SomeType

which would be helpful if it's a long calculation,

in the case it's

func longCalculationB() -> SomeType

That would probably be valid to put the async keyword front even though I would 
not be a big fan of that as you'd be executing on an indefinite queue a 
calculation that may not be thread safe.

async would be in that case a wrapper around dispatch_async  + semaphore


On 25 août 2017 18:08 -0400, Jonathan Hull , wrote:
> Why wouldn’t b wait for a in this example?  If it is using futures, those 
> aren’t available in the current proposal.
>
> > On Aug 25, 2017, at 3:02 PM, Florent Vilmart  wrote:
> >
> > Probably with:
> >
> > let a = longCalculationA()
> > let b = longCalculationB() //b doesn’t wait for a to complete before 
> > starting
> > let c = longCalculationC() //c doesn’t wait for a or b
> > let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits 
> > until a, b, and c are all available
> >
> > On 25 août 2017 17:48 -0400, wrote:
> > >
> > > let a = async longCalculationA()
> > > let b = async longCalculationB() //b doesn’t wait for a to complete 
> > > before starting
> > > let c = async longCalculationC() //c doesn’t wait for a or b
> > > let result = await combineCalculations(a: a, b: b, c: c) //waits until a, 
> > > b, and c are all available
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] New async keyword usage

[Florent Vilmart via swift-evolution]

Probably with:

let a = longCalculationA()
let b = longCalculationB() //b doesn’t wait for a to complete before starting
let c = longCalculationC() //c doesn’t wait for a or b
let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits until 
a, b, and c are all available

On 25 août 2017 17:48 -0400, wrote:
>
> let a = async longCalculationA()
> let b = async longCalculationB() //b doesn’t wait for a to complete before 
> starting
> let c = async longCalculationC() //c doesn’t wait for a or b
> let result = await combineCalculations(a: a, b: b, c: c) //waits until a, b, 
> and c are all available
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Florent Vilmart via swift-evolution]

I'm really not sold about the ~> operator, as it would be easy to miss. Swift 
is known and loved for the expressiveness of the language, using that operator 
doesn't help with that.

On another hand, I agree that this is the sexiest, less intrusive solution.

On 17 févr. 2017 13:36 -0500, Adrian Zubarev via swift-evolution 
, wrote:
> My suggestion is that -> would be the conditional arrow that can be both pure 
> or impure. That would make @pure func foo(_ f: @pure (Int) -> Int) -> Int 
> equivalent to func foo(_ f: (Int) ~> Int) -> Int. Plus depending on the 
> implementation the compiler might be able to help and tell you that foo could 
> use ~> instead.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 19:25:41, Anton Zhilin (antonyzhi...@gmail.com) 
> schrieb:
> > Just let
> >
> > @pure func foo(_ f: (Int) -> Int) -> Int
> >
> > be the same as those two combined:
> >
> > @pure func foo(_ f: @pure (Int) -> Int) -> Int
> > func foo(_ f: (Int) -> Int) -> Int
> >
> > No need for anything like “re-pure” or ≃>.
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Florent Vilmart via swift-evolution]

Another usecase would be for the type aliases:

typealias PureFunc = pure (Some)->Else

Or

pure typealias PureFunc = (Some)->Else

I'm not sure where the keyword should stand

On Feb 17, 2017, 12:03 PM -0500, Matthew Johnson via swift-evolution 
, wrote:
>
> > On Feb 17, 2017, at 10:55 AM, David Sweeris  > (mailto:daveswee...@mac.com)> wrote:
> >
> > On Feb 17, 2017, at 08:49, Matthew Johnson  > (mailto:matt...@anandabits.com)> wrote:
> >
> > >
> > > > On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution 
> > > >  wrote:
> > > >
> > > > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution 
> > > >  wrote:
> > > >
> > > > >
> > > > > I haven’t yet read all the feedback in this topic but I’d like to 
> > > > > throw some bikeshedding of mine into the room. :)
> > > > >
> > > > >
> > > > > How about this?
> > > > >
> > > > > Version 1: func(pure) …
> > > > > Version 2: func label(…) ~> ReturnType
> > > > >
> > > > >
> > > > >
> > > >
> > > > Version 2 is going to upset those who use "~>" as an operator.
> > > >
> > > > As the # of possible attributes grows, having an obvious grouping 
> > > > mechanism for them, like version 1, might be worthwhile simply to help 
> > > > make the list clearer. What about allowing "@(list, of, attributes)" 
> > > > instead of "@list, @of, @attributes”?
> > >
> > > That would be a little bit awkward for attributes that are parameterized.
> >
> > Are there any parameterized attributes other than "@inline(always|never)”?
>
> I am not sure, but there has been discussion of introducing them. For 
> example, regardless of what syntax we choose for indicating a public enum is 
> closed it will need to have an optional parameter indicating the first 
> version of the library in which it was closed (which can be omitted if it was 
> closed the first time it appeared). One option for indicating this is to use 
> an attribute.
> >
> > > And if we did do this we should allow the parens to be omitted when there 
> > > is only one attribute.
> > Agreed.
> >
> > - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Florent Vilmart via swift-evolution]

We could do:

pure let closure = { _-> Else in }

But given the scope capturing nature of closures I was actually wondering if 
this 'purity' should be applied to closures.

After all an inline defined func would do.

On Feb 17, 2017, 11:59 AM -0500, Matthew Johnson , 
wrote:
> How do you suggest a closure indicate its purity? Something like this?
>
> { pure in $0.property }
>
> > On Feb 17, 2017, at 10:57 AM, Florent Vilmart  > (mailto:flor...@flovilmart.com)> wrote:
> > We were discussing the topic yesterday with others and some suggested 
> > adding a pure keyword, for improved readability, just before the function 
> > declaration:
> >
> > Ex:
> >
> > pure func(a:Some) -> Else {}
> >
> >
> >
> > On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution 
> > , wrote:
> > >
> > > > On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution 
> > > >  wrote:
> > > >
> > > > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution 
> > > >  wrote:
> > > >
> > > > >
> > > > > I haven’t yet read all the feedback in this topic but I’d like to 
> > > > > throw some bikeshedding of mine into the room. :)
> > > > >
> > > > >
> > > > > How about this?
> > > > >
> > > > > Version 1: func(pure) …
> > > > > Version 2: func label(…) ~> ReturnType
> > > > >
> > > > >
> > > > >
> > > >
> > > > Version 2 is going to upset those who use "~>" as an operator.
> > > >
> > > > As the # of possible attributes grows, having an obvious grouping 
> > > > mechanism for them, like version 1, might be worthwhile simply to help 
> > > > make the list clearer. What about allowing "@(list, of, attributes)" 
> > > > instead of "@list, @of, @attributes”?
> > >
> > > That would be a little bit awkward for attributes that are parameterized. 
> > > And if we did do this we should allow the parens to be omitted when there 
> > > is only one attribute.
> > > >
> > > > - Dave Sweeris ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Florent Vilmart via swift-evolution]

We were discussing the topic yesterday with others and some suggested adding a 
pure keyword, for improved readability, just before the function declaration:

Ex:

pure func(a:Some) -> Else {}

On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution 
, wrote:
>
> > On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution 
> >  wrote:
> >
> > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution 
> >  wrote:
> >
> > >
> > > I haven’t yet read all the feedback in this topic but I’d like to throw 
> > > some bikeshedding of mine into the room. :)
> > >
> > >
> > > How about this?
> > >
> > > Version 1: func(pure) …
> > > Version 2: func label(…) ~> ReturnType
> > >
> > >
> > >
> >
> > Version 2 is going to upset those who use "~>" as an operator.
> >
> > As the # of possible attributes grows, having an obvious grouping mechanism 
> > for them, like version 1, might be worthwhile simply to help make the list 
> > clearer. What about allowing "@(list, of, attributes)" instead of "@list, 
> > @of, @attributes”?
>
> That would be a little bit awkward for attributes that are parameterized. And 
> if we did do this we should allow the parens to be omitted when there is only 
> one attribute.
> >
> > - Dave Sweeris ___
> > swift-evolution mailing list
> > swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Florent Vilmart via swift-evolution]

>From what I see, talking about Fields, Rings, vector spaces etc... we're 
>talking about modeling the standard library upon mathematic models / axioms 
>(particularly algebra) and using the same terminology.

Those constructions allow for a more flexible approach as one would be able to 
'code theorems' on the top of the std library based on their mathematical 
definitions, instead of their CS oriented definitions.

That's overly abstract, incredible low level and insanely powerful at the same 
time.

Still it's an interesting concept of modeling the 'algebra' based upon those 
abstract structures, even if I believe the real world examples of usage would 
be thin.

On Jan 16, 2017, 9:26 PM -0500, Jay Abbott via swift-evolution 
, wrote:
> I barely understand any of this thread, so these might be silly questions, or 
> based on a total misunderstanding the goals here, but it seems to be about: 
> a) clever/advanced mathsy things; b) naming things; and c) the standard 
> library... my questions are:
>
> Do specialised clever advanced mathsy libraries all work exactly the same, or 
> do they have slightly different behaviours or conventions or semantics in 
> different fields of study?
>
> Is the the goal here to define a common/shared sub-set of specialised maths 
> libraries, but in the standard library? Would that be useful by itself?
>
> Could it be possible that "naming things" in the standard library would 
> trample all over possible uses in external libraries, making it harder rather 
> than easier for specialised maths libraries to construct their interfaces in 
> a non-confusing way?
>
>
> On Tue, 17 Jan 2017 at 01:39 Dave Abrahams via swift-evolution 
>  wrote:
> >
> > on Mon Jan 16 2017, Xiaodi Wu  > (mailto:swift-evolution@swift.org)> wrote:
> >
> > > Strideable? I didn't think Strideable itself was going away. I'd be sad if
> > > it did; for one, all the Unsafe*Pointers are Strideable and that has its
> > > uses.
> >
> > Nobody's proposing to remove Strideable.
> >
> > --
> > -Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] guard let x = x

[Florent Vilmart via swift-evolution]

It seems that we settle on a relatively 'long' keyword 'unwrap', 
Did we consider a ? prefix operator?

As we use the ? postfix in order to safely unpack, we could as well introduce 
prefix ?

guard ?foo, ?bar else { return }

It is 'expressive', and makes me think 'do I have?'. 

It is less technically / semantically correct than unwrap, but also gives a 
playful twist, making those guard/if condition lines more concise.

it would play correctly decently with:

guard var ?foo, var ?bar else { return }


-- 
Florent Vilmart

Le 1 novembre 2016 à 19:08:11, ilya via swift-evolution 
(swift-evolution@swift.org) a écrit:

> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }

I would argue for
c) guard let reallyFoobar = foobar else { … }

(or perhaps guard let foobar_ = foobar else { … } )

That way one can use both an optional foobar and non-optional "unwrapped value 
of foobar at the moment of guard" without any possibility of mixing those two 
(and without violating DRY).

Ilya.

On Wed, Oct 26, 2016 at 6:38 PM Chris Lattner via swift-evolution 
 wrote:
On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution 
 wrote:
On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution 
 wrote:

Hey all,

As usual, apologies if this horse was beaten ages ago before I joined the 
mailing list, but thought I would bring this up.

Yes, this has thoroughly been beaten to death.  It is also outside the scope of 
Swift 4 stage 1.  That said, it is such a glaring problem that we’ll have to 
deal with it at some point.

I was typing the above (for the hundredth time) the other day and I was 
wondering whether it might be worth considering offering a shorter syntax:

guard let x, y, z else {…}

This specific syntax is commonly requested.  The problem with this is that it 
provides no useful information about what is actually going on: it sacrifices 
clarity to get terseness, a specific non-goal of Swift.


Erica says:
Your initial suggestion doesn't work as overloading "let" confuses rather than 
clarifies this process. In February, I brought up `bind x` to mean 
"conditionally bind x to x, and produce a conditional fail if that's not 
possible", with the hope that "bind self" could be used in closures. Under that 
scheme your example would read:

guard bind x, bind y, bind z else { … }

To me, this is the most promising direction, but I’d suggest the use of 
“unwrap" as the keyword.  If you compare these two:

a) guard let foobar = foobar else { … }
b) guard unwrap foobar else { … }

I think that b) wins by virtue of eliminating repetition ("foobar = foobar" 
fails DRY principles), but retains clarity by introducing a word into the 
grammar that people already commonly know and use, and which is googlable if 
they don’t.

This also gives us the conceptual hook to make the “unwrapping an optional” 
behavior (which occurs with if let, optional chaining, etc) be something that 
could be extended to other similar user defined types, such as a Result type.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Promises, Futures and the death of the callback hell

[Florent Vilmart via swift-evolution]

I promise I'll spec some things out before Spring if this is something we want 
part of the language. I don't want it to have a sub-par implementation like 
Nodejs and forcing devs to monkey patch with Bluebird-Swift of so...

-- 
Florent Vilmart

Le 31 octobre 2016 à 11:52:57, Xiaodi Wu (xiaodi...@gmail.com) a écrit:

It's not up to me to promise anything :P
On Mon, Oct 31, 2016 at 07:29 Jeremy Pereira  
wrote:

> On 29 Oct 2016, at 01:47, Xiaodi Wu via swift-evolution 
>  wrote:
>
> Async and related topics are deferred until the spring; I would imagine 
> promises fall into the same basket.

So you are promising that we will discuss futures and promises in the future…




signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Promises, Futures and the death of the callback hell

[Florent Vilmart via swift-evolution]

Has this subject been already addressed? Is it worth considering here?

I searched the repo for Futures and Promises, and it seems that no proposal has 
been opened yet.

F.

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution