Re: [swift-evolution] [Pitch] Angle Type

> On 15. Jan 2018, at 23:55, Taylor Swift wrote: > > > > On Jan 15, 2018, at 3:30 PM, Karl Wagner > wrote: > >> >> >>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >>>

Re: [swift-evolution] [Pitch] Angle Type

> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution > wrote: > > This could work, but you’re also giving up all the nice Numeric and > FloatingPoint conformances when you use this,, all of a sudden adding two > angles together isn’t let γ = α + β, it’s γ =

Re: [swift-evolution] [Pitch] Angle Type

> On 14. Jan 2018, at 06:04, BJ Homer via swift-evolution > wrote: > > An Angle type already exists in Foundation; see Measurement. You > could add some convenience methods in an extension pretty easily. > > import Foundation > > typealias Angle = Measurement >

Re: [swift-evolution] [Pitch] Angle Type

> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution > wrote: > > I do a lot of geometry and spherical-related work and i have never found an > Angle type to be worth having. Always use radians. It’s what sin() and cos() > take, it’s what graphics APIs

Re: [swift-evolution] [pitch] adding toggle to Bool

> On 12. Jan 2018, at 20:54, Alejandro Martinez via swift-evolution > wrote: > > I wouldn't go as far as to ask to fade out ! but in all my code I end > up doing == false just for readability. That ! knows who to hide > himself too well :P > Yeah so do I. ! is a

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On 13. Jan 2018, at 03:22, Connor Wakamo via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 11:51 PM, Chris Lattner > > wrote: >> >> On Jan 11, 2018, at 11:22 AM, Connor Wakamo >

Re: [swift-evolution] [Proposal] Random Unification

> On 13. Jan 2018, at 05:23, Nate Cook via swift-evolution > wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > > wrote: > >> I think we have different definitions of

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > +1. Yes please. Long overdue. > >> Is the problem being addressed significant enough to warrant a change to >> Swift? > > It’s a

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

> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution > wrote: > > There exists in the standard library a type `DictionaryLiteral` that deserves > naming re-consideration before we declare ABI Stability, because it’s > confusingly misnamed, being neither a

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On 7. Jan 2018, at 18:47, Robert Widmann <devteam.cod...@gmail.com> wrote: > > > > ~Robert Widmann > > 2017/12/31 11:02、Karl Wagner via swift-evolution <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>>のメール: > >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On 5. Jan 2018, at 15:52, Swift via swift-evolution > wrote: > > Hi Jordan, > > Thanks for your thoughtful reply. Comments inline... > > Sent from my iPad > > On Jan 4, 2018, at 5:37 PM, Jordan Rose >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On 3. Jan 2018, at 18:49, Dave DeLong via swift-evolution > wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution

Re: [swift-evolution] [swift-dev] Make offset index available for String

And really, this is more an issue for swift-evolution, since what you’re talking about (self-incrementing indexes) would be a new language feature. - Karl > On 3. Jan 2018, at 01:19, Karl Wagner wrote: > > Swift used to do this, but we switched it around so indexes

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 2. Jan 2018, at 16:38, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 1, 2018, at 11:47 PM, Chris Lattner > wrote: > >>> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution > wrote: > > Sorry for the delay. I've just updated the proposal text to incorporate > various changes, some contributed by others. > >

Re: [swift-evolution] namespacing protocols to other types

