Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution > wrote: > > My answer to `inout` is to promote it to a full-fledged "storage class" (in C > terminology) and allow normal variables to be `inout`. > This would immediately solve the problems with

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

on Fri Jun 09 2017, Saagar Jha wrote: > It reads better and feels more natural. In my mind, it’s similar to the > difference between > > ["1", "2", "3"].flatMap { Double($0) } > > and > > ["1", "2", "3"].flatMap(Double.init) > > Saagar Jha I am not convinced this

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Fri Jun 09 2017, Kevin Ballard wrote: > On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: >> >> on Mon Jun 05 2017, Kevin Ballard wrote: >> >> > There’s also the curious case where I can have two String.Index

Re: [swift-evolution] History and future of Swift's parentheses

The topic of this thread: It is simply the history and future of parentheses in Swift. My initial post is just a starting point, it could have been something else. But I'm interested to hear what people have to say about the history and future of Swift's parentheses. What is messy: As I said,

Re: [swift-evolution] History and future of Swift's parentheses

It may make things more terrible. The solution introduces two separated type system and one is Swift 3 mode for asterisk syntax. > Robert Bennett via swift-evolution 於 2017年6月10日 > 上午6:02 寫道： > > I see. My ideal solution to this would be an explicit tuple packing

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

> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution > wrote: > > >> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution >> wrote: >> >> Typealiases can greatly reduce the complexity of code. But I think one >>

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

> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution > wrote: > > Typealiases can greatly reduce the complexity of code. But I think one change > in how the compiler handles them could make them even more powerful. [SNIP] > Perhaps it would be better if

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

It reads better and feels more natural. In my mind, it’s similar to the difference between ["1", "2", "3"].flatMap { Double($0) } and ["1", "2", "3"].flatMap(Double.init) Saagar Jha > On Jun 9, 2017, at 16:06, Max Moiseev via swift-evolution > wrote: > > Sorry.

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] Introduction of OrderedSet

I recall reading that in Python 3.6 they changed the implementation of set and dict to both have better performance *and* maintain insert order for free. I know nothing about the implementation details of this but might it be possible to make a similar change to Swift’s Set and Dictionary, so

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: > > on Mon Jun 05 2017, Kevin Ballard wrote: > > > There’s also the curious case where I can have two String.Index values > > that compare unequal but actually return the same value when used

Re: [swift-evolution] History and future of Swift's parentheses

I'm confused as to the topic of this thread: On the one hand, you're starting off with a statement about parentheses being used for multiple different things, suggesting that what you want to discuss is related to spelling using parentheses. OTOH, the exercises that you put forward show that

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 5:32 PM, Gor Gyolchanyan wrote: > Forked swift-evolution, created a draft proposal: > > https://github.com/technogen-gg/swift-evolution/blob/ > master/proposals/-uniform-initialization.md > > This is my first proposal, so I might have missed

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] History and future of Swift's parentheses

The analogy of the special first parameter label was relevant (for me) in that it was a special rule that was invented to resolve a problem/situation with no clear best solution. Probably most people agree now that the current simpler and more uniform rule set for parameter labels are obviously

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 9:12 AM, Gor Gyolchanyan via swift-evolution > > wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I

Re: [swift-evolution] Introduction of OrderedSet

> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution > wrote: > > Let me try to redirect this conversation, if I may. > > As far as I can tell, SE-0069 states plainly that the plan of record is to > offer a value type called OrderedSet in Foundation, but

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

Sorry. I might be missing something. Why is this better than: let allEmployees = Set(managers.flatMap { $0.directReports } ? > On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution > wrote: > > The new smart key path feature is really lovely, and feels like a

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution > wrote: > > The point of exercise 1 is to show that it is impossible (in Swift 4) to > write a generic function composition operator (or function) which works as > expected for any reasonable

Re: [swift-evolution] History and future of Swift's parentheses

I see. My ideal solution to this would be an explicit tuple packing and unpacking API, as opposed to implicitly flexible functions. Something akin to (borrowing Python’s asterisk syntax): func compose(_ g: (*U)->*V, _ f: (*T)->*U) -> (*T)->*V {...} The asterisks indicate that the

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

@Doug: It might indeed be confusing to use "typealias" for this. Looking at the HeaderKey example, alternatives could be: 1) struct inheritance (HeaderKey would inherit from String), value subtyping? 2) the ability to specify implicit conversion between types, C# has the implicit keyword

