Re: [swift-evolution] [Pitch] Generalized supertype constraints

You’re right, I misunderstood that paragraph (maybe I read what I wanted to read :D). Thank you very much for the clarification and I’ll take a closer look at your proposal tomorrow! - Dennis Sent from my iPhone > On 25. Nov 2017, at 10:37 PM, Adrian Zubarev >

Re: [swift-evolution] [Pitch] Generalized supertype constraints

I would also love to have generic associated types in the language, I have a lot of uses for them and, IIUC, supertype constraint would enable me to express the following: protocol Service {} protocol WikiService: Service {} // methods not shown for conciseness class DefaultWikiService:

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

I think discovering them is not the problem, the question is if you really want them to be annotated pro-actively by the compiler - I don't think so. Your comparison with @escape is both right and wrong :) It's wrong in the sense that @escaping is a relaxing attribute while @pure is a

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

> On Feb 16, 2017, at 10:24 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Secondly, are they inherited? So if ClassA has a pure fu

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

Big +1 from me for the concept, thanks for proposing this, here's some "but"'s that came to my mind after a quick read: I don't quite like the introduction of a new function arrow, in the end (in my opinion) this is just a more special, more constrained version of a normal function. For me,

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I'm also +1 on this, wanted this for a long time :) - Dennis > On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution > wrote: > > Great, thanks. Love it :) > > +1 > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Februar 2017 um 14:39:43,

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

> I like the idea of allowing destructuring everywhere we bind a name very > much. My only (minor) concern with doing this for tuples right now is that > it might encourage overuse of them where a struct would be a better choice. > > I have been thinking about destructuring of structs and

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

re if the proposed feature is adding important improvement to the > language. > > On 30.05.2016 0:20, Dennis Weissmann via swift-evolution wrote: >> Thanks for everyone participating in this discussion! :) >> I’ve drafted a formal proposal, it is available >> here: >> https

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

Hi Brent, Thanks! Those are great points! I haven’t thought about the possibility of suppressing the external label. I like your option 2 very much! I’ll add it to the proposal and change the used variable names. - Dennis > On May 30, 2016, at 3:01 PM, Brent Royal-Gordon

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

e following statement is but > strictly speaking (at least for me) (valueA: String, valueB: String) is not > of the same type as (String, String) just like func d(string: String, int: > Int) is different from func e(_: String, _: Int) though in Swift the tuples > are inte

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+ 1 from me as well for the already stated reasons. - Dennis > On May 28, 2016, at 2:15 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Awesome! :) You are too fast to follow up! - Dennis Sent from my iPhone > On May 13, 2016, at 7:02 AM, Chris Lattner <clatt...@apple.com> wrote: > > On May 12, 2016, at 12:59 AM, Dennis Weissmann via swift-evolution > <swift-evolution@swift.org> wrote: >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

- Dennis > On May 12, 2016, at 9:34 AM, Pierre Habouzit <phabou...@apple.com> wrote: > >> On May 11, 2016, at 9:02 AM, Dennis Weissmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 1. What i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

1. What is your evaluation of the proposal? +1 I think this is a big win for readability. 2. Is the problem being addressed significant enough to warrant a change to Swift? Yes. dispatch is used nearly everywhere so many many projects would benefit from it. 3. Does this proposal fit well with

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

ike func d(string: String, int: Int) is different from func e(_: String, _: Int) though in Swift the tuples are interchangeable (you can pass one where the other is expected). > On May 8, 2016, at 6:10 PM, Geordie J <geo...@gmail.com> wrote: > > Comments below > >> Am

Re: [swift-evolution] [swift-corelibs-dev] Change in String.CharacterView.Index?

Hey Joe, The collection index model changed: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md You now need to ask the collection for the next index: let a = “Hello, World" let secondIndex = a.characters.index(after: a.characters.startIndex)

[swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

Following a short discussion with positive feedback on [swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812) I’d like to discuss the following: Tuples should be destructible into their components in parameter lists. Consider the following code: let a = [0,1,2,3,4,5,6,7,8,9]

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Sorry for my absence. > Increment/decrement operators, currying, tuple splat and even the C-style for > loop have already been deprecated, and although I would have preferred to > keep some of those constructs, I think it is good how progressive Swift is > pushed forward ("would we add this

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

- Dennis > On Apr 18, 2016, at 9:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I would like to see format strings go away and be replace with safer inline >> annotations. > > The main problem is doing localized strings with printf-style formats well,

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

hink it would make the language clearer and more consistent if varargs were removed. - Dennis > On Apr 18, 2016, at 9:48 AM, Gwendal Roué <gwendal.r...@gmail.com> wrote: > > >> Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution >> <swift-evolution@swift.org>

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > [offtopic for "A New Model for Collections and Indices"] > > Just wanted to add my 2 cents to this new naming guidelines proposal that > @Dave pointed to: > "Update API Naming Guidelines and