: P where T == Self.T } Anyway, I thought that was not on the table, and in any case I’m convinced that it should be a separate proposal. This gets to the heart of the interaction between generic types and protocols, and we all know it’s not always a smooth transition (hello AnyCollection, AnyHashable,

Re: [swift-evolution] namespacing protocols to other types

Yeah I wrote that proposal. I eventually stripped it down to just disallow all capturing, but it was still not selected by the core team for review ¯\_(ツ)_/¯ As for capturing semantics, once you start working through use-cases, it’s becomes clear that it's going to require generalised

Re: [swift-evolution] [Pitch] @static imports

k with a module compiled to allow static imports. It just wouldn’t _require_ it (and wouldn’t allow you to assume the module is a fixed version). - Karl > > Slava > >> On Dec 20, 2017, at 6:56 AM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:s

[swift-evolution] [Pitch] @static imports

There’s a lot of talk in the non-exhaustive enum discussion about the source transition. So let me suggest a possible solution: @static imports. Basically, it seems to me like resilience is going to introduce a lot of indirection, both in generated instructions and in the language. I think that

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 20. Dec 2017, at 14:36, Karl Wagner wrote: > > > >> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution >> > wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

Personally, I think this dovetails quite nicely with the ‘random’ discussion. Enums are just one kind of type with a finite set of values; Int and Bool also fit that description, as may many structs and even classes. Having a general way to express that would be quite nice, IMO. - Karl > On

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

7, at 19:39, Ben Cohen via swift-evolution > <swift-evolution@swift.org> wrote: > > They will continue to conform to Collection just as they do today. > Range.IndexDistance is already an Int. > >> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution >&

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

What does this mean for ranges of integers, as Xiaodi mentioned in the review thread? Can they still conform to Collection? I think we really need clarification on that aspect. Personally, I would consider it a deal-breaker. - Karl > On 4. Dec 2017, at 18:57, Douglas Gregor via

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

> > I believe that adding explicit syntax would be counterproductive to your > goals, and would not make dynamic lookup syntax more clear. I assume that > you would also want the same thing for DynamicCallable too, and operator > overloads, subscripts, and every other operation you perform on

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

> On 1. Dec 2017, at 07:05, Chris Lattner via swift-evolution > wrote: > > Hi Doug, > > Thank you for the detailed email. I have been traveling today, so I haven’t > had a chance to respond until now. I haven’t read the down-thread emails, so > I apologize if

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

> On 30. Nov 2017, at 09:24, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> > wrote: >> >> I’d like to formally propose the

Re: [swift-evolution] [Proposal] Random Unification

> On 28. Nov 2017, at 00:20, Martin Waitz via swift-evolution > wrote: > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like `choose(in:)`? >> >> let diceRoll = random.choose(in: 1...6)

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

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > >

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

I think this is essential for creating good, general-purpose abstractions with Swift. For example, currently I have a protocol which models a CRUD database. There is some ORM behaviour which translates the DB information in to model objects, but of course, each database might have different

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

> On 22. Nov 2017, at 07:51, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > We’re having a bit of a debate > over the question of whether SE-0143 “Conditional Conformances” >

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

> On 13. Nov 2017, at 05:11, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of

Re: [swift-evolution] Abstract methods

I think there is a legitimate hole around abstract methods. I don’t think it really matters whether you’re talking about a class hierarchy or a protocol hierarchy. They’re both providing partial implementations of behaviour, predicated on some other method being implemented. The practical

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

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution > > wrote: > > FWIW, Ben Cohen and I have been talking about possibly using Swift packages > as a way to seed out experimental ideas for extensions to the Standard >

Re: [swift-evolution] [SPM] Roadmap?

> On 28. Oct 2017, at 15:26, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > > Now, I want to localise my package - what do I do? I’m going to have to > create some middleware to translate platform-specific concepts in to a > baselin

Re: [swift-evolution] [SPM] Roadmap?

> On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution > wrote: > > Hi, > > Is there any news about features that are willling to be integrated into SPM > 5? > Those I see the most relevant: > - iOS support > - Some kind of configuration/settings

Re: [swift-evolution] [draft] Target environment platform condition

> On 26. Oct 2017, at 17:13, Dave DeLong via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] [draft] Target environment platform condition

that ideally should not exist in a simulator, > but unfortunately such cases do exist. > > (This was at least true in iOS 9, and I haven’t seen any indication that it > has changed.) > > -BJ > > On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution > <swift-e

Re: [swift-evolution] [draft] Target environment platform condition

I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition. - Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option). - Does your platform’s

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25. Oct 2017, at 13:41, David Hart via swift-evolution > wrote: > > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find

Re: [swift-evolution] Re-initialization of lazy variables?

> On 6. Oct 2017, at 14:49, Spencer Kohan via swift-evolution > wrote: > > Hi all, > > In migrating to swift 4 I've noticed one thing which has changed is there is > no longer support for the automatic re-initialization of lazy variables. > > In swift 3 I could

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On 29. Sep 2017, at 02:59, Andrew Trick via swift-evolution > wrote: > > >> On Sep 6, 2017, at 10:15 PM, Taylor Swift > > wrote: >> >> okay so I think so far what’s been agreed on is >> >> 1. rename “Bytes”

Re: [swift-evolution] Enums and Source Compatibility

> On 29. Sep 2017, at 00:24, Dave DeLong via swift-evolution > wrote: > > I also realize that this may be an impractical approach to solving this > problem, because it would require teaching the analyzer about built products, > with knowledge of what’s going to be