Re: [swift-evolution] History and future of Swift's parentheses

My answer to `inout` is to promote it to a full-fledged "storage class" (in C terminology) and allow normal variables to be `inout`. This would immediately solve the problems with `inout` being a magical thing in functions, as well as a convenient way of storing "references" (in C++

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] [Proposal] Uniform Initialization Syntax

Forked swift-evolution, created a draft proposal: https://github.com/technogen-gg/swift-evolution/blob/master/proposals/-uniform-initialization.md This is my first proposal, so I might

Re: [swift-evolution] History and future of Swift's parentheses

The point of exercise 1 is to show that it is impossible (in Swift 4) to write a generic function composition operator (or function) which works as expected for any reasonable functions. This was possible in Swift 3, but in Swift 4 it will only work for functions with exactly one parameter. You'd

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

+1 to this. My ideal imagining of this behavior is to: 1) Define a protocol containing the precise operations you want to support via forwarding. 2) Internally/fileprivately extend the original type to conform to this protocol. 3) In your new type, tell it to forward protocol members for a

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

> On Jun 9, 2017, at 2:53 PM, Tony Allevato wrote: > > +1 to this. My ideal imagining of this behavior is to: > > 1) Define a protocol containing the precise operations you want to support > via forwarding. > 2) Internally/fileprivately extend the original type to

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

On Fri, Jun 9, 2017 at 15:47 Matthew Johnson 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 > members on Foo? > > > Yeah. Previous discussions of newtype have usually

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 1:17 PM, Gor Gyolchanyan via swift-evolution > wrote: > > Yes, except why would you need to define `((A, B)) -> C`?, If you need to > pass a 2-element tuple into a function that takes two parameters - you can! > If you want to pass two values

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

> On Jun 9, 2017, at 3:16 PM, Tony Allevato wrote: > > Makes sense. I guess from an implementation point of view, the compiler only > needs to be able to see the signatures of the members to synthesize the calls > to them. My thinking was that conforming the original

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 8:12 AM, Gor Gyolchanyan via swift-evolution > wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concept of

Re: [swift-evolution] [Meta] WWDC week

> On Jun 5, 2017, at 8:53 PM, Brent Royal-Gordon > wrote: > > How does Friday sound to people? Based on a couple of Twitter responses, it > seems to be pretty open, and it has the advantage that nobody's gonna have a > talk or event the

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

Makes sense. I guess from an implementation point of view, the compiler only needs to be able to see the signatures of the members to synthesize the calls to them. My thinking was that conforming the original type would remove the need for the compiler to verify separately that the members exist

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

> On Jun 9, 2017, at 2:39 PM, Xiaodi Wu wrote: > > Interesting. So you’d want `newtype Foo = String` to start off with no > members on Foo? Yeah. Previous discussions of newtype have usually led to discussion of ways to forward using a protocol-oriented approach.

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

Interesting. So you’d want `newtype Foo = String` to start off with no members on Foo? On Fri, Jun 9, 2017 at 15:18 Matthew Johnson wrote: > On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jun 9, 2017 at 12:44

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

> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution > > wrote: > Somewhat related to this, shouldn’t it be possible to

Re: [swift-evolution] Introduction of OrderedSet

Let me try to redirect this conversation, if I may. As far as I can tell, SE-0069 states plainly that the plan of record is to offer a value type called OrderedSet in Foundation, but resources to design and implement were not then available. So, little point in having a vote as to whether one is

Re: [swift-evolution] History and future of Swift's parentheses

