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

There are fields where there is no swift culture at all, or barely none, for example on the server side. I don’t want to see « swift-django » winning this battle. I like compile-type safety, because i know that in the long term it makes my code more manageable. But in some cases it’s hard to

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

Is there another proposal directly related to namespacing ? This would seem like addressing a bit of the same issue.. As an example i would much prefer writing something like : Package UITableView Class Table : UIView Class Cell : UIView Protocol Delegate Protocol Datasource With each class in

Re: [swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

> Le 18 nov. 2017 à 23:47, Xiaodi Wu a écrit : > >> On Sat, Nov 18, 2017 at 16:25 Benjamin G >> wrote: >> I think because it's not immediately obvious with multiple if statement, >> that they all try to compare the same expression to

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Le 16 oct. 2017 à 07:20, Xiaodi Wu via swift-evolution > a écrit : > >> On Sun, Oct 15, 2017 at 11:57 PM, Thorsten Seitz wrote: >> >> >>> Am 16.10.2017 um 00:41 schrieb Xiaodi Wu via swift-evolution >>> : >>>

Re: [swift-evolution] Swift and actors

I have the feeling concurrency and asynchrony related features are going to have vastly different requirements and typical use case on a mobile app and on a server. If you take something like reactive programming , they're quite suited to the http request / response lifecycle where your state

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

> Le 24 sept. 2017 à 21:15, Marc Schlichte via swift-evolution > a écrit : > > I hope we come up with some genuine ideas for ReactiveStreams on Swift. > > For example instead of onNext()/onError() we could have a single method which > takes a Result Monad. ARC

Re: [swift-evolution] Different types for getter and setter

Seeing this proposal for the first time and the previous messages in that thread makes me wonder : is making extensive use of getters and setters an encouraged coding style in swift ? In every language that has them, i tend to keep their use to the strict minimum, because i find that 1/

Re: [swift-evolution] [Concurrency] Theoretical question about actors vs async

://hexdocs.pm/elixir/Task.html just in case. > Le 18 sept. 2017 à 18:15, Pierre Habouzit <phabou...@apple.com> a écrit : > >> On Sep 18, 2017, at 2:32 AM, Benjamin Garrigues via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >

Re: [swift-evolution] [Concurrency] Theoretical question about actors vs async

> Le 18 sept. 2017 à 07:59, Pierre Habouzit a écrit : > >> On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution >> wrote: >> >> I've read Chris Lattner proposal on concurrency, and if i'm correct, the >> proposal is to start

[swift-evolution] Async vs Actor

Hi, not a compiler developer in any way, but i recently had the opportunity to experiment with this pattern in go (thanks to https://www.youtube.com/watch?v=yCbon_9yGVs). It seems by reading the threads that the idea of mixing actor with async, or actor with callbacks raises a lot of question