Re: [swift-evolution] [Discussion] Resources

> On 27. Sep 2017, at 12:32, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On 25. Sep 2017, at 18:54, Rick Ballard via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi Karl and Keit

Re: [swift-evolution] [Discussion] Resources

t;> -- >> Keith Smiley >> >> On 09/22, Taylor Swift via swift-evolution wrote: >>> I have never once felt a need to distribute a library with an icon >>> >>> On Fri, Sep 22, 2017 at 10:43 AM, Karl Wagner via swift-evolution < >>> swi

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Yeah, IMO it’s fair to add this function. I also think we should have a way of removing elements at multiple indexes (e.g. from a generic sequence of indexes). That’s something that naïve programmers are more likely to get wrong. - Karl > On 26. Sep 2017, at 06:27, Félix Cloutier via

Re: [swift-evolution] Enums and Source Compatibility

Yes, it’s binary compatiblity (ABI). And yes, you’re right that inlineable code is especially fragile to changes made in later versions of the library. See: https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#inlineable-code > > On

Re: [swift-evolution] [Discussion] Resources

> On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi everybody! > > I’m really happy that Swift 4 is out, and it’s great that there’s already so > much active discussion about Swift 5 (concurrency, etc). I find I’

Re: [swift-evolution] Enums and Source Compatibility

> On 22. Sep 2017, at 17:21, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On 21. Sep 2017, at 00:51, Rex Fenley via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Enums and Source Compatibility

> On 21. Sep 2017, at 00:51, Rex Fenley via swift-evolution > wrote: > > Hi Jordan, > > I've been keeping up with most of the discussion since I last emailed about > my concern about making nonexhaustive the default mode for enums. So far I am > still strongly in

[swift-evolution] [Discussion] Resources

Hi everybody! I’m really happy that Swift 4 is out, and it’s great that there’s already so much active discussion about Swift 5 (concurrency, etc). I find I’m running in to language roadblocks less and less, and the improvements to the generics system have really improved a lot of my code.

Re: [swift-evolution] typed throws

> On 18. Aug 2017, at 08:27, John McCall via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 6. Aug 2017, at 17:15, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > let newItems_heap = newItems.backing.isAllocatedInline ? > newItems(withBacking: newItems.backing.clone()) : newItems Should, of course, b

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> Actually, if you do a lot of graphics programming like I do, the memory > layout is very, very important. Swift may not care about layout, but many > APIs that it interacts with do. > Sure; I’m well-aware of how important it can be to decide on an appropriate memory layout. I’m very much

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wr

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

>> >> The root cause, of course, is that the VLAs require new stack allocations >> each time, and the stack is only deallocated as one lump when the frame ends. > > That is true of alloca(), but not of VLAs. VLAs are freed when they go out > of scope. > Learned something today. Anyway, if

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

5319411988, >-0.41637437, > 0.99914771 > ] > { > y = x2 * y + c > } > return y > } > > On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On 3. Aug 2017, at 07:26, John McCall <rjmcc...@apple.com> wrote: > >> On Aug 3, 2017, at 12:45 AM, Daryle Walker <dary...@mac.com >> <mailto:dary...@mac.com>> wrote: >>> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >>&

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On 3. Aug 2017, at 00:43, Xiaodi Wu via swift-evolution > wrote: > > > On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans > wrote: > I think that the items mentioned earlier in the list (just reminded below)

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 3. Aug 2017, at 00:21, John McCall wrote: > > >> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution >> > wrote: >> >>> On Aug 2, 2017, at 5:56 PM, Karl Wagner >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On 31. Jul 2017, at 21:09, John McCall via swift-evolution > wrote: > >> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> wrote: >>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>> wrote:

Re: [swift-evolution] [Pitch] New Version of Array Proposal

I’m -1 on adding a fixed-sized Array type. It goes back to something which I remember reading from John McCall earlier this week but can’t find any more: about tuple indices being nominal and not ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal? The difference

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

Any/AnyObject are constraints for an existential container. Protocol conformances are also existential constraints, but not quite the same thing as Any/AnyObject. Rather than adding negative constraints, I think we need a richer set of more specific positive constraints.

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