Yes, except why would you need to define `((A, B)) -> C`?, If you need to pass a 2-element tuple into a function that takes two parameters - you can! If you want to pass two values into a function that *looks* like it takes a single 2-element tuple - you can! Seems to me that the difference

Re: [swift-evolution] Int indexing into UTF16View

on Thu Jun 08 2017, David Hart wrote: > Hello, > > When working with Strings which are known to be ASCII, I tend to use > the UTF16View for the performance of random access. I would also like > to have the convenience of indexing with Int: > > let barcode =

Re: [swift-evolution] Introduction of OrderedSet

This sounds awesome to me, except I'd take it a bit further and bring this idea to its logical conclusion: creating concrete type subtypes. Take, for example the CGFloat, which is a struct, that's essentially a subtype of Double. Seems like what you actually want is to create a subtype of

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

On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > Somewhat related to this, shouldn’t it be possible to sub-struct a struct > as long as you only add functions and computed properties (i.e., no stored > properties)? Traditionally structs cannot

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

> On Jun 9, 2017, at 6:12 PM, Jacob Williams wrote: > >> On Jun 9, 2017, at 9:53 AM, Charlie Monroe > > wrote: >> >> -1 - this would disallow e.g. to share UI code between iOS and macOS: >> >> #if os(iOS) >>

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

Somewhat related to this, shouldn’t it be possible to sub-struct a struct as long as you only add functions and computed properties (i.e., no stored properties)? Traditionally structs cannot be subtyped because their size must be known at compile time. I don’t know the implementation details of

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

> On Jun 9, 2017, at 9:53 AM, Charlie Monroe wrote: > > -1 - this would disallow e.g. to share UI code between iOS and macOS: > > #if os(iOS) > typealias XUView = UIView > #else > typealias XUView = NSView > #endif > > extension XUView { > ... > }

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

-1 - this would disallow e.g. to share UI code between iOS and macOS: #if os(iOS) typealias XUView = UIView #else typealias XUView = NSView #endif extension XUView { ... } or with any similar compatibility typealiases. > On Jun 9, 2017, at 5:38 PM, Jacob Williams via

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

I feel like this might be better served by something like newtype which I know I've seen floating around on this list before. The idea is that something like: newtype HeaderKey = String would serve roughly as syntactic sugar for something like struct HeaderKey { let value: String init(_

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

+1 from me. There have been times I’ve wanted to subclass an object (such as String) but since it is a non-class, non-protocol type you can only extend Strings existing functionality which adds that same functionality to Strings everywhere. It would be nice if we could either extend type

Re: [swift-evolution] Introduction of OrderedSet

+1 for ordered set and dictionary, and please add ordered dictionary in ObjC as well. Envoyé de mon iPhone > Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution > a écrit : > > +1, and would also like to see OrderedDictionary as well. > >> On Jun 9, 2017,

Re: [swift-evolution] History and future of Swift's parentheses

> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution > a écrit : > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concept of

Re: [swift-evolution] History and future of Swift's parentheses

> > So I wonder if any of you have had any thoughts about what Swift's > parentheses-related future (or evolutionary baggage) will be? > I really wish swift used the concept of tuples **exclusively** for all purposes that involve parentheses, as well as dividing tuples into two categories: -

Re: [swift-evolution] History and future of Swift's parentheses