Indeed. I think something that is missing from the generics manifesto is that we need more type constraints. Value/reference semantics is one badly-needed distinction, but there are others, too (e.g. trivial types). There are lots of generic structures and algorithms which

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On 12. Jul 2017, at 22:21, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 11 2017, Robert Bennett wrote: > >> Just realized that even inout functions don’t let you do >> member(object) = value. > > The other difference is that an inout function

Re: [swift-evolution] [Pitch] BitPatternRepresentable

> On 16. Jul 2017, at 16:26, Dave Abrahams via swift-evolution > wrote: > > > on Sun Jul 16 2017, Jens Persson wrote: > >> On Wed, Jul 12, 2017 at 12:23 AM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>>

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On 12. Jul 2017, at 01:20, Robert Bennett wrote: > > Well, if they really are first-class deferred method calls or member > accesses, then do seem pretty function-y after all. Then again, if they were > meant to be functions, it seems like their design would reflect

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

> On 11. Jul 2017, at 17:41, Wallacy via swift-evolution > wrote: > > When will be a good time to discuss this proposal again? I think Apple's usual policy is that Swift 4 will ship with iOS 11 (so end of September, I think). Then they have a break, and sometime

Re: [swift-evolution] [Pre-pitch] Allowing enums inside protocols?

> On 9. Jul 2017, at 06:06, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull > wrote: > Do you know why it was never brought to a vote? > > If I had to guess, it would be because

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On 11. Jul 2017, at 21:01, Robert Bennett via swift-evolution > wrote: > > In general, I like the idea of making ordinary types callable (although > curried functions already accomplish this to some extent), but I hesitate to > bring this capability to keypaths

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

I agree that it should be completely implicit. KeyPaths are simply chains of partially-applied properties and subscripts. At the same time, it was noted in the KeyPath proposal that a similar mechanism might be used to model chains of partially-applied functions. I think that

Re: [swift-evolution] [Pitch] `let` in protocols

> On 26. Jun 2017, at 13:44, Karl Wagner wrote: > > >> On 25. Jun 2017, at 22:13, Robert Bennett wrote: >> >> For a concrete type, a partial initializer is a function that: >> Can set `let` instance variables >> May not refer to `self` in an rvalue

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

> On 23. Jun 2017, at 02:59, Kevin Ballard via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md > >

Re: [swift-evolution] [Pitch] `let` in protocols

> On 25. Jun 2017, at 22:13, Robert Bennett wrote: > > For a concrete type, a partial initializer is a function that: > Can set `let` instance variables > May not refer to `self` in an rvalue > Must set the same subset of instance variables regardless of the code path >

Re: [swift-evolution] [Pitch] `let` in protocols

What you want is some way to guarantee value semantics when writing generic code. It’s a known hole, and admittedly quite a big one. I hope that there will be time for core language improvements like this in Swift 5. Be sure to raise the issue again once planning for that starts! - Karl > On

Re: [swift-evolution] Reproducible builds (same code -> always same binary)

> On 12. Jun 2017, at 21:56, Tuur Anton via swift-evolution > wrote: > > > adrian kashivskyy wrote: > > > open-source projects and that most of them are compiled by users > > > Maybe that's true, but there are apps where most of users just download the > binary.

Re: [swift-evolution] Introducing synthesized locks

> On 12. Jun 2017, at 11:10, Erik Aigner via swift-evolution > wrote: > > In my day to day tasks, synchronization primitives are used quite often. ObjC > had the @synchronized attribute for methods. I didn’t find anything about > this in swift evolution, so I

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

> On 7. Jun 2017, at 19:35, Adam Sharp via swift-evolution > wrote: > > The new smart key path feature is really lovely, and feels like a great > addition to Swift. > > It seems like it might be straightforward to add overloads of `map` and > `flatMap` to the

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

> On 10. Jun 2017, at 01:42, Karl Wagner wrote: > >> >> On 8. Jun 2017, at 04:58, Tony Allevato via swift-evolution >> > wrote: >> >> +1, I really like this. It would also align nicely with the method type >>

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

> On 8. Jun 2017, at 04:58, Tony Allevato via swift-evolution > wrote: > > +1, I really like this. It would also align nicely with the method type > flattening in SE-0042 >

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On 9. Jun 2017, at 21:47, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 9, 2017, at 2:39 PM, Xiaodi Wu > > wrote: >> >> Interesting. So you’d want `newtype Foo = String` to start off with no >>

Re: [swift-evolution] [Pitch] Adding safety to arrays

rtant priorities than the need to assign elements out-of-order  I > > > > don't think we'd need to add another type to the standard library for > > > > this use case. > > > > > > > > > > > > On Apr 16, 2017, at 11:22 AM, Saagar Jha <saa.

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

> On 2 May 2017, at 05:29, Xiaodi Wu wrote: > > On Mon, May 1, 2017 at 9:52 PM, Karl Wagner > wrote: > > > On 2 May 2017, at 04:44, Xiaodi Wu > > wrote: > > > > Does this

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

> On 2 May 2017, at 04:44, Xiaodi Wu wrote: > > Does this gain something by being part of the standard library as opposed to > being built on top of it? Well, somebody thought repeatElement was general enough to make part of the standard library. If we’re going to allow

[swift-evolution] [Pitch] New collection-based 'repeat' API

Currently, we have the Repeated type, which presents a single element as though it were a Collection. > for i in repeatElement(1, count: 3) { print(i) } 1 1 1 > for i in repeatElement([1, 2, 3], count: 3) { print(i) } [1, 2, 3] [1, 2, 3] [1, 2, 3] However, we lack the ability for Collections

Re: [swift-evolution] Haskell-like as-patterns in switch statements

> On 23 Apr 2017, at 15:55, Ionuț G. Stan via swift-evolution > wrote: > > Hi all, > > I'm unsure if this is the appropriate venue to discuss this, so apologies if > it's not. > > I was wondering if the issue of supporting as-patterns in switch statements > has

Re: [swift-evolution] [Idea] Generic associated types

> wrote: >>> >>> I think you want higher-kinded >>> types. >>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types >>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution > wrote: > > Hi everyone, > > Thanks for your feedback on this proposal. Based on that plus additional > feedback from core team members and others who responded off-thread, we are > making the following

Re: [swift-evolution] [pitch] Comparison Reform

> On 18 Apr 2017, at 19:06, David Sweeris via swift-evolution > wrote: > > >> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution >> > wrote: >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

> On 18 Apr 2017, at 00:29, Karl Wagner wrote: > > >> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution >> > wrote: >> >> This is the best approach that I’m aware of. It does bake in an ABI >>

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution > wrote: > > This is the best approach that I’m aware of. It does bake in an ABI > assumption that the tuple layout will be contiguous and strided/addressable. > Monitor

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

> On 17 Apr 2017, at 21:18, Anders Kierulf wrote: > > >> On Apr 17, 2017, at 12:37 PM, Karl Wagner > > wrote: >> >>> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution >>>

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution > wrote: > > Proposal: UnsafeMutablePointer almost provides what I need. However, it can > only allocate memory on the heap, or it can take a given blob of memory and > interpret it as something else.

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution > wrote: > > > on Fri Apr 14 2017, Karl Wagner wrote: > >> Personally, the only valid use-case I can think of is when you want to >> initialise an Array’s elements

Re: [swift-evolution] [pitch] Comparison Reform

> On 16 Apr 2017, at 18:35, Karl Wagner wrote: > >> >> On 16 Apr 2017, at 05:32, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Sat Apr 15 2017, Xiaodi Wu >

Re: [swift-evolution] [pitch] Comparison Reform

> On 16 Apr 2017, at 05:32, Dave Abrahams via swift-evolution > wrote: > > > on Sat Apr 15 2017, Xiaodi Wu > wrote: > >> On Sat, Apr 15, 2017 at 3:12 PM, Dave Abrahams via swift-evolution < >>

Re: [swift-evolution] [pitch] Comparison Reform

> >> I think consideration should be given to a design that achieves a >> user-facing but not onerous differentiation between level 1 and level 2 >> equality. However, the only one I can think of is essentially a different >> shade of the `PartiallyComparable` alternative already outlined in the

Re: [swift-evolution] [pitch] Comparison Reform

> On 14 Apr 2017, at 02:58, Xiaodi Wu via swift-evolution > wrote: > > Jaden, the proposal literally says that a compiler feature named > "@_implements" is necessary for the proposed design to work. You can see WIP > for that feature in the apple/swift repo. > >

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution >> > wrote: >> >> I want to disagree with this is strongly

Re: [swift-evolution] [Pitch] Adding safety to arrays

> I'd actually say the #1 reason not to add this feature is that a lot of > developers don't seem to understand this, and they're likely to use the > feature to make their code try to continue in the face of programmer error > instead of trapping like it properly should. A program in an

  1   2   3   >