At first I thought that task 1 looked innocuous enough; then I discovered this bizarre behavior. Not sure if this was the point of your email.  func compose(_ g: @escaping (U)->V, _ f: @escaping (T)->U) -> (T)->V { return { x in g(f(x)) } } func strung(_ tuple: (Int, Int)) -> (String,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Cool. I have reservations about idea #3, but we can tackle that another day. (Real life things beckon.) But suffice it to say that I now really, really like your idea #2. On Fri, Jun 9, 2017 at 08:06 Gor Gyolchanyan wrote: > You know, come to think of it, I totally agree,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

You know, come to think of it, I totally agree, and here's why: A normal initializer (if #2 is accepted) would *conceptually* have the signature: mutating func `init`(...) -> Self Which would mean that both `self` and the returned result are non-optional. A failable initializer could then have

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 07:33 Gor Gyolchanyan wrote: > So far, we've discussed two ways of interpreting `self = nil`, both of > which have a sensible solution, in my opinion: > > 1. It's a special rule like you said, which can be seen as > counter-intuitive, but recall that

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

So far, we've discussed two ways of interpreting `self = nil`, both of which have a sensible solution, in my opinion: 1. It's a special rule like you said, which can be seen as counter-intuitive, but recall that `return nil` is just as much of a special rule and is also largely

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan wrote: > I think a good approach would be to have `self = nil` only mean `the > initializer is going to fail` because if your type is > ExpressibleByNilLiteral, it means that the `nil` of your type already > carries the same

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan wrote: > The type of `self` could remain `inout Self` inside the failable > initializer. The ability to assign nil would be a compiler magic (much like > `return nil` is compiler magic) that is meant to introduce uniformity to >

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

I think a good approach would be to have `self = nil` only mean `the initializer is going to fail` because if your type is ExpressibleByNilLiteral, it means that the `nil` of your type already carries the same meaning as if your type was not ExpressibleByNilLiteral and was an optional instead,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

The type of `self` could remain `inout Self` inside the failable initializer. The ability to assign nil would be a compiler magic (much like `return nil` is compiler magic) that is meant to introduce uniformity to the initialization logic. The idea is to define all different ways

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

If `self` is not of type `inout Self?`, then what is the type of `self` such that you may assign it a value of `nil`? It certainly cannot be of type `inout Self`, unless `Self` conforms to `ExpressibleByNilLiteral`, in which case you are able to assign `self = nil` an unlimited number of

Re: [swift-evolution] Introduction of OrderedSet

+1, and would also like to see OrderedDictionary as well. > On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution > wrote: > > I would be in favor of it; there have been a few times (including Core Data, > as you mentioned) where I would have used it had it

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Good point, but not necessarily. Since you cannot access `self` before it being fully initialized and since `self` can only be initialized once, this would mean that after `self = nil`, you won't be allowed to access `self` in your initializer at all.You'll be able to do any potential, cleanup

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> Le 9 juin 2017 à 10:07, Mark Lacey a écrit : > > I’m not trying to argue that it’s impossible to do. I don’t think it’s a good > idea at all. That’s subjective. Me saying “that really should be an error” is > a subjective statement. I don’t have to say “This is a

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 9, 2017, at 12:55 AM, Gwendal Roué wrote: > >> >> Le 9 juin 2017 à 09:41, Mark Lacey > > a écrit : >> >> >>> On Jun 9, 2017, at 12:12 AM, Gwendal Roué >>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> Le 9 juin 2017 à 09:41, Mark Lacey a écrit : > > >> On Jun 9, 2017, at 12:12 AM, Gwendal Roué > > wrote: >> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return "notOverloaded1" }

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 9, 2017, at 12:12 AM, Gwendal Roué wrote: > >>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >>> "notOverloaded1" } >>> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >>> { return "notOverloaded3" } >>>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >> "notOverloaded1" } >> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >> { return "notOverloaded3" } >> >> func overloaded(_ closure: (Int, Int) -> Int) -> String { return >>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 8, 2017, at 11:37 PM, Gwendal Roué via swift-evolution > wrote: > > >> Le 9 juin 2017 à 07:56, Vladimir.S via swift-evolution >> > a écrit : >> >> Yes, we are discussing the *potential*

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> Le 9 juin 2017 à 07:56, Vladimir.S via swift-evolution > a écrit : > > Yes, we are discussing the *potential* solutions for Swift 4 that can > decrease the pain of migration of *some* Swift3 code, given (Int,Int)->() and > ((Int,Int))->() are different types in

Re: [swift-evolution] Int indexing into UTF16View

It's not. Static strings use UTF-8. > Le 8 juin 2017 à 16:38, David Hart via swift-evolution > a écrit : > > > >> On 8 Jun 2017, at 14:15, Vladimir.S wrote: >> >>> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >>> Hello, >>> When