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

[John McCall via swift-evolution]

> 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 `inout` being a magical thing 
> in functions, as well as a convenient way of storing "references" (in C++ 
> terminology) to potentially huge inout expressions, not to mention returning 
> an inout from a function, effectively spreading the getter-setter awesomeness 
> to everything else besides properties and subscripts.

C++ implements this idea by being utterly unsafe; Rust implements it by 
introducing entire new dimensions of language complexity.  Are you proposing 
one of these in particular, or do you have your own concept?

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

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

[Dave Abrahams via swift-evolution]

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 syntactic sugar is worth complicating the
language or library for, but if it is, IMO the right thing is to make a
keypath be-a subtype of the appropriate function type, rather than to
start down the path of creating a keypath overload for every method that
takes a closure argument.

>
>> On Jun 9, 2017, at 16:06, Max Moiseev via swift-evolution 
>>  wrote:
>> 
>> 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 great 
>>> addition to Swift.
>>> 
>>> It seems like it might be straightforward to add overloads of `map`
>>> and `flatMap` to the standard library to make use of the new
>>> functionality:
>>> 
>>> let managers = flatOrganisation.managers
>>> let allEmployees = Set(managers.flatMap(\.directReports))
>>> let employeeNames = Set(allEmployees.map(\.name))
>>> 
>>> This feels like a really natural way of working with key paths in a
>>> functional style. It makes a lot of sense for collections, and
>>> possibly for Optional too (although as far as I can see optional
>>> chaining is more or less equivalent, and with more compact syntax).
>>> 
>>> I’m hoping that this might be low-hanging fruit that could be
>>> considered for the Swift 4 release. I’d be happy to have a go at
>>> writing a proposal if there’s interest!
>>> 
>>> –Adam
>>> 
>>> ___
>>> 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
>

-- 
-Dave

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

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

[Dave Abrahams via swift-evolution]

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 values
>> > that compare unequal but actually return the same value when used in a
>
>> > subscript. 
>> > For example, with the above string, if I have a
>> > String.Index(encodedOffset: 0) and a String.Index(encodedOffset:
>> > 1). This may not be a problem in practice, but it’s something to be
>> > aware of.
>> 
>> I don't think this one even rises to that level.
>> 
>> let s = "aaa"
>> var si = s.indices.makeIterator()
>> let i0 = si.next()!
>> let i1 = si.next()!
>> print(i0 == i1)   // false
>> print(s[i0] == s[i1]) // true.  Surprised?
>
> Good point.
>
>> > I’m also confused by the paragraph about index comparison. It talks
>> > about if two indices are valid in a single String view, comparison
>> > semantics are according to Collection, and otherwise indexes are
>> > compared using encodedOffsets, and this means indexes aren’t totally
>> > ordered. But I’m not sure what the first part is supposed to mean. How
>> > is comparing indices that are valid within a single view any different
>> > than comparing the encodedOffsets?
>> 
>> In today's String, encodedOffset is an offset in UTF-16.  Two indices
>> into a UTF-8 view may be unequal yet have the same encodedOffset.
>
> Ah, right. So a String.Index is actually something similar to
>
> public struct Index {
> public var encodedOffset: Int
> private var byteOffset: Int // UTF-8 offset into the UTF-8 code unit
> }

Similar.  I'd write it this way:

public struct Index {
   public var encodedOffset: Int

   // Offset into a UnicodeScalar represented in an encoding other
   // than the String's underlying encoding
   private var transcodedOffset: Int 
}

> In this case, can't we still define String.Index comparison as merely
> being the lexicographical comparison of (encodedOffset, byteOffset)?

Yes, and that's how it's implemented in the PR.  But byteOffset is not
part of the user model, so we can't specify it that way.

> Also, as a side note, the proposal implies that encodedOffset is
> mutable. Is this actually the case? If so, I assume that mutating it
> would also reset the byteOffset?

Yes, 

 i.encodedOffset = n

is equivalent to

 i = String.Index(encodedOffset: n)
 
-- 
-Dave

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

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

[Jens Persson via swift-evolution]

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, many things parentheses-related in Swift are (at least
currently) messy: tuples, func calling, -definitions, -signatures, -types,
discussions about them, etc.

It's hard to discuss (and probably design) a system in which parentheses
are used for so many different but intertweaved concepts (is there a
complete list of all the uses for parentheses in Swift?).

There are many concrete examples of this  parentheses-related "mess",
namely bugs and/or inconsistencies. See for example the four bugs I was
just recently asked to file in this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170605/037049.html

Similar inconsistencies and bugs have been in Swift since the first beta.

Why are they still there? Why does it take so long to get rid of them?

Again, I think part of the problem is that the multipurpose parentheses
confuses people and also makes it necessary to add special rules to handle
clashes in the syntax which would perhaps not have been there if
parentheses hadn't been used for so many different things.

Don't know if that clarified anything or if I'm just repeating myself.

I'm not seeking to discuss any particular kinds of cleaning up, just
interested to hear anything people think about related to parentheses in
Swift (tuples, paramter lists, argument lists, pattern matching, ...).

/Jens


On Sat, Jun 10, 2017 at 2:00 AM, Xiaodi Wu  wrote:

> 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 you're concerned about
> the loss of implicit tuple splatting, a well-acknowledged regression, for
> which the way forward is to introduce explicit tuple splatting at some
> point in the future (at least, according to SE-0029, that's the intended
> direction for Swift).
>
> What, in the end, are you claiming to be "messy," and what kinds of
> cleaning up are you seeking to discuss?
>
>
>
> On Fri, Jun 9, 2017 at 7:34 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 better. It was possible to escape the ugly special case of the
>> first parameter, after all.
>>
>> Similarly, I wonder if the parentheses-related mess actually can be
>> simpler and more uniform, after all. I remember a lot of discussions in
>> which people argued that Swift couldn't and/or shouldn't get rid of the
>> special first parameter label rules.
>>
>> I'm not a compiler hacker and I have no idea exactly what aspects of the
>> language is easy/hard/impossible to change once Swift is binary stable.
>>
>> My concrete concerns are that the messy parentheses-related parts of the
>> language will continue to be messy for ever.
>> I have no idea if there is any actual reason to worry about that, but ABI
>> stability was originally intended for Swift 3, and then it was postponed
>> because some stuff needed to be done before ABI stability. Now I'm just
>> worried that solving the parentheses situation is something that needs to
>> be done before ABI stability. Please correct/enlighten me!
>>
>> /Jens
>>
>>
>>
>> On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman 
>> wrote:
>>
>>>
>>>
>>> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution <
>>> swift-evolution@swift.org> 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 functions.
>>> This was possible in Swift 3, but in Swift 4 it will only work for
>>> functions with exactly one parameter. You'd have to special-case it for
>>> every combination of parameter counts of f and g that it should be able to
>>> handle.
>>>
>>> The following program demonstrates how it can be done in Swift 3.1 and
>>> 3.2:
>>>
>>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U)
>>> -> (T) -> V {
>>> return { x in g(f(x)) }
>>> }
>>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>>> func square(_ a: Int) -> Int { return a * a }
>>> let squaredSum = compose(square, sum)
>>> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here
>>> but ok ...
>>> print(result) // 49
>>> // Well, it 

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

[Susan Cheng via swift-evolution]

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 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 arguments to the function will be packed into 
> a tuple (or not, in the case of a single-argument function) whose type is 
> denoted by T, U, V, or conversely that the functions take/return argument 
> lists that look like *T, *U, *V where T, U, V are tuple types. Then the 
> function definition would look like
> 
> {
> return { x: *T in g(f(x)) }
> }
> 
> This would in essence create a new non nominal type: function argument lists. 
> These would be distinct from tuples, although the two may freely be converted 
> into one another using the asterisk. This type would be structurally distinct 
> from tuples by virtue of the fact that single-element argument lists exist 
> while single-element tuples do not. (An asterisk will convert a 
> single-element argument list into a single (non-tuple) element and vice 
> versa.)
> 
> To users, argument lists would be accessed solely through tuples with the 
> asterisk syntax. The identity **T == T would hold whenever T is a tuple or 
> argument list. Their usefulness would lie in the ability to call f(*x) when f 
> takes multiple arguments and x is a tuple.
> 
> I acknowledge that this is probably not going to happen for Swift 4 but I 
> would sure like it if it did.
> 
>> On Jun 9, 2017, at 5: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 functions.
>> This was possible in Swift 3, but in Swift 4 it will only work for functions 
>> with exactly one parameter. You'd have to special-case it for every 
>> combination of parameter counts of f and g that it should be able to handle.
>> 
>> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
>> 
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
>> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> let squaredSum = compose(square, sum)
>> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but 
>> ok ...
>> print(result) // 49
>> // Well, it worked, not flawlessly but we did manage to write
>> // a function composition function and we composed sum
>> // and square, and we could call it and get a correct result.
>> 
>>  
>> And this program demonstrates what happens if you try it in Swift 4:
>> 
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
>> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> // let squaredSum = compose(square, sum) // Error! (without the 
>> compose-variant below)
>> 
>> // The error message is:
>> // Cannot convert value of type `(Int, Int) -> Int` to
>> // expected argument type `(_) -> _`
>> 
>> // That's it, it is simply not possible!
>> 
>> // You'd have to write special variants of the compose func for every 
>> combination
>> // of parameter counts! For example, in order to get this sum and square
>> // example working, this specific variant must be written:
>> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> 
>> V) -> (T, U) -> W {
>> return { (x, y) in g(f(x, y)) }
>> }
>> // Now it will work:
>> let squaredSum = compose(square, sum)
>> // But only thanks to that awfully specific compose func variant ...
>> // We would have to write a lot more variants for it to be practically 
>> usable on pretty much any common function.
>> 
>> I'm sure some will say:
>> "no regular developers use function composition anyway so why ..."
>> or
>> "It's not very swifty to use free functions and higher order functions like 
>> that."
>> 
>> My answer is that this is just a simple but telling example. The issue (as I 
>> see it) exists in all situations involving generics and function types.
>> 
>> I'm a regular programmer and I like to be able to write basic, useful 
>> abstractions.
>> It's no fun when the language forces you to write lots of specific variants 
>> of your generic code.
>> 
>> I would feel less worried about the parentheses situation if the language 
>> was going in a direction where you could see how this simple exercise would 
>> be a no brainer.
>> 
>> Can Swift's parentheses-situation be sorted out before ABI 

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

[David Sweeris via swift-evolution]

> 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 
>> change in how the compiler handles them could make them even more powerful.
> [SNIP]
>> Perhaps it would be better if the extension would only apply to the parts of 
>> my code where I use the HeaderKey typealias and not to all Strings. This 
>> could be a great tool to specialize classes by creating a typealias and 
>> adding functionality to it. Another example I can think of is typealiases 
>> for dictionaries or arrays with added business logic through extensions 
>> (especially since you can't inherit from structs).
>> 
>> If you want to create an extension that adds functionality to all Strings 
>> you could have created an extension for String instead of HeaderKey.
>> 
>> Please let me know what you think. I'm not sure how complex this change 
>> would be.
>> I could write a proposal if you're interested.
> 
> Isn’t the point of “typealias" is that it does NOT have any change in 
> semantics? The compiler doesn’t even have to acknowledge aliases in any 
> run-time type tables, it just references the existing row of what the alias 
> points to (based on a compile-time type table).
> 
> As others suggested, this new semantic could be moved to a new type concept 
> (with a new keyword).

Agreed... +1 for something like "newtype", -1 for hoisting that functionality 
onto "typealias".

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

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

[Daryle Walker via swift-evolution]

> 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 the extension would only apply to the parts of 
> my code where I use the HeaderKey typealias and not to all Strings. This 
> could be a great tool to specialize classes by creating a typealias and 
> adding functionality to it. Another example I can think of is typealiases for 
> dictionaries or arrays with added business logic through extensions 
> (especially since you can't inherit from structs).
> 
> If you want to create an extension that adds functionality to all Strings you 
> could have created an extension for String instead of HeaderKey.
> 
> Please let me know what you think. I'm not sure how complex this change would 
> be.
> I could write a proposal if you're interested.

Isn’t the point of “typealias" is that it does NOT have any change in 
semantics? The compiler doesn’t even have to acknowledge aliases in any 
run-time type tables, it just references the existing row of what the alias 
points to (based on a compile-time type table).

As others suggested, this new semantic could be moved to a new type concept 
(with a new keyword).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

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

[Saagar Jha via swift-evolution]

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. 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 great 
>> addition to Swift.
>> 
>> It seems like it might be straightforward to add overloads of `map` and 
>> `flatMap` to the standard library to make use of the new functionality:
>> 
>>  let managers = flatOrganisation.managers
>>  let allEmployees = Set(managers.flatMap(\.directReports))
>>  let employeeNames = Set(allEmployees.map(\.name))
>> 
>> This feels like a really natural way of working with key paths in a 
>> functional style. It makes a lot of sense for collections, and possibly for 
>> Optional too (although as far as I can see optional chaining is more or less 
>> equivalent, and with more compact syntax).
>> 
>> I’m hoping that this might be low-hanging fruit that could be considered for 
>> the Swift 4 release. I’d be happy to have a go at writing a proposal if 
>> there’s interest!
>> 
>> –Adam
>> 
>> ___
>> 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

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

[Karl Wagner via swift-evolution]

> 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 standard library to make use of the new functionality:
> 
>   let managers = flatOrganisation.managers
>   let allEmployees = Set(managers.flatMap(\.directReports))
>   let employeeNames = Set(allEmployees.map(\.name))
> 
> This feels like a really natural way of working with key paths in a 
> functional style. It makes a lot of sense for collections, and possibly for 
> Optional too (although as far as I can see optional chaining is more or less 
> equivalent, and with more compact syntax).
> 
> I’m hoping that this might be low-hanging fruit that could be considered for 
> the Swift 4 release. I’d be happy to have a go at writing a proposal if 
> there’s interest!
> 
> –Adam
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Working demo:

struct VirtualKeyPath {
let block: (Root) -> Value
func evaluate(on: Root) -> Value { return block(on) }
}

// If we could extend 'Any', this would be possible...
//extension Any {
//subscript(keyPath: VirtualKeyPath) -> Value {
//return keyPath.evaluate(on: self)
//}
//}

extension KeyPath where Value: Collection {

func map(_ descendent: KeyPath) -> 
VirtualKeyPath {
return VirtualKeyPath { (obj: Root) -> [T] in
return obj[keyPath: self].map { $0[keyPath: descendent] }
}
}
}

extension VirtualKeyPath where Value: Collection {

func map(_ descendent: KeyPath) -> 
VirtualKeyPath {
return VirtualKeyPath { (obj: Root) -> [T] in
return self.evaluate(on: obj).map { $0[keyPath: descendent] }
}
}
}

struct Person {
let name: String
}
struct Department {
let people: [Person]
}

let nameLengths = (\Department.people).map(\.name).map(\.characters.count)

let testObj = Department(people: [Person(name: "Alice"),
  Person(name: "Bob"),
  Person(name: "Claire"),
  Person(name: "David")])

kp.evaluate(on: testObj) // returns [5, 3, 6, 5]
As far as making this kind of thing easier in the language is concerned, one 
thing I can think of is allowing another \ to end the key-path expression, 
rather than enclosing it with brackets. So:

let nameLengths = (\Department.people).map(\.name).map(\.characters.count)

Becomes:

let nameLengths = \Department.people\.map(\.name).map(\.characters.count)

And that’s it, I think. It’s quite nice as-is.

- Karl

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

Re: [swift-evolution] Introduction of OrderedSet

[Robert Bennett via swift-evolution]

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 that we don’t even 
need specialized ordered variants?

> On Jun 9, 2017, at 7:28 PM, Douglas Gregor  wrote:
> 
> 
>> 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 resources to design 
>> and implement were not then available.
>> 
>> So, little point in having a vote as to whether one is in favor of 
>> OrderedSet or not. In my view, the questions to be answered are:
>> 
>> For the core team–
>> 
>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>> future addition to Foundation?
> 
> *I* think it’s still a good idea, and I suspect that others on the core team 
> will agree.
> 
>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>> community help to bring about this addition?
> 
> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
> anything in Swift 5 that would absolutely require us to introduce this 
> functionality in that time frame. It’s a bit of a nice-to-have-at-any-point, 
> noting of course that bridging NSOrderedSet in existing APIs is a nontrivial 
> source-breaking change.
> 
> Having a proposed API and implementation on hand makes it easier to add this 
> functionality, of course.
> 
>> If not, for the whole community–
>> 
>> * Is it wise to implement such a type in the standard library? Should we 
>> simply bring over the native implementation from Swift Package Manager? What 
>> are the implications for bridging?
> 
> Obviously, we’d want an efficient copy-on-write, native implementation; the 
> Swift Package Manager implementation is a bit more bare-bones than we’d want: 
> absolute performance matters, so having a separate Set + Array in the struct 
> probably isn’t good enough. Bridging performance matters, so we’d probably 
> want the one-pointer representation like array uses where the pointer can be 
> vended directly to Objective-C.
> 
>   - Doug
> 
>>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
>>>  wrote:
>>> +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, 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 been available.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> 
>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>>  wrote:
>> 
>> Hello,
>> 
>> in the past there have been a few requests for an OrderedSet 
>> implementation in Swift. In the proposal 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  was mentioned that the OrderedSet will be considered for the feature.
>> 
>> However, since then there were a few discussions on OrderedSet but it 
>> doesn’t get much attention and there wasn’t any comment about it from 
>> the swift team.
>> 
>> I want to bring up some points, why an OrderedSet is needed in the base 
>> library.
>> 
>> 1. CoreData is probably the most obvious place where people would use an 
>> ordered set. Especially when working with large amounts of data, 
>> presorting can save a lot of time and battery life. If a bridgeable 
>> ordered set was part of the standard library we could use a ordered set 
>> in swift without having to use the NSOrderedSet from objective c. Which 
>> would be pretty nice in my opinion. Even when using a NSOrderedSet we 
>> couldn’t have a generic version of it.
>> 
>> 2. A shared datamodel between App and Server. One main advantage of 
>> having web servers written in Swift is that we can share code between 
>> the server and the app. For servers performance does matter a lot, since 
>> they are usually working with much more data than apps. Databases are 
>> represented as sets and fetching sorted data from the database can be 
>> represented as an ordered set. However, since we don’t have ordered sets 
>> we 

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

[Kevin Ballard via swift-evolution]

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 in a
> > subscript. 
> > For example, with the above string, if I have a
> > String.Index(encodedOffset: 0) and a String.Index(encodedOffset:
> > 1). This may not be a problem in practice, but it’s something to be
> > aware of.
> 
> I don't think this one even rises to that level.
> 
> let s = "aaa"
> var si = s.indices.makeIterator()
> let i0 = si.next()!
> let i1 = si.next()!
> print(i0 == i1)   // false
> print(s[i0] == s[i1]) // true.  Surprised?

Good point.

> > I’m also confused by the paragraph about index comparison. It talks
> > about if two indices are valid in a single String view, comparison
> > semantics are according to Collection, and otherwise indexes are
> > compared using encodedOffsets, and this means indexes aren’t totally
> > ordered. But I’m not sure what the first part is supposed to mean. How
> > is comparing indices that are valid within a single view any different
> > than comparing the encodedOffsets?
> 
> In today's String, encodedOffset is an offset in UTF-16.  Two indices
> into a UTF-8 view may be unequal yet have the same encodedOffset.

Ah, right. So a String.Index is actually something similar to

public struct Index {
public var encodedOffset: Int
private var byteOffset: Int // UTF-8 offset into the UTF-8 code unit
}

In this case, can't we still define String.Index comparison as merely being the 
lexicographical comparison of (encodedOffset, byteOffset)?

Also, as a side note, the proposal implies that encodedOffset is mutable. Is 
this actually the case? If so, I assume that mutating it would also reset the 
byteOffset?

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

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

[Xiaodi Wu via swift-evolution]

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 you're concerned about
the loss of implicit tuple splatting, a well-acknowledged regression, for
which the way forward is to introduce explicit tuple splatting at some
point in the future (at least, according to SE-0029, that's the intended
direction for Swift).

What, in the end, are you claiming to be "messy," and what kinds of
cleaning up are you seeking to discuss?



On Fri, Jun 9, 2017 at 7:34 PM, Jens Persson via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 better. It was possible to escape the ugly special case of the
> first parameter, after all.
>
> Similarly, I wonder if the parentheses-related mess actually can be
> simpler and more uniform, after all. I remember a lot of discussions in
> which people argued that Swift couldn't and/or shouldn't get rid of the
> special first parameter label rules.
>
> I'm not a compiler hacker and I have no idea exactly what aspects of the
> language is easy/hard/impossible to change once Swift is binary stable.
>
> My concrete concerns are that the messy parentheses-related parts of the
> language will continue to be messy for ever.
> I have no idea if there is any actual reason to worry about that, but ABI
> stability was originally intended for Swift 3, and then it was postponed
> because some stuff needed to be done before ABI stability. Now I'm just
> worried that solving the parentheses situation is something that needs to
> be done before ABI stability. Please correct/enlighten me!
>
> /Jens
>
>
>
> On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman 
> wrote:
>
>>
>>
>> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution <
>> swift-evolution@swift.org> 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 functions.
>> This was possible in Swift 3, but in Swift 4 it will only work for
>> functions with exactly one parameter. You'd have to special-case it for
>> every combination of parameter counts of f and g that it should be able to
>> handle.
>>
>> The following program demonstrates how it can be done in Swift 3.1 and
>> 3.2:
>>
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U)
>> -> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> let squaredSum = compose(square, sum)
>> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here
>> but ok ...
>> print(result) // 49
>> // Well, it worked, not flawlessly but we did manage to write
>> // a function composition function and we composed sum
>> // and square, and we could call it and get a correct result.
>>
>>
>> And this program demonstrates what happens if you try it in Swift 4:
>>
>> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U)
>> -> (T) -> V {
>> return { x in g(f(x)) }
>> }
>> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
>> func square(_ a: Int) -> Int { return a * a }
>> // let squaredSum = compose(square, sum) // Error! (without the
>> compose-variant below)
>>
>> // The error message is:
>> // Cannot convert value of type `(Int, Int) -> Int` to
>> // expected argument type `(_) -> _`
>>
>> // That's it, it is simply not possible!
>>
>> // You'd have to write special variants of the compose func for every
>> combination
>> // of parameter counts! For example, in order to get this sum and square
>> // example working, this specific variant must be written:
>> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U)
>> -> V) -> (T, U) -> W {
>> return { (x, y) in g(f(x, y)) }
>> }
>> // Now it will work:
>> let squaredSum = compose(square, sum)
>> // But only thanks to that awfully specific compose func variant ...
>> // We would have to write a lot more variants for it to be practically
>> usable on pretty much any common function.
>>
>> I'm sure some will say:
>> "no regular developers use function composition anyway so why ..."
>> or
>> "It's not very swifty to use free functions and higher order functions
>> like that."
>>
>> My answer is that this is just a simple but telling example. The issue
>> (as I see it) exists in all situations involving generics and function
>> types.
>>
>> I'm a regular programmer and I like to be able to 

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

[Xiaodi Wu via swift-evolution]

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 something or composed it
> wrong, so please feel free to comment, fork and send pull requests. 
>
>
This is a very interesting read. We did not discuss the 'indirect' idea at
all on this list. Did you come up with it just now? In any case, my
suggestion as to moving forward would be this:

- Do you feel that both halves of your draft (expanding `return` in
initializers, and `indirect` initializers) should absolutely be one
proposal, or can they be separated?

a) If they can be separated because each half has individual merit, then
these ideas may be more likely to succeed as separate proposals, as each
can be critiqued fully and judged independently as digestible units.

b) If you intend to tackle all your ideas all at once, that's going to be a
much bigger change--in terms of review effort, likely bikeshedding, and
implementation effort. It'll probably be best to solicit initial feedback
on this list first about `indirect` initializers, even if just to
familiarize the community with the idea, before launching into a pitch of
the whole proposal.


On Jun 9, 2017, at 3:24 PM, Xiaodi Wu  wrote:
>
> 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, 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 the signature:
>>
>> mutating func `init`() -> Self?
>>
>> Which would make the returned result optional, but leave `self`
>> non-optional.
>> This would make `return nil` less out-of-place, like you said, while
>> still leaving `self` as a set-exactly-once `inout Self`.
>> A factory initializer would then have the signature:
>>
>> static func `init`(...) -> Self
>>
>> or in case of a failable factory initializer:
>>
>> static func `init`(...) -> Self?
>>
>> Which would still make sense with the now legal `return ...` syntax,
>> while adding the restriction of not having any `self` at all.
>> So, annotating the initializer with the keyword `factory` would cause it
>> to change the signature as well as remove any compiler assumptions about
>> the dynamic type of the returned instance.
>>
>> In addition, idea #3 would be available for more deterministic in-place
>> initialization.
>>
>> On Jun 9, 2017, at 2:47 PM, Xiaodi Wu  wrote:
>>
>> 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 `return nil` is just as much of a
>>> special rule and is also largely counter-intuitive.
>>>
>>
>> `return nil` is “special,” but it doesn’t conflict with any other syntax
>> because the initializer notionally has no return value. Personally, I have
>> always disliked `return nil` in failable initializers for that reason, but
>> I couldn’t come up with a better alternative.
>>
>> Your proposed idea to allow returning any value is interesting because,
>> in the case of a failable initializer, `return nil` continues to have the
>> same meaning if we consider the return value of the initializer to be of
>> type `Self?`. For that reason, I think your idea #2 is quite clever, and it
>> would go a long way in making `return nil` a lot less odd. It also
>> increases the expressivity of initializers because it allows one to set the
>> value of self and also return in one statement, clearly demonstrating the
>> intention that no other code in the initializer should be run before
>> returning.
>>
>> For all of those reasons, I think idea #2 is a winning idea.
>>
>> The benefit of `self = nil` is that it's much more in line with
>>> initialization semantics, it provides more uniform syntax and it's a bit
>>> less restrictive.
>>>
>>> 2. It's an `inout Self!`, like Greg said, which can be seen as more
>>> cumbersome. Implicitly unwrapped optionals are a bit difficult, but this
>>> "variation" of it is much more restrictive then the normal ones, because
>>> unlike normal implicitly unwrapped optionals, this one cannot be accessed
>>> after being assigned nil (and it also cannot be indirectly assigned `nil`,
>>> because escaping `self` is not allowed before full initialization), so
>>> there is 

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

[Karl Wagner via swift-evolution]

> 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 
>> flattening in SE-0042 
>> 
>>  (once it gets implemented), because passing keypaths (i.e., unbound 
>> property references) and unbound parameterless method references to 
>> map/flatMap would look nearly the same:
>> 
>> ```
>> struct Person {
>>   let firstName: String
>>   let lastName: String
>>   func fullName() -> String { return "\(firstName) \(lastName)" }
>> }
>> 
>> let people: [Person]
>> let firstNames = people.map(\.firstName)
>> let fullNames = people.map(Person.fullName)  // because after SE-0042, this 
>> will be (Person) -> String, not (Person) -> () -> String
>> ```
>> 
>> Especially if there's a move in the future to also use \. to denote unbound 
>> methods references, which was discussed during the keypath reviews. (Even 
>> with that, I believe it would be more work though to get rid of the explicit 
>> type name in the function case.)
>> 
>> 
> 
> When it comes to unbound method references, personally, I would love to see 
> us ditch currying in some future version of Swift and move to full-blown 
> partial application instead. We would need variadic generics if we wanted to 
> expose them as nicely-typed objects as we do with KeyPaths.
> 
> Anyway, I think what you want is something like this (where VirtualKeyPath is 
> a custom subclass of KeyPath which is lazily-evaluated using a closure).
> 
> extension KeyPath where Value: Collection {
> func map(_ descendent: KeyPath) -> VirtualKeyPath 
> {
> return VirtualKeyPath { 
> (obj: Root) -> [T] in obj[keypath: self].map { $0[keypath: 
> descendent] } 
> }
> }
> }
> 
> \Department.people.map(\.fullName).characters.count  // type: 
> VirtualKeyPath
> 
> 
> Custom subclasses of KeyPath are not allowed, so you can’t actually do this. 
> I don’t know, maybe it wouldn’t be much overhead to add the one, 
> closure-based VirtualKeyPath — clearly the architecture is meant to be 
> flexible. Maybe it’s better to wait until Swift 5 for that, though.
> 
> - Karl

Two corrections to myself:

1) It’s KeyPath

2) You could implement VirtualKeyPath today, but you wouldn’t get the chaining 
syntax. You’d have to just keep map-ping it every time:

\Department.people.map(\.fullName).map(\.characters.count)  // type: 
VirtualKeyPath

- Karl

> 
>> On Wed, Jun 7, 2017 at 6:11 PM Xiaodi Wu via swift-evolution 
>> > wrote:
>> +1. Would think that all variants should exist on Optional too unless it 
>> would be harmful.
>> On Wed, Jun 7, 2017 at 20:13 Michael J LeHew Jr via swift-evolution 
>> > wrote:
>> This is a great idea, and ought to be easy enough to bring forward!  +1 from 
>> me!
>> 
>> -Michael
>> 
>> > On Jun 7, 2017, at 11:18 AM, Matt Diephouse via swift-evolution 
>> > > wrote:
>> >
>> > 
>> >
>> >> 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 great 
>> >> addition to Swift.
>> >>
>> >> It seems like it might be straightforward to add overloads of `map` and 
>> >> `flatMap` to the standard library to make use of the new functionality:
>> >>
>> >>  let managers = flatOrganisation.managers
>> >>  let allEmployees = Set(managers.flatMap(\.directReports))
>> >>  let employeeNames = Set(allEmployees.map(\.name))
>> >>
>> >> This feels like a really natural way of working with key paths in a 
>> >> functional style. It makes a lot of sense for collections, and possibly 
>> >> for Optional too (although as far as I can see optional chaining is more 
>> >> or less equivalent, and with more compact syntax).
>> >>
>> >> I’m hoping that this might be low-hanging fruit that could be considered 
>> >> for the Swift 4 release. I’d be happy to have a go at writing a proposal 
>> >> if there’s interest!
>> >>
>> >> –Adam
>> >>
>> >> ___
>> >> swift-evolution mailing list
>> >> swift-evolution@swift.org 
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> >> 
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org 
>> > 

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

[Karl Wagner via swift-evolution]

> 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 
> 
>  (once it gets implemented), because passing keypaths (i.e., unbound property 
> references) and unbound parameterless method references to map/flatMap would 
> look nearly the same:
> 
> ```
> struct Person {
>   let firstName: String
>   let lastName: String
>   func fullName() -> String { return "\(firstName) \(lastName)" }
> }
> 
> let people: [Person]
> let firstNames = people.map(\.firstName)
> let fullNames = people.map(Person.fullName)  // because after SE-0042, this 
> will be (Person) -> String, not (Person) -> () -> String
> ```
> 
> Especially if there's a move in the future to also use \. to denote unbound 
> methods references, which was discussed during the keypath reviews. (Even 
> with that, I believe it would be more work though to get rid of the explicit 
> type name in the function case.)
> 
> 

When it comes to unbound method references, personally, I would love to see us 
ditch currying in some future version of Swift and move to full-blown partial 
application instead. We would need variadic generics if we wanted to expose 
them as nicely-typed objects as we do with KeyPaths.

Anyway, I think what you want is something like this (where VirtualKeyPath is a 
custom subclass of KeyPath which is lazily-evaluated using a closure).

extension KeyPath where Value: Collection {
func map(_ descendent: KeyPath) -> VirtualKeyPath {
return VirtualKeyPath { 
(obj: Root) -> [T] in obj[keypath: self].map { $0[keypath: 
descendent] } 
}
}
}

\Department.people.map(\.fullName).characters.count  // type: 
VirtualKeyPath


Custom subclasses of KeyPath are not allowed, so you can’t actually do this. I 
don’t know, maybe it wouldn’t be much overhead to add the one, closure-based 
VirtualKeyPath — clearly the architecture is meant to be flexible. Maybe it’s 
better to wait until Swift 5 for that, though.

- Karl

> On Wed, Jun 7, 2017 at 6:11 PM Xiaodi Wu via swift-evolution 
> > wrote:
> +1. Would think that all variants should exist on Optional too unless it 
> would be harmful.
> On Wed, Jun 7, 2017 at 20:13 Michael J LeHew Jr via swift-evolution 
> > wrote:
> This is a great idea, and ought to be easy enough to bring forward!  +1 from 
> me!
> 
> -Michael
> 
> > On Jun 7, 2017, at 11:18 AM, Matt Diephouse via swift-evolution 
> > > wrote:
> >
> > 
> >
> >> 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 great 
> >> addition to Swift.
> >>
> >> It seems like it might be straightforward to add overloads of `map` and 
> >> `flatMap` to the standard library to make use of the new functionality:
> >>
> >>  let managers = flatOrganisation.managers
> >>  let allEmployees = Set(managers.flatMap(\.directReports))
> >>  let employeeNames = Set(allEmployees.map(\.name))
> >>
> >> This feels like a really natural way of working with key paths in a 
> >> functional style. It makes a lot of sense for collections, and possibly 
> >> for Optional too (although as far as I can see optional chaining is more 
> >> or less equivalent, and with more compact syntax).
> >>
> >> I’m hoping that this might be low-hanging fruit that could be considered 
> >> for the Swift 4 release. I’d be happy to have a go at writing a proposal 
> >> if there’s interest!
> >>
> >> –Adam
> >>
> >> ___
> >> 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 mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

[Jens Persson via swift-evolution]

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 better. It was possible to escape the ugly special case of the
first parameter, after all.

Similarly, I wonder if the parentheses-related mess actually can be simpler
and more uniform, after all. I remember a lot of discussions in which
people argued that Swift couldn't and/or shouldn't get rid of the special
first parameter label rules.

I'm not a compiler hacker and I have no idea exactly what aspects of the
language is easy/hard/impossible to change once Swift is binary stable.

My concrete concerns are that the messy parentheses-related parts of the
language will continue to be messy for ever.
I have no idea if there is any actual reason to worry about that, but ABI
stability was originally intended for Swift 3, and then it was postponed
because some stuff needed to be done before ABI stability. Now I'm just
worried that solving the parentheses situation is something that needs to
be done before ABI stability. Please correct/enlighten me!

/Jens



On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman 
wrote:

>
>
> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> 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 functions.
> This was possible in Swift 3, but in Swift 4 it will only work for
> functions with exactly one parameter. You'd have to special-case it for
> every combination of parameter counts of f and g that it should be able to
> handle.
>
> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
>
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> let squaredSum = compose(square, sum)
> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but
> ok ...
> print(result) // 49
> // Well, it worked, not flawlessly but we did manage to write
> // a function composition function and we composed sum
> // and square, and we could call it and get a correct result.
>
>
> And this program demonstrates what happens if you try it in Swift 4:
>
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> // let squaredSum = compose(square, sum) // Error! (without the
> compose-variant below)
>
> // The error message is:
> // Cannot convert value of type `(Int, Int) -> Int` to
> // expected argument type `(_) -> _`
>
> // That's it, it is simply not possible!
>
> // You'd have to write special variants of the compose func for every
> combination
> // of parameter counts! For example, in order to get this sum and square
> // example working, this specific variant must be written:
> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) ->
> V) -> (T, U) -> W {
> return { (x, y) in g(f(x, y)) }
> }
> // Now it will work:
> let squaredSum = compose(square, sum)
> // But only thanks to that awfully specific compose func variant ...
> // We would have to write a lot more variants for it to be practically
> usable on pretty much any common function.
>
> I'm sure some will say:
> "no regular developers use function composition anyway so why ..."
> or
> "It's not very swifty to use free functions and higher order functions
> like that."
>
> My answer is that this is just a simple but telling example. The issue (as
> I see it) exists in all situations involving generics and function types.
>
> I'm a regular programmer and I like to be able to write basic, useful
> abstractions.
> It's no fun when the language forces you to write lots of specific
> variants of your generic code.
>
> I would feel less worried about the parentheses situation if the language
> was going in a direction where you could see how this simple exercise would
> be a no brainer.
>
> Can Swift's parentheses-situation be sorted out before ABI stability?
> Otherwise it would be a bit like if Swift had kept the special rule for
> the first parameter, only much worse.
>
>
> Out of curiosity, how do you think this would impact ABI? What are your
> concrete concerns here?
>
> I don't think the analogy of first parameter label is relevant, as that
> needn't be ABI.
>
> /Jens
>
>
>
>
> On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan 
> wrote:
>
>> Yes, except why would you need to define `((A, B)) -> C`?, If you need to
>> pass a 2-element tuple 

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

[David Waite via swift-evolution]

> 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 really wish swift used the concept of tuples **exclusively** for all 
> purposes that involve parentheses, as well as dividing tuples into two 
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.
> - All closures (a.k.a. function pointers) take exactly one parameter, which 
> is a bare tuple.

A function would need to support a nonassignable, superset tuple in some cases 
such as:
- non-escaping functions
- inout parameters

> - All functions return exactly one parameter, which is a tuple.

Is or could be? Are you defining inout parameters as syntactically hidden 
return values?

-DW


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

Re: [swift-evolution] Introduction of OrderedSet

[Douglas Gregor via swift-evolution]

> 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 resources to design 
> and implement were not then available.
> 
> So, little point in having a vote as to whether one is in favor of OrderedSet 
> or not. In my view, the questions to be answered are:
> 
> For the core team–
> 
> * Is it still the plan to offer value types postponed from SE-0069 as a 
> future addition to Foundation?

*I* think it’s still a good idea, and I suspect that others on the core team 
will agree.

> * If so, is that a priority in the Swift 5 timeframe, and how can the 
> community help to bring about this addition?

I wouldn’t consider it a “priority”, in the sense that I can’t imagine anything 
in Swift 5 that would absolutely require us to introduce this functionality in 
that time frame. It’s a bit of a nice-to-have-at-any-point, noting of course 
that bridging NSOrderedSet in existing APIs is a nontrivial source-breaking 
change.

Having a proposed API and implementation on hand makes it easier to add this 
functionality, of course.

> If not, for the whole community–
> 
> * Is it wise to implement such a type in the standard library? Should we 
> simply bring over the native implementation from Swift Package Manager? What 
> are the implications for bridging?

Obviously, we’d want an efficient copy-on-write, native implementation; the 
Swift Package Manager implementation is a bit more bare-bones than we’d want: 
absolute performance matters, so having a separate Set + Array in the struct 
probably isn’t good enough. Bridging performance matters, so we’d probably want 
the one-pointer representation like array uses where the pointer can be vended 
directly to Objective-C.

- Doug

> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
> > wrote:
> +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, 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 been available.
>>> 
>>> 
>>> Jeff Kelley
>>> 
>>> slauncha...@gmail.com  | @SlaunchaMan 
>>>  | jeffkelley.org 
 On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
 > wrote:
 
 Hello,
 
 in the past there have been a few requests for an OrderedSet 
 implementation in Swift. In the proposal 
 https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
  
 
  was mentioned that the OrderedSet will be considered for the feature.
 
 However, since then there were a few discussions on OrderedSet but it 
 doesn’t get much attention and there wasn’t any comment about it from the 
 swift team.
 
 I want to bring up some points, why an OrderedSet is needed in the base 
 library.
 
 1. CoreData is probably the most obvious place where people would use an 
 ordered set. Especially when working with large amounts of data, 
 presorting can save a lot of time and battery life. If a bridgeable 
 ordered set was part of the standard library we could use a ordered set in 
 swift without having to use the NSOrderedSet from objective c. Which would 
 be pretty nice in my opinion. Even when using a NSOrderedSet we couldn’t 
 have a generic version of it.
 
 2. A shared datamodel between App and Server. One main advantage of having 
 web servers written in Swift is that we can share code between the server 
 and the app. For servers performance does matter a lot, since they are 
 usually working with much more data than apps. Databases are represented 
 as sets and fetching sorted data from the database can be represented as 
 an ordered set. However, since we don’t have ordered sets we have to 
 choose either a normal set or an array. Sets don’t have an order and 
 arrays can contain the same object multiple times, which makes them both a 
 less suitable choice.
 
 3. Swift has the potential to be used for education. There is a lot of 

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

[Max Moiseev via swift-evolution]

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 great 
> addition to Swift.
> 
> It seems like it might be straightforward to add overloads of `map` and 
> `flatMap` to the standard library to make use of the new functionality:
> 
>   let managers = flatOrganisation.managers
>   let allEmployees = Set(managers.flatMap(\.directReports))
>   let employeeNames = Set(allEmployees.map(\.name))
> 
> This feels like a really natural way of working with key paths in a 
> functional style. It makes a lot of sense for collections, and possibly for 
> Optional too (although as far as I can see optional chaining is more or less 
> equivalent, and with more compact syntax).
> 
> I’m hoping that this might be low-hanging fruit that could be considered for 
> the Swift 4 release. I’d be happy to have a go at writing a proposal if 
> there’s interest!
> 
> –Adam
> 
> ___
> 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] History and future of Swift's parentheses

[Michael Ilseman via swift-evolution]

> 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 functions.
> This was possible in Swift 3, but in Swift 4 it will only work for functions 
> with exactly one parameter. You'd have to special-case it for every 
> combination of parameter counts of f and g that it should be able to handle.
> 
> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
> 
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> let squaredSum = compose(square, sum)
> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but ok 
> ...
> print(result) // 49
> // Well, it worked, not flawlessly but we did manage to write
> // a function composition function and we composed sum
> // and square, and we could call it and get a correct result.
> 
>  
> And this program demonstrates what happens if you try it in Swift 4:
> 
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> // let squaredSum = compose(square, sum) // Error! (without the 
> compose-variant below)
> 
> // The error message is:
> // Cannot convert value of type `(Int, Int) -> Int` to
> // expected argument type `(_) -> _`
> 
> // That's it, it is simply not possible!
> 
> // You'd have to write special variants of the compose func for every 
> combination
> // of parameter counts! For example, in order to get this sum and square
> // example working, this specific variant must be written:
> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> V) 
> -> (T, U) -> W {
> return { (x, y) in g(f(x, y)) }
> }
> // Now it will work:
> let squaredSum = compose(square, sum)
> // But only thanks to that awfully specific compose func variant ...
> // We would have to write a lot more variants for it to be practically usable 
> on pretty much any common function.
> 
> I'm sure some will say:
> "no regular developers use function composition anyway so why ..."
> or
> "It's not very swifty to use free functions and higher order functions like 
> that."
> 
> My answer is that this is just a simple but telling example. The issue (as I 
> see it) exists in all situations involving generics and function types.
> 
> I'm a regular programmer and I like to be able to write basic, useful 
> abstractions.
> It's no fun when the language forces you to write lots of specific variants 
> of your generic code.
> 
> I would feel less worried about the parentheses situation if the language was 
> going in a direction where you could see how this simple exercise would be a 
> no brainer.
> 
> Can Swift's parentheses-situation be sorted out before ABI stability?
> Otherwise it would be a bit like if Swift had kept the special rule for the 
> first parameter, only much worse.
> 

Out of curiosity, how do you think this would impact ABI? What are your 
concrete concerns here?

I don't think the analogy of first parameter label is relevant, as that needn't 
be ABI. 

> /Jens
> 
> 
> 
> 
>> On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan  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 into a function that  *looks* like it takes a 
>> single 2-element tuple - you can! Seems to me that the difference between 
>> `((A, B)) -> C` and `(A, B) -> C` is virtually non-existent. But keep in 
>> mind that this only works for bare tuples (the ones that can't have labels). 
>> Non-closure functions DO have labels, which is part of their signature, so 
>> this is a different story.
>> 
 On Jun 9, 2017, at 6:18 PM, Gwendal Roué  wrote:
 
 
> 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 tuples **exclusively** for all 
 purposes that involve parentheses, as well as dividing tuples into two 
 categories:
 - Bare tuples, which do not have labels.
 - Rich tuples, which do.
 As a consequence, here's a list of statements that would become true:
 - All functions take exactly one parameter, which is a tuple.
 - All closures (a.k.a. function pointers) take exactly one parameter, 

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

[Robert Bennett via swift-evolution]

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 arguments to the function will be packed into a 
tuple (or not, in the case of a single-argument function) whose type is denoted 
by T, U, V, or conversely that the functions take/return argument lists that 
look like *T, *U, *V where T, U, V are tuple types. Then the function 
definition would look like

{
return { x: *T in g(f(x)) }
}

This would in essence create a new non nominal type: function argument lists. 
These would be distinct from tuples, although the two may freely be converted 
into one another using the asterisk. This type would be structurally distinct 
from tuples by virtue of the fact that single-element argument lists exist 
while single-element tuples do not. (An asterisk will convert a single-element 
argument list into a single (non-tuple) element and vice versa.)

To users, argument lists would be accessed solely through tuples with the 
asterisk syntax. The identity **T == T would hold whenever T is a tuple or 
argument list. Their usefulness would lie in the ability to call f(*x) when f 
takes multiple arguments and x is a tuple.

I acknowledge that this is probably not going to happen for Swift 4 but I would 
sure like it if it did.

> On Jun 9, 2017, at 5: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 functions.
> This was possible in Swift 3, but in Swift 4 it will only work for functions 
> with exactly one parameter. You'd have to special-case it for every 
> combination of parameter counts of f and g that it should be able to handle.
> 
> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
> 
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> let squaredSum = compose(square, sum)
> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but ok 
> ...
> print(result) // 49
> // Well, it worked, not flawlessly but we did manage to write
> // a function composition function and we composed sum
> // and square, and we could call it and get a correct result.
> 
>  
> And this program demonstrates what happens if you try it in Swift 4:
> 
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) -> 
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> // let squaredSum = compose(square, sum) // Error! (without the 
> compose-variant below)
> 
> // The error message is:
> // Cannot convert value of type `(Int, Int) -> Int` to
> // expected argument type `(_) -> _`
> 
> // That's it, it is simply not possible!
> 
> // You'd have to write special variants of the compose func for every 
> combination
> // of parameter counts! For example, in order to get this sum and square
> // example working, this specific variant must be written:
> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) -> V) 
> -> (T, U) -> W {
> return { (x, y) in g(f(x, y)) }
> }
> // Now it will work:
> let squaredSum = compose(square, sum)
> // But only thanks to that awfully specific compose func variant ...
> // We would have to write a lot more variants for it to be practically usable 
> on pretty much any common function.
> 
> I'm sure some will say:
> "no regular developers use function composition anyway so why ..."
> or
> "It's not very swifty to use free functions and higher order functions like 
> that."
> 
> My answer is that this is just a simple but telling example. The issue (as I 
> see it) exists in all situations involving generics and function types.
> 
> I'm a regular programmer and I like to be able to write basic, useful 
> abstractions.
> It's no fun when the language forces you to write lots of specific variants 
> of your generic code.
> 
> I would feel less worried about the parentheses situation if the language was 
> going in a direction where you could see how this simple exercise would be a 
> no brainer.
> 
> Can Swift's parentheses-situation be sorted out before ABI stability?
> Otherwise it would be a bit like if Swift had kept the special rule for the 
> first parameter, only much worse.
> 
> /Jens
> 
> 
> 
> 
>> On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan  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 

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

[Yvo van Beek via swift-evolution]

@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

for this

@Will:

Your solution of creating a HeaderKey struct resolves most issues, but has
a few downsides:
1) the HeaderKey struct would contain quite some boilerplate code that
mimics String (Equality, CustomStringConvertible etc.)
2) the ExpressibleByStringLiteral enables the use of static strings, but a
dynamic string would need to be wrapped: HeaderKey(dynamicHeader) leading
to clunky code
3) the headers dictionary would become more difficult to process, the key
would no longer be an actual String, resulting in more code that distracts
from the actual code

Thanks everyone for chiming in on this.


On Fri, Jun 9, 2017 at 11:41 AM, Will Field-Thompson 
wrote:

> 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(_ value: String) { self.value = value }
>/* Possibly insert methods from String here, possibly do something
> else, whatever */
> }
>
> I've always thought this might be interesting, but there's a few reasons I
> suggest it in place of extending a typealias:
> 1) Backwards compatibility — this could very easily break existing code
> 2) Semantically it seems to me that an *alias* is a useful distinction
> from *"let's make a new type" *— sometimes you actually just want to call
> one type by another name in some context
>
> Regardless, I think you could solve your particular problem like this:
>
> public struct HeaderKey {
>let value: String
>public init(_ value: String) { self.value = value }
> }
>
> and conform HeaderKey to ExpressibleByStringLiteral. That way your
> framework's users can still use headers[.lastModified] and
> headers["X-MyHeader"] syntax, and it makes your library's code only very
> slightly more complicated.
>
> Not trying to tell you how to write your library, but this approach worked
> really well for me recently.
>
> Best,
>
> Will
>
> On Fri, Jun 9, 2017 at 12:14 AM Yvo van Beek via swift-evolution <
> swift-evolution@swift.org> 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.
>>
>> Let's say I'm creating a web server framework and I've created a simple
>> dictionary to store HTTP headers (I know that headers are more complex than
>> that, but as an example). I could write something like this:
>>
>> typealias HeaderKey = String
>>
>>   var headers = [HeaderKey: String]()
>>   headers["Host"] = "domain.com"
>>
>> Now I can define a couple of default headers like this:
>>
>>   extension HeaderKey {
>> static var lastModified: String { return "Last-Modified" }
>> static var host: String { return "Host" }
>>   }
>>
>> After that I can do this:
>>
>>   var headers = [HeaderKey: String]()
>>   headers[.host] = "domain.com"
>>   headers[.lastModified] = "some date"
>>   headers["X-MyHeader"] = "This still works too"
>>
>> But unfortunately the extension is also applied to normal strings:
>>
>> var normalString: String = .host
>>
>> Perhaps it would be better if the extension would only apply to the parts
>> of my code where I use the HeaderKey typealias and not to all Strings. This
>> could be a great tool to specialize classes by creating a typealias and
>> adding functionality to it. Another example I can think of is typealiases
>> for dictionaries or arrays with added business logic through extensions
>> (especially since you can't inherit from structs).
>>
>> If you want to create an extension that adds functionality to all Strings
>> you could have created an extension for String instead of HeaderKey.
>>
>> Please let me know what you think. I'm not sure how complex this change
>> would be.
>> I could write a proposal if you're interested.
>>
>> Kind regards,
>> Yvo
>> ___
>> 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] History and future of Swift's parentheses

[Gor Gyolchanyan via swift-evolution]

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++ 
terminology) to potentially huge inout expressions, not to mention returning an 
inout from a function, effectively spreading the getter-setter awesomeness to 
everything else besides properties and subscripts.

As for variadic parameters: currently they are what I call a "dead end 
feature", meaning that there is no way to propagate them further and abstract 
them away, because you can't "unpack" a sequence into a variadic parameter (the 
way you can in Python with the prefix `*`), so my answer to that would also be 
to promote it to its own Sequence protocol conforming compiler-magic structure, 
which would also become part of the type system and alleviate the problem.

> On Jun 9, 2017, at 11:07 PM, David Sweeris  wrote:
> 
>> 
>> 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 tuples **exclusively** for all 
>> purposes that involve parentheses, as well as dividing tuples into two 
>> categories:
>> - Bare tuples, which do not have labels.
>> - Rich tuples, which do.
>> As a consequence, here's a list of statements that would become true:
>> - All functions take exactly one parameter, which is a tuple.
> 
> That’s what we used to do. It caused problems with other language features 
> (“inout" and “variadic" parameters were the two big ones, IIRC).
> 
> - Dave Sweeris

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

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

[Karl Wagner via swift-evolution]

> 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 
>> members on Foo?
> 
> Yeah.  Previous discussions of newtype have usually led to discussion of ways 
> to forward using a protocol-oriented approach.  Nothing has gotten too far, 
> but it usually comes up that suppressing undesired members is important.
> 
> It is also important to have some way to distinguish between members with a 
> parameter of the underlying type from members that should be treated by 
> newtype as Self parameters.  The mechanism we have for doing that in Swift 
> happens to be a protocol.

It’s important to note that you can create powerful quasi-subtype relationships 
using composition. This is going to be a little divergent, but this is WWDC 
week and everybody’s here, and its related to the topic of architecture with 
value-types.

The only practical difference between composition and subclassing is that you 
can’t add storage and have it carried along with the original “instance”. I’m 
not even sure that really makes sense for value types, which don’t have 
identity — the alternative, that a value is be composed of sub-values, makes 
more sense to me.

I’ve recently converted an entire project from using class hierarchies and 
stacks of protocols down to a handful of protocols and value-types. I cut the 
number of files in half, reduced duplicated logic, increased testability, 
maintainability, all kinds of good stuff. I’m pretty happy with how it turned 
out, so let me very briefly outline how I did it, to give a concrete example of 
the kinds of things you can do with composition.

The new data subsystem of this App is now entirely stateless - ultimately, if 
you look through all of the wrappers, we’re literally just passing around a 
handful of “let” variables (api endpoint, api key, login key, and a cache 
identifier), and the entire framework boils down to isolated islands of 
business logic written in extensions on those structs.

There are only two really important protocols: an ObjectStore (i.e. a cache) 
and an ObjectSource (i.e. the API). They have very generic methods, like 
“fetch”, “put” and “delete”. All of the business logic about which queries to 
run on the cache, and where to put the data, or how to query the correct data 
out of the API, is written in a collection of wrapper structs which you access 
to via a computed property (a kind of namespaced protocol-extension, e.g. 
myObjectStore.userInformation). Above the source and store (i.e. wrapping them) 
sits a Repository struct, which coordinates getting data from the ObjectStore, 
querying for that data from the ObjectSource if it doesn’t have anything (or if 
its expired), and returns a future (actually it’s a Reactive Observable, but 
any kind of future-like-object will do) encapsulating the operation. 

There’s lots you can do with value-types. For example, I created a wrapper for 
the top-level “Session” type which dynamically checks if the session belongs to 
a logged-in user. There is a separate repository for public data (e.g. store 
locations) and private data (e.g. purchase history), and we can model all of 
this separation really easily in the type-system with no cognitive or 
computational overhead.

/// An API session, which may or may not belong to a logged-in user.
///
struct Session {
typealias Identity = (loginKey: String, cacheIdentifier: String)

let configuration: SessionConfiguration // creates repository on behalf of 
the session, for unit-testing.
let identity: Identity?
let publicData: PublicDataRepository

init(configuration: SessionConfiguration, identity: Identity) {
self.configuration = configuration
self.identity  = identity
self.publicData= configuration.makePublicRepository()
}
}

/// A session which is dynamically known to belong to a logged-in user.
///
struct AuthenticatedSession {

let base: Session // you can think of this like ‘super’
let privateData: PrivateDataRepository

init?(base: Session) {
guard let identity = base.identity else { return nil }
self.base   = base
privateData = base.configuration.makePrivateRepository(for: identity)
}
}

/* methods which do not require authentication */

extension Session { 
func getStoreLocations() -> Future<[StoreLocation]> { … }
 }

/* methods which require a logged-in user */

extension AuthenticatedSession {  
func buySomething(_: ThingToBuy) -> Future { … }
}

When it comes to storage, AuthenticatedSession not having the same memory 
layout as Session means you can’t store one variable that could be either — 
unless you box it. You can use a protocol to create a semantically-meaningful 
box (e.g. PublicDataProvider, with one computed 

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

[Gor Gyolchanyan via swift-evolution]

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 something or composed it 
wrong, so please feel free to comment, fork and send pull requests. 

> On Jun 9, 2017, at 3:24 PM, Xiaodi Wu  wrote:
> 
> 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, 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 the signature:
> 
> mutating func `init`() -> Self?
> 
> Which would make the returned result optional, but leave `self` non-optional.
> This would make `return nil` less out-of-place, like you said, while still 
> leaving `self` as a set-exactly-once `inout Self`.
> A factory initializer would then have the signature:
> 
> static func `init`(...) -> Self
> 
> or in case of a failable factory initializer:
> 
> static func `init`(...) -> Self?
> 
> Which would still make sense with the now legal `return ...` syntax, while 
> adding the restriction of not having any `self` at all.
> So, annotating the initializer with the keyword `factory` would cause it to 
> change the signature as well as remove any compiler assumptions about the 
> dynamic type of the returned instance.
> 
> In addition, idea #3 would be available for more deterministic in-place 
> initialization.
> 
>> On Jun 9, 2017, at 2:47 PM, Xiaodi Wu > > wrote:
>> 
>> 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 `return nil` is just as much of a special 
>> rule and is also largely counter-intuitive.
>> 
>> `return nil` is “special,” but it doesn’t conflict with any other syntax 
>> because the initializer notionally has no return value. Personally, I have 
>> always disliked `return nil` in failable initializers for that reason, but I 
>> couldn’t come up with a better alternative.
>> 
>> Your proposed idea to allow returning any value is interesting because, in 
>> the case of a failable initializer, `return nil` continues to have the same 
>> meaning if we consider the return value of the initializer to be of type 
>> `Self?`. For that reason, I think your idea #2 is quite clever, and it would 
>> go a long way in making `return nil` a lot less odd. It also increases the 
>> expressivity of initializers because it allows one to set the value of self 
>> and also return in one statement, clearly demonstrating the intention that 
>> no other code in the initializer should be run before returning.
>> 
>> For all of those reasons, I think idea #2 is a winning idea.
>> 
>> The benefit of `self = nil` is that it's much more in line with 
>> initialization semantics, it provides more uniform syntax and it's a bit 
>> less restrictive.
>> 
>> 2. It's an `inout Self!`, like Greg said, which can be seen as more 
>> cumbersome. Implicitly unwrapped optionals are a bit difficult, but this 
>> "variation" of it is much more restrictive then the normal ones, because 
>> unlike normal implicitly unwrapped optionals, this one cannot be accessed 
>> after being assigned nil (and it also cannot be indirectly assigned `nil`, 
>> because escaping `self` is not allowed before full initialization), so there 
>> is only one possible place it can be set to nil and that's directly in the 
>> initializer. This means that `self` can be safely treated as `inout Self` 
>> before being set to nil (and after being set to nil, it doesn't matter any 
>> more because you aren't allowed to access it, due to not being fully 
>> initialized).
>> 
>> I have to say, I don’t like either of these explanations at all. I think 
>> having a “special” IUO is a difficult sell; it is just conceptually too 
>> complicated, and I don’t agree that it gains you much.
>> 
>> By your own admission, `self = nil` is wonky, and making the language 
>> wonkier because it currently has a parallel wonky feature in `return nil` 
>> seems like the wrong way to go. In addition, there’s nothing gained here 
>> that cannot be done with a defer statement; of course, defer statements 
>> might not be very 

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

[Jens Persson via swift-evolution]

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 have to special-case it for
every combination of parameter counts of f and g that it should be able to
handle.

The following program demonstrates how it can be done in Swift 3.1 and 3.2:

func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
(T) -> V {
return { x in g(f(x)) }
}
func sum(_ a: Int, _ b: Int) -> Int { return a + b }
func square(_ a: Int) -> Int { return a * a }
let squaredSum = compose(square, sum)
let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but
ok ...
print(result) // 49
// Well, it worked, not flawlessly but we did manage to write
// a function composition function and we composed sum
// and square, and we could call it and get a correct result.


And this program demonstrates what happens if you try it in Swift 4:

func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
(T) -> V {
return { x in g(f(x)) }
}
func sum(_ a: Int, _ b: Int) -> Int { return a + b }
func square(_ a: Int) -> Int { return a * a }
// let squaredSum = compose(square, sum) // Error! (without the
compose-variant below)

// The error message is:
// Cannot convert value of type `(Int, Int) -> Int` to
// expected argument type `(_) -> _`

// That's it, it is simply not possible!

// You'd have to write special variants of the compose func for every
combination
// of parameter counts! For example, in order to get this sum and square
// example working, this specific variant must be written:
func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) ->
V) -> (T, U) -> W {
return { (x, y) in g(f(x, y)) }
}
// Now it will work:
let squaredSum = compose(square, sum)
// But only thanks to that awfully specific compose func variant ...
// We would have to write a lot more variants for it to be practically
usable on pretty much any common function.

I'm sure some will say:
"no regular developers use function composition anyway so why ..."
or
"It's not very swifty to use free functions and higher order functions like
that."

My answer is that this is just a simple but telling example. The issue (as
I see it) exists in all situations involving generics and function types.

I'm a regular programmer and I like to be able to write basic, useful
abstractions.
It's no fun when the language forces you to write lots of specific variants
of your generic code.

I would feel less worried about the parentheses situation if the language
was going in a direction where you could see how this simple exercise would
be a no brainer.

Can Swift's parentheses-situation be sorted out before ABI stability?
Otherwise it would be a bit like if Swift had kept the special rule for the
first parameter, only much worse.

/Jens




On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan  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 into a function that  *looks* like it takes
> a single 2-element tuple - you can! Seems to me that the difference between
> `((A, B)) -> C` and `(A, B) -> C` is virtually non-existent. But keep in
> mind that this only works for bare tuples (the ones that can't have
> labels). Non-closure functions DO have labels, which is part of their
> signature, so this is a different story.
>
> On Jun 9, 2017, at 6:18 PM, Gwendal Roué  wrote:
>
>
> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> 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 tuples **exclusively** for all
> purposes that involve parentheses, as well as dividing tuples into two
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.
> - All closures (a.k.a. function pointers) take exactly one parameter,
> which is a bare tuple.
> - All functions return exactly one parameter, which is a tuple.
> - Pattern matching is done on a single bare tuple using a single bare
> tuple pattern.
>
> The currently ongoing proposal to make a single-element tuple auto-flatten
> would work extremely well with this idea, by making all these changes
> completely backward-compatible.
>
>
> If I have well understood, Swift has evolved away from this.
>
> If what you describe were true, added to the fact that there is no such
> thing as a one-element tuple in the language, then (A,B) -> C 

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

[Tony Allevato via swift-evolution]

+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 particular
property (the underlying String, or whatever) and the compiler will
synthesize the protocol member stubs on the new type.

There are definitely finer details to be worked out but that's a rough
sketch of how I've been imagining it could work. Nice advantages include
(1) if there already exists a protocol that defines the exact operations
you want to forward, you can skip step 2, and (2) it's explicit/opt-in
synthesis where you have to provide the members to forward (this is
expected, at a minimum), but you don't have to write all the boilerplate
implementations.


On Fri, Jun 9, 2017 at 12:47 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> 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 led to discussion of
> ways to forward using a protocol-oriented approach.  Nothing has gotten too
> far, but it usually comes up that suppressing undesired members is
> important.
>
> It is also important to have some way to distinguish between members with
> a parameter of the underlying type from members that should be treated by
> newtype as Self parameters.  The mechanism we have for doing that in Swift
> happens to be a protocol.
>
> 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 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 be subtyped because their
>>> size must be known at compile time. I don’t know the implementation details
>>> of where functions and computed properties live, but something tells me
>>> they belong to the type and not the object (although I’ve never really made
>>> the effort to sit down and fully understand Swift’s type model), in which
>>> case adding them to a struct’s definition would not change the size of the
>>> object on the stack. Thus it should be possible to make custom substructs
>>> of String that add additional functionality but no new stored properties.
>>> Thoughts?
>>>
>>
>> Value subtyping is a large subject and, IIUC, newtype would be a subset
>> of that topic. Unlikely to be in scope for Swift 5, though, but that’s up
>> to the core team.
>>
>>
>> I see newtype as being more related to forwarding than subtyping.
>> Usually you want to hide significant parts of the interface to the wrapped
>> type.
>>
>>
>>
>> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <
>>> swift-evolution@swift.org> 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)
>>> typealias XUView = UIView
>>> #else
>>> typealias XUView = NSView
>>> #endif
>>>
>>> extension XUView {
>>> ...
>>> }
>>>
>>>
>>> I really don’t see how this disallows code sharing between the two
>>> systems? Could you explain further? Based on my understanding of the pitch,
>>> this is valid code still. (Although I do like the suggestion of a new
>>> keyword rather than just limiting type alias).
>>>
>>> Even if your example was invalid, you could also just do something like
>>> this:
>>>
>>> #if os(iOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> //extension code here
>>> }
>>> #if os(macOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> // extension code here
>>> }
>>> #endif
>>>
>>> While not as pretty, still just as effective if you have to deal with
>>> different types based on the system being compiled for and you could easily
>>> still make the type alias extensions for each type work the same.
>>>
>>> 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 {
>>> ...
>>> }
>>>
>>> or with any similar compatibility typealiases.
>>>
>>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> +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 

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

[Matthew Johnson via swift-evolution]

> 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 conform to this 
> protocol.
> 3) In your new type, tell it to forward protocol members for a particular 
> property (the underlying String, or whatever) and the compiler will 
> synthesize the protocol member stubs on the new type.
> 
> There are definitely finer details to be worked out but that's a rough sketch 
> of how I've been imagining it could work. Nice advantages include (1) if 
> there already exists a protocol that defines the exact operations you want to 
> forward, you can skip step 2, and (2) it's explicit/opt-in synthesis where 
> you have to provide the members to forward (this is expected, at a minimum), 
> but you don't have to write all the boilerplate implementations.

I have a mostly finished second draft of a protocol-oriented forwarding 
proposal which is pretty similar to what you describe here.  The most important 
difference is that while protocols are used to perform forwarding neither type 
is required to actually conform to the protocol.  

That turns out to be pretty important when you think about edge cases.  
Sometimes you don’t actually want the forwardee to conform (that’s probably why 
you said internal / fileprivate).  Sometimes you also don’t want the forwarder 
to conform.  IIRC, there are also cases where it cannot conform (I would have 
to dig up the proposal to recall the details).

> 
> 
> On Fri, Jun 9, 2017 at 12:47 PM 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 
>> members on Foo?
> 
> Yeah.  Previous discussions of newtype have usually led to discussion of ways 
> to forward using a protocol-oriented approach.  Nothing has gotten too far, 
> but it usually comes up that suppressing undesired members is important.
> 
> It is also important to have some way to distinguish between members with a 
> parameter of the underlying type from members that should be treated by 
> newtype as Self parameters.  The mechanism we have for doing that in Swift 
> happens to be a protocol.
> 
>> On Fri, Jun 9, 2017 at 15:18 Matthew Johnson > > wrote:
>>> 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 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 
>>> where functions and computed properties live, but something tells me they 
>>> belong to the type and not the object (although I’ve never really made the 
>>> effort to sit down and fully understand Swift’s type model), in which case 
>>> adding them to a struct’s definition would not change the size of the 
>>> object on the stack. Thus it should be possible to make custom substructs 
>>> of String that add additional functionality but no new stored properties. 
>>> Thoughts?
>>> 
>>> Value subtyping is a large subject and, IIUC, newtype would be a subset of 
>>> that topic. Unlikely to be in scope for Swift 5, though, but that’s up to 
>>> the core team.
>> 
>> I see newtype as being more related to forwarding than subtyping.  Usually 
>> you want to hide significant parts of the interface to the wrapped type.
>> 
>>> 
>>> 
>>> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution 
>>> > 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)
>   typealias XUView = UIView
> #else
>   typealias XUView = NSView
> #endif
> 
> extension XUView {
>   ...
> }
 
 I really don’t see how this disallows code sharing between the two 
 systems? Could you explain further? Based on my understanding of the 
 pitch, this is valid code still. (Although I do like the suggestion of a 
 new keyword rather than just limiting type alias).
 
 Even if your example was invalid, you could also just do something like 
 this:
 
 #if os(iOS)

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

[Xiaodi Wu via swift-evolution]

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 led to discussion of
> ways to forward using a protocol-oriented approach.  Nothing has gotten too
> far, but it usually comes up that suppressing undesired members is
> important.
>

That’s right. These conversations have slipped my mind but that does ring a
bell now.

I think the ask in this thread is for some facility to add members only (or
even, perhaps, to add nothing at all), which would be well served by value
subtyping.

In addition, you’re absolutely right that there’s been discussion of better
ways of forwarding where the starting point is a wrapped type with no
members. Interesting.

It is also important to have some way to distinguish between members with a
> parameter of the underlying type from members that should be treated by
> newtype as Self parameters.  The mechanism we have for doing that in Swift
> happens to be a protocol.
>
> 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 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 be subtyped because their
>>> size must be known at compile time. I don’t know the implementation details
>>> of where functions and computed properties live, but something tells me
>>> they belong to the type and not the object (although I’ve never really made
>>> the effort to sit down and fully understand Swift’s type model), in which
>>> case adding them to a struct’s definition would not change the size of the
>>> object on the stack. Thus it should be possible to make custom substructs
>>> of String that add additional functionality but no new stored properties.
>>> Thoughts?
>>>
>>
>> Value subtyping is a large subject and, IIUC, newtype would be a subset
>> of that topic. Unlikely to be in scope for Swift 5, though, but that’s up
>> to the core team.
>>
>>
>> I see newtype as being more related to forwarding than subtyping.
>> Usually you want to hide significant parts of the interface to the wrapped
>> type.
>>
>>
>>
>> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <
>>> swift-evolution@swift.org> 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)
>>> typealias XUView = UIView
>>> #else
>>> typealias XUView = NSView
>>> #endif
>>>
>>> extension XUView {
>>> ...
>>> }
>>>
>>>
>>> I really don’t see how this disallows code sharing between the two
>>> systems? Could you explain further? Based on my understanding of the pitch,
>>> this is valid code still. (Although I do like the suggestion of a new
>>> keyword rather than just limiting type alias).
>>>
>>> Even if your example was invalid, you could also just do something like
>>> this:
>>>
>>> #if os(iOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> //extension code here
>>> }
>>> #if os(macOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> // extension code here
>>> }
>>> #endif
>>>
>>> While not as pretty, still just as effective if you have to deal with
>>> different types based on the system being compiled for and you could easily
>>> still make the type alias extensions for each type work the same.
>>>
>>> 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 {
>>> ...
>>> }
>>>
>>> or with any similar compatibility typealiases.
>>>
>>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> +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 aliases (and
>>> only the type alias), or if it were possible to inherit from structs so
>>> that we could create a custom string type like so:
>>>
>>> struct HeaderKey: String {
>>> static var lastModified: String { return “Last-Modified” }
>>> static var host: String { return “Host” }
>>> }
>>>
>>> I realize that struct inheritance is far less likely, since that 

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

[Stephen Celis via swift-evolution]

> 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 into a function that  *looks* like it takes a 
> single 2-element tuple - you can! Seems to me that the difference between 
> `((A, B)) -> C` and `(A, B) -> C` is virtually non-existent. But keep in mind 
> that this only works for bare tuples (the ones that can't have labels). 
> Non-closure functions DO have labels, which is part of their signature, so 
> this is a different story.

Exactly. Been trying to communicate this for awhile. The types are almost 
always completely isomorphic and so the distinction barely exists. 
Function-only modifiers (like inout) make things slightly more complicated but 
I don’t think is an insurmountable problem.

Really miss the expressiveness we lost :/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 type would remove the 
> need for the compiler to verify separately that the members exist on the type 
> (because of it conforms, they must, so you get it for free), but I suppose in 
> this case the compiler would just do a separate validation pass.

Yeah, conformance could be used as a shortcut when it exists but requiring it 
is an unnecessary limitation that reduces flexibility and actually prevents 
some uses altogether.

> 
> I'm really looking forward to reading your draft!
> On Fri, Jun 9, 2017 at 12:58 PM Matthew Johnson  > wrote:
>> 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 conform to this 
>> protocol.
>> 3) In your new type, tell it to forward protocol members for a particular 
>> property (the underlying String, or whatever) and the compiler will 
>> synthesize the protocol member stubs on the new type.
>> 
>> There are definitely finer details to be worked out but that's a rough 
>> sketch of how I've been imagining it could work. Nice advantages include (1) 
>> if there already exists a protocol that defines the exact operations you 
>> want to forward, you can skip step 2, and (2) it's explicit/opt-in synthesis 
>> where you have to provide the members to forward (this is expected, at a 
>> minimum), but you don't have to write all the boilerplate implementations.
> 
> I have a mostly finished second draft of a protocol-oriented forwarding 
> proposal which is pretty similar to what you describe here.  The most 
> important difference is that while protocols are used to perform forwarding 
> neither type is required to actually conform to the protocol.  
> 
> That turns out to be pretty important when you think about edge cases.  
> Sometimes you don’t actually want the forwardee to conform (that’s probably 
> why you said internal / fileprivate).  Sometimes you also don’t want the 
> forwarder to conform.  IIRC, there are also cases where it cannot conform (I 
> would have to dig up the proposal to recall the details).
> 
>> 
>> 
>> On Fri, Jun 9, 2017 at 12:47 PM 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 
>>> members on Foo?
>> 
>> Yeah.  Previous discussions of newtype have usually led to discussion of 
>> ways to forward using a protocol-oriented approach.  Nothing has gotten too 
>> far, but it usually comes up that suppressing undesired members is important.
>> 
>> It is also important to have some way to distinguish between members with a 
>> parameter of the underlying type from members that should be treated by 
>> newtype as Self parameters.  The mechanism we have for doing that in Swift 
>> happens to be a protocol.
>> 
>>> On Fri, Jun 9, 2017 at 15:18 Matthew Johnson >> > wrote:
 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 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 
 where functions and computed properties live, but something tells me they 
 belong to the type and not the object (although I’ve never really made the 
 effort to sit down and fully understand Swift’s type model), in which case 
 adding them to a struct’s definition would not change the size of the 
 object on the stack. Thus it should be possible to make custom substructs 
 of String that add additional functionality but no new stored properties. 
 Thoughts?
 
 Value subtyping is a large subject and, IIUC, newtype would be a subset of 
 that topic. Unlikely to be in scope for Swift 5, though, but that’s up to 
 the core team.
>>> 
>>> I see newtype as being more related to forwarding than subtyping.  Usually 
>>> you 

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

[David Sweeris via swift-evolution]

> 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 tuples **exclusively** for all 
> purposes that involve parentheses, as well as dividing tuples into two 
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.

That’s what we used to do. It caused problems with other language features 
(“inout" and “variadic" parameters were the two big ones, IIRC).

- Dave Sweeris

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

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

[Brent Royal-Gordon via swift-evolution]

> 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 next day that they need to prepare for.


Although nobody's set up anything formal, I've created an event on Beacon and 
I'm camping out near the convention center. Anyone from S-E or otherwise 
connected to the development of the Swift language and compiler is welcome to 
join me. I'm in the Peet's near the Hilton right now, but we've moved in the 
past and may move again in the future, so keep an eye on the Beacon event for 
updates.

I ought to look like my Twitter profile picture >. For those who are as faceblind as I am, I'm 
wearing a steel Apple Watch™, a matching ATP Shirt™, and I have a teal jacket. 
(Should have worn my orange Swift t-shirt, but hindsight is 20/20.)

-- 
Brent Royal-Gordon
Architechies

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

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

[Tony Allevato via swift-evolution]

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 on the type (because of it conforms, they must, so you get it for
free), but I suppose in this case the compiler would just do a separate
validation pass.

I'm really looking forward to reading your draft!
On Fri, Jun 9, 2017 at 12:58 PM Matthew Johnson 
wrote:

> 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 conform to this
> protocol.
> 3) In your new type, tell it to forward protocol members for a particular
> property (the underlying String, or whatever) and the compiler will
> synthesize the protocol member stubs on the new type.
>
> There are definitely finer details to be worked out but that's a rough
> sketch of how I've been imagining it could work. Nice advantages include
> (1) if there already exists a protocol that defines the exact operations
> you want to forward, you can skip step 2, and (2) it's explicit/opt-in
> synthesis where you have to provide the members to forward (this is
> expected, at a minimum), but you don't have to write all the boilerplate
> implementations.
>
>
> I have a mostly finished second draft of a protocol-oriented forwarding
> proposal which is pretty similar to what you describe here.  The most
> important difference is that while protocols are used to perform forwarding
> neither type is required to actually conform to the protocol.
>
> That turns out to be pretty important when you think about edge cases.
> Sometimes you don’t actually want the forwardee to conform (that’s probably
> why you said internal / fileprivate).  Sometimes you also don’t want the
> forwarder to conform.  IIRC, there are also cases where it cannot conform
> (I would have to dig up the proposal to recall the details).
>
>
>
> On Fri, Jun 9, 2017 at 12:47 PM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> 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 led to discussion of
>> ways to forward using a protocol-oriented approach.  Nothing has gotten too
>> far, but it usually comes up that suppressing undesired members is
>> important.
>>
>> It is also important to have some way to distinguish between members with
>> a parameter of the underlying type from members that should be treated by
>> newtype as Self parameters.  The mechanism we have for doing that in Swift
>> happens to be a protocol.
>>
>> 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 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 be subtyped because their
 size must be known at compile time. I don’t know the implementation details
 of where functions and computed properties live, but something tells me
 they belong to the type and not the object (although I’ve never really made
 the effort to sit down and fully understand Swift’s type model), in which
 case adding them to a struct’s definition would not change the size of the
 object on the stack. Thus it should be possible to make custom substructs
 of String that add additional functionality but no new stored properties.
 Thoughts?

>>>
>>> Value subtyping is a large subject and, IIUC, newtype would be a subset
>>> of that topic. Unlikely to be in scope for Swift 5, though, but that’s up
>>> to the core team.
>>>
>>>
>>> I see newtype as being more related to forwarding than subtyping.
>>> Usually you want to hide significant parts of the interface to the wrapped
>>> type.
>>>
>>>
>>>
>>> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <
 swift-evolution@swift.org> 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)
 typealias XUView = UIView
 #else
 typealias XUView = NSView
 #endif

 extension XUView {
 ...
 }


 I really don’t see how this disallows code sharing 

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

[Matthew Johnson via swift-evolution]

> 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.  Nothing has gotten too far, but 
it usually comes up that suppressing undesired members is important.

It is also important to have some way to distinguish between members with a 
parameter of the underlying type from members that should be treated by newtype 
as Self parameters.  The mechanism we have for doing that in Swift happens to 
be a protocol.

> On Fri, Jun 9, 2017 at 15:18 Matthew Johnson  > wrote:
>> 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 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 
>> where functions and computed properties live, but something tells me they 
>> belong to the type and not the object (although I’ve never really made the 
>> effort to sit down and fully understand Swift’s type model), in which case 
>> adding them to a struct’s definition would not change the size of the object 
>> on the stack. Thus it should be possible to make custom substructs of String 
>> that add additional functionality but no new stored properties. Thoughts?
>> 
>> Value subtyping is a large subject and, IIUC, newtype would be a subset of 
>> that topic. Unlikely to be in scope for Swift 5, though, but that’s up to 
>> the core team.
> 
> I see newtype as being more related to forwarding than subtyping.  Usually 
> you want to hide significant parts of the interface to the wrapped type.
> 
>> 
>> 
>> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution 
>> > 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)
typealias XUView = UIView
 #else
typealias XUView = NSView
 #endif
 
 extension XUView {
...
 }
>>> 
>>> I really don’t see how this disallows code sharing between the two systems? 
>>> Could you explain further? Based on my understanding of the pitch, this is 
>>> valid code still. (Although I do like the suggestion of a new keyword 
>>> rather than just limiting type alias).
>>> 
>>> Even if your example was invalid, you could also just do something like 
>>> this:
>>> 
>>> #if os(iOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> //extension code here
>>> }
>>> #if os(macOS)
>>> typealias XUView = UIView
>>> extension XUView {
>>> // extension code here
>>> }
>>> #endif
>>> 
>>> While not as pretty, still just as effective if you have to deal with 
>>> different types based on the system being compiled for and you could easily 
>>> still make the type alias extensions for each type work the same.
>>> 
 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 {
...
 }
 
 or with any similar compatibility typealiases.
 
> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
> > wrote:
> 
> +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 
> aliases (and only the type alias), or if it were possible to inherit from 
> structs so that we could create a custom string type like so:
> 
> struct HeaderKey: String {
>   static var lastModified: String { return “Last-Modified” }
>   static var host: String { return “Host” }
> }
> 
> I realize that struct inheritance is far less likely, since that defeats 
> one of the main pieces of what makes a struct a struct. So I’m all for 
> this proposal of allowing 

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

[Xiaodi Wu via swift-evolution]

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 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 be subtyped because their size
>> must be known at compile time. I don’t know the implementation details of
>> where functions and computed properties live, but something tells me they
>> belong to the type and not the object (although I’ve never really made the
>> effort to sit down and fully understand Swift’s type model), in which case
>> adding them to a struct’s definition would not change the size of the
>> object on the stack. Thus it should be possible to make custom substructs
>> of String that add additional functionality but no new stored properties.
>> Thoughts?
>>
>
> Value subtyping is a large subject and, IIUC, newtype would be a subset of
> that topic. Unlikely to be in scope for Swift 5, though, but that’s up to
> the core team.
>
>
> I see newtype as being more related to forwarding than subtyping.  Usually
> you want to hide significant parts of the interface to the wrapped type.
>
>
>
> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <
>> swift-evolution@swift.org> 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)
>> typealias XUView = UIView
>> #else
>> typealias XUView = NSView
>> #endif
>>
>> extension XUView {
>> ...
>> }
>>
>>
>> I really don’t see how this disallows code sharing between the two
>> systems? Could you explain further? Based on my understanding of the pitch,
>> this is valid code still. (Although I do like the suggestion of a new
>> keyword rather than just limiting type alias).
>>
>> Even if your example was invalid, you could also just do something like
>> this:
>>
>> #if os(iOS)
>> typealias XUView = UIView
>> extension XUView {
>> //extension code here
>> }
>> #if os(macOS)
>> typealias XUView = UIView
>> extension XUView {
>> // extension code here
>> }
>> #endif
>>
>> While not as pretty, still just as effective if you have to deal with
>> different types based on the system being compiled for and you could easily
>> still make the type alias extensions for each type work the same.
>>
>> 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 {
>> ...
>> }
>>
>> or with any similar compatibility typealiases.
>>
>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> +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 aliases (and
>> only the type alias), or if it were possible to inherit from structs so
>> that we could create a custom string type like so:
>>
>> struct HeaderKey: String {
>> static var lastModified: String { return “Last-Modified” }
>> static var host: String { return “Host” }
>> }
>>
>> I realize that struct inheritance is far less likely, since that defeats
>> one of the main pieces of what makes a struct a struct. So I’m all for this
>> proposal of allowing type aliases to be extended as though they were their
>> own struct/class.
>>
>> Unfortunately, I’m not sure how feasible this kind of functionality would
>> actually be, but if it’s possible then I’m in favor of implementing it.
>>
>> On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution <
>> swift-evolution@swift.org> 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.
>>
>> Let's say I'm creating a web server framework and I've created a simple
>> dictionary to store HTTP headers (I know that headers are more complex than
>> that, but as an example). I could write something like this:
>>
>> typealias HeaderKey = String
>>
>>   var headers = [HeaderKey: String]()
>>   headers["Host"] = "domain.com"
>>
>> Now I can define a couple of default headers like this:
>>
>>   extension HeaderKey {
>> static var lastModified: String { return "Last-Modified" }
>> static var host: String { return "Host" }
>>   }
>>
>> After that I can do 

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

[Matthew Johnson via swift-evolution]

> 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 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 where 
> functions and computed properties live, but something tells me they belong to 
> the type and not the object (although I’ve never really made the effort to 
> sit down and fully understand Swift’s type model), in which case adding them 
> to a struct’s definition would not change the size of the object on the 
> stack. Thus it should be possible to make custom substructs of String that 
> add additional functionality but no new stored properties. Thoughts?
> 
> Value subtyping is a large subject and, IIUC, newtype would be a subset of 
> that topic. Unlikely to be in scope for Swift 5, though, but that’s up to the 
> core team.

I see newtype as being more related to forwarding than subtyping.  Usually you 
want to hide significant parts of the interface to the wrapped type.

> 
> 
> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution 
> > 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)
>>> typealias XUView = UIView
>>> #else
>>> typealias XUView = NSView
>>> #endif
>>> 
>>> extension XUView {
>>> ...
>>> }
>> 
>> I really don’t see how this disallows code sharing between the two systems? 
>> Could you explain further? Based on my understanding of the pitch, this is 
>> valid code still. (Although I do like the suggestion of a new keyword rather 
>> than just limiting type alias).
>> 
>> Even if your example was invalid, you could also just do something like this:
>> 
>> #if os(iOS)
>>  typealias XUView = UIView
>>  extension XUView {
>>  //extension code here
>>  }
>> #if os(macOS)
>>  typealias XUView = UIView
>>  extension XUView {
>>  // extension code here
>>  }
>> #endif
>> 
>> While not as pretty, still just as effective if you have to deal with 
>> different types based on the system being compiled for and you could easily 
>> still make the type alias extensions for each type work the same.
>> 
>>> 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 {
>>> ...
>>> }
>>> 
>>> or with any similar compatibility typealiases.
>>> 
 On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
 > wrote:
 
 +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 aliases (and 
 only the type alias), or if it were possible to inherit from structs so 
 that we could create a custom string type like so:
 
 struct HeaderKey: String {
static var lastModified: String { return “Last-Modified” }
static var host: String { return “Host” }
 }
 
 I realize that struct inheritance is far less likely, since that defeats 
 one of the main pieces of what makes a struct a struct. So I’m all for 
 this proposal of allowing type aliases to be extended as though they were 
 their own struct/class.
 
 Unfortunately, I’m not sure how feasible this kind of functionality would 
 actually be, but if it’s possible then I’m in favor of implementing it.
 
> On Jun 8, 2017, at 10:14 PM, 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.
> 
> Let's say I'm creating a web server framework and I've created a simple 
> dictionary to store HTTP headers (I know that headers are more complex 
> than that, but as an example). I could write something like this:
> 
> typealias HeaderKey = String
> 
>   var headers = [HeaderKey: 

Re: [swift-evolution] Introduction of OrderedSet

[Xiaodi Wu via swift-evolution]

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 in favor of
OrderedSet or not. In my view, the questions to be answered are:

For the core team–

* Is it still the plan to offer value types postponed from SE-0069 as a
future addition to Foundation?

* If so, is that a priority in the Swift 5 timeframe, and how can the
community help to bring about this addition?

If not, for the whole community–

* Is it wise to implement such a type in the standard library? Should we
simply bring over the native implementation from Swift Package Manager?
What are the implications for bridging?
On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution <
swift-evolution@swift.org> wrote:

> +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 <
> swift-evolution@swift.org> a écrit :
>
> +1, and would also like to see OrderedDictionary as well.
>
> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> 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 been available.
>
>
> Jeff Kelley
>
> slauncha...@gmail.com | @SlaunchaMan  |
> jeffkelley.org
>
> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> in the past there have been a few requests for an OrderedSet
> implementation in Swift. In the proposal
> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>  was
> mentioned that the OrderedSet will be considered for the feature.
>
> However, since then there were a few discussions on OrderedSet but it
> doesn’t get much attention and there wasn’t any comment about it from the
> swift team.
>
> I want to bring up some points, why an OrderedSet is needed in the base
> library.
>
> 1. CoreData is probably the most obvious place where people would use an
> ordered set. Especially when working with large amounts of data, presorting
> can save a lot of time and battery life. If a bridgeable ordered set was
> part of the standard library we could use a ordered set in swift without
> having to use the NSOrderedSet from objective c. Which would be pretty nice
> in my opinion. Even when using a NSOrderedSet we couldn’t have a generic
> version of it.
>
> 2. A shared datamodel between App and Server. One main advantage of having
> web servers written in Swift is that we can share code between the server
> and the app. For servers performance does matter a lot, since they are
> usually working with much more data than apps. Databases are represented as
> sets and fetching sorted data from the database can be represented as an
> ordered set. However, since we don’t have ordered sets we have to choose
> either a normal set or an array. Sets don’t have an order and arrays can
> contain the same object multiple times, which makes them both a less
> suitable choice.
>
> 3. Swift has the potential to be used for education. There is a lot of
> support, for example the playground app on iPad. When it comes to the
> theory behind data structures and algorithms or to the theory of
> computation a defined order plays an important role.
>
> The biggest issue is that we always have to copy data from a set into an
> array to have it in a sorted order with losing the safety of uniqueness.
> Which is not suitable for a safe and performance oriented programming
> language at all.
>
> Last but not least, it fits in the goals of Swift 4 stage 2 and an ordered
> set can be found in other popular programming languages, too.
>
> What do you think?
>
> Best regards,
>
> Maik
>
> ___
> 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 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] History and future of Swift's parentheses

[Gor Gyolchanyan via swift-evolution]

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 between `((A, B)) -> 
C` and `(A, B) -> C` is virtually non-existent. But keep in mind that this only 
works for bare tuples (the ones that can't have labels). Non-closure functions 
DO have labels, which is part of their signature, so this is a different story.

> On Jun 9, 2017, at 6:18 PM, Gwendal Roué  wrote:
> 
> 
>> 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 tuples **exclusively** for all 
>> purposes that involve parentheses, as well as dividing tuples into two 
>> categories:
>> - Bare tuples, which do not have labels.
>> - Rich tuples, which do.
>> As a consequence, here's a list of statements that would become true:
>> - All functions take exactly one parameter, which is a tuple.
>> - All closures (a.k.a. function pointers) take exactly one parameter, which 
>> is a bare tuple.
>> - All functions return exactly one parameter, which is a tuple.
>> - Pattern matching is done on a single bare tuple using a single bare tuple 
>> pattern.
>> 
>> The currently ongoing proposal to make a single-element tuple auto-flatten 
>> would work extremely well with this idea, by making all these changes 
>> completely backward-compatible.
> 
> If I have well understood, Swift has evolved away from this.
> 
> If what you describe were true, added to the fact that there is no such thing 
> as a one-element tuple in the language, then (A,B) -> C and ((A, B)) -> C 
> could not be distinguished, for the simple reason that ((A, B)) -> C could 
> not be defined.
> 
> For ((A, B)) -> C to be defined, we'd need a function that takes exactly one 
> parameter, which is a tuple (your idea), whose single element is a tuple 
> (oops, there is no single-valued tuples).
> 
> No opinion here, just they way I have understood recent Swift history.
> Gwendal
> 

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

Re: [swift-evolution] Int indexing into UTF16View

[Dave Abrahams via swift-evolution]

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 = "M1X/CLEMENT   EELT9QBQGVAAMSEZY1353 244 21D 531  
> 10A1311446838”
> let name = barcode.utf16[2..<22]
> let pnrCode = barcode.utf16[23..<30]
> let seatNo = barcode.utf16[47..<51]
> let fromCity = barcode.utf16[30..<33]
> let toCity = barcode.utf16[33..<36]
> let carrier = barcode.utf16[36..<39]
> let flightNumber = barcode.utf16[39..<44]
> let day = barcode.utf16[44..<47]
>
> I define my own subscript in an extension to UTF16View but I think this 
> should go in the Standard
> Library.
> Any thoughts?

The standard library has been headed in the direction of supporting
underlying String encodings that are not UTF-16 (or UTF-16 subsets, like
ASCII and Latin-1), e.g. UTF-8, which would make it impossible to
support such an API performantly.  So, such an addition would require a
change in our long-term strategy for String, which was laid out in
https://github.com/apple/swift/blob/master/docs/StringManifesto.md

That's not to say it's impossible, but it would be a major course change.

-- 
-Dave

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

Re: [swift-evolution] Introduction of OrderedSet

[Gor Gyolchanyan via swift-evolution]

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 String, while 
leaving String completely intact.
You could have defined a new type HeaderKey, have a single String member in it 
and define call forwarding functions that you need, which would solve your use 
case perfectly.
The only downside is the horrible amount of boilerplate you'd have to write, 
which is where some syntactic sugar could be introduced.

indirect struct HeaderKey {

var value: String // Indirect structs must have exactly one stored 
variable named `value`.

}

extension HeaderKey: CustomStringInitializable {

/// Implementing conformance is optional if `self.value` conforms to it.

}

> On Jun 9, 2017, at 6:37 PM, Remy Demarest via swift-evolution 
>  wrote:
> 
> +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 aliases (and only 
> the type alias), or if it were possible to inherit from structs so that we 
> could create a custom string type like so:
> 
> struct HeaderKey: String {
>   static var lastModified: String { return “Last-Modified” }
>   static var host: String { return “Host” }
> }
> 
> I realize that struct inheritance is far less likely, since that defeats one 
> of the main pieces of what makes a struct a struct. So I’m all for this 
> proposal of allowing type aliases to be extended as though they were their 
> own struct/class.
> 
> Unfortunately, I’m not sure how feasible this kind of functionality would 
> actually be, but if it’s possible then I’m in favor of implementing it.
> 
>> On Jun 8, 2017, at 10:14 PM, 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.
>> 
>> Let's say I'm creating a web server framework and I've created a simple 
>> dictionary to store HTTP headers (I know that headers are more complex than 
>> that, but as an example). I could write something like this:
>> 
>> typealias HeaderKey = String
>> 
>>   var headers = [HeaderKey: String]()
>>   headers["Host"] = "domain.com "
>> 
>> Now I can define a couple of default headers like this:
>> 
>>   extension HeaderKey {
>> static var lastModified: String { return "Last-Modified" }
>> static var host: String { return "Host" }
>>   }
>> 
>> After that I can do this:
>> 
>>   var headers = [HeaderKey: String]()
>>   headers[.host] = "domain.com "
>>   headers[.lastModified] = "some date"
>>   headers["X-MyHeader"] = "This still works too"
>> 
>> But unfortunately the extension is also applied to normal strings:
>> 
>> var normalString: String = .host
>> 
>> Perhaps it would be better if the extension would only apply to the parts of 
>> my code where I use the HeaderKey typealias and not to all Strings. This 
>> could be a great tool to specialize classes by creating a typealias and 
>> adding functionality to it. Another example I can think of is typealiases 
>> for dictionaries or arrays with added business logic through extensions 
>> (especially since you can't inherit from structs).
>> 
>> If you want to create an extension that adds functionality to all Strings 
>> you could have created an extension for String instead of HeaderKey.
>> 
>> Please let me know what you think. I'm not sure how complex this change 
>> would be.
>> I could write a proposal if you're interested.
>> 
>> Kind regards,
>> Yvo
>> ___
>> 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

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

[Xiaodi Wu via swift-evolution]

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 be subtyped because their size
> must be known at compile time. I don’t know the implementation details of
> where functions and computed properties live, but something tells me they
> belong to the type and not the object (although I’ve never really made the
> effort to sit down and fully understand Swift’s type model), in which case
> adding them to a struct’s definition would not change the size of the
> object on the stack. Thus it should be possible to make custom substructs
> of String that add additional functionality but no new stored properties.
> Thoughts?
>

Value subtyping is a large subject and, IIUC, newtype would be a subset of
that topic. Unlikely to be in scope for Swift 5, though, but that’s up to
the core team.


On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <
> swift-evolution@swift.org> 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)
> typealias XUView = UIView
> #else
> typealias XUView = NSView
> #endif
>
> extension XUView {
> ...
> }
>
>
> I really don’t see how this disallows code sharing between the two
> systems? Could you explain further? Based on my understanding of the pitch,
> this is valid code still. (Although I do like the suggestion of a new
> keyword rather than just limiting type alias).
>
> Even if your example was invalid, you could also just do something like
> this:
>
> #if os(iOS)
> typealias XUView = UIView
> extension XUView {
> //extension code here
> }
> #if os(macOS)
> typealias XUView = UIView
> extension XUView {
> // extension code here
> }
> #endif
>
> While not as pretty, still just as effective if you have to deal with
> different types based on the system being compiled for and you could easily
> still make the type alias extensions for each type work the same.
>
> 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 {
> ...
> }
>
> or with any similar compatibility typealiases.
>
> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +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 aliases (and
> only the type alias), or if it were possible to inherit from structs so
> that we could create a custom string type like so:
>
> struct HeaderKey: String {
> static var lastModified: String { return “Last-Modified” }
> static var host: String { return “Host” }
> }
>
> I realize that struct inheritance is far less likely, since that defeats
> one of the main pieces of what makes a struct a struct. So I’m all for this
> proposal of allowing type aliases to be extended as though they were their
> own struct/class.
>
> Unfortunately, I’m not sure how feasible this kind of functionality would
> actually be, but if it’s possible then I’m in favor of implementing it.
>
> On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution <
> swift-evolution@swift.org> 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.
>
> Let's say I'm creating a web server framework and I've created a simple
> dictionary to store HTTP headers (I know that headers are more complex than
> that, but as an example). I could write something like this:
>
> typealias HeaderKey = String
>
>   var headers = [HeaderKey: String]()
>   headers["Host"] = "domain.com"
>
> Now I can define a couple of default headers like this:
>
>   extension HeaderKey {
> static var lastModified: String { return "Last-Modified" }
> static var host: String { return "Host" }
>   }
>
> After that I can do this:
>
>   var headers = [HeaderKey: String]()
>   headers[.host] = "domain.com"
>   headers[.lastModified] = "some date"
>   headers["X-MyHeader"] = "This still works too"
>
> But unfortunately the extension is also applied to normal strings:
>
> var normalString: String = .host
>
> Perhaps it would be better if the extension would only apply to the parts
> of my code where I use the HeaderKey typealias and not to all Strings. This
> could be a great tool to specialize classes by creating a typealias and
> adding functionality to it. Another example 

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

[Charlie Monroe via swift-evolution]

> 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)
>>  typealias XUView = UIView
>> #else
>>  typealias XUView = NSView
>> #endif
>> 
>> extension XUView {
>>  ...
>> }
> 
> I really don’t see how this disallows code sharing between the two systems? 
> Could you explain further? Based on my understanding of the pitch, this is 
> valid code still. (Although I do like the suggestion of a new keyword rather 
> than just limiting type alias).
> 
> Even if your example was invalid, you could also just do something like this:
> 
> #if os(iOS)
>   typealias XUView = UIView
>   extension XUView {
>   //extension code here
>   }
> #if os(macOS)
>   typealias XUView = UIView
>   extension XUView {
>   // extension code here
>   }
> #endif

Um... And you'd implement the same thing twice? The idea behind declaring the 
typealias and extension on it is that you can easily create additional 
functionality with the same code base on both UIView and NSView without 
duplicit code.

>From what I understand that is suggested by this proposal, given the following 
>example expanding my original:

/// Extension of NSView/UIView depending on the target.
extension XUView {

/// Creates some subview and returns it.
func createSubview() -> XUView {
...
}

}

I wouldn't then be able to:

> But unfortunately the extension is also applied to normal strings:
> 
> var normalString: String = .host

a) assign: let view: UIView = view.createSubview()

> Perhaps it would be better if the extension would only apply to the parts of 
> my code where I use the HeaderKey typealias and not to all Strings. 


b) use any of the extensions of views that are not declared as the typealias 
"XUView" (e.g. anything in the Cocoa/UIKit frameworks).






> 
> While not as pretty, still just as effective if you have to deal with 
> different types based on the system being compiled for and you could easily 
> still make the type alias extensions for each type work the same.
> 
>> 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 {
>>  ...
>> }
>> 
>> or with any similar compatibility typealiases.
>> 
>>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
>>> > wrote:
>>> 
>>> +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 aliases (and 
>>> only the type alias), or if it were possible to inherit from structs so 
>>> that we could create a custom string type like so:
>>> 
>>> struct HeaderKey: String {
>>> static var lastModified: String { return “Last-Modified” }
>>> static var host: String { return “Host” }
>>> }
>>> 
>>> I realize that struct inheritance is far less likely, since that defeats 
>>> one of the main pieces of what makes a struct a struct. So I’m all for this 
>>> proposal of allowing type aliases to be extended as though they were their 
>>> own struct/class.
>>> 
>>> Unfortunately, I’m not sure how feasible this kind of functionality would 
>>> actually be, but if it’s possible then I’m in favor of implementing it.
>>> 
 On Jun 8, 2017, at 10:14 PM, 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.
 
 Let's say I'm creating a web server framework and I've created a simple 
 dictionary to store HTTP headers (I know that headers are more complex 
 than that, but as an example). I could write something like this:
 
 typealias HeaderKey = String
 
   var headers = [HeaderKey: String]()
   headers["Host"] = "domain.com "
 
 Now I can define a couple of default headers like this:
 
   extension HeaderKey {
 static var lastModified: String { return "Last-Modified" }
 static var host: String { return "Host" }
   }
 
 After that I can do this:
 
   var headers = [HeaderKey: String]()
   headers[.host] = "domain.com "
   

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

[Robert Bennett via swift-evolution]

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 where 
functions and computed properties live, but something tells me they belong to 
the type and not the object (although I’ve never really made the effort to sit 
down and fully understand Swift’s type model), in which case adding them to a 
struct’s definition would not change the size of the object on the stack. Thus 
it should be possible to make custom substructs of String that add additional 
functionality but no new stored properties. Thoughts?

> On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution 
>  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)
>>  typealias XUView = UIView
>> #else
>>  typealias XUView = NSView
>> #endif
>> 
>> extension XUView {
>>  ...
>> }
> 
> I really don’t see how this disallows code sharing between the two systems? 
> Could you explain further? Based on my understanding of the pitch, this is 
> valid code still. (Although I do like the suggestion of a new keyword rather 
> than just limiting type alias).
> 
> Even if your example was invalid, you could also just do something like this:
> 
> #if os(iOS)
>   typealias XUView = UIView
>   extension XUView {
>   //extension code here
>   }
> #if os(macOS)
>   typealias XUView = UIView
>   extension XUView {
>   // extension code here
>   }
> #endif
> 
> While not as pretty, still just as effective if you have to deal with 
> different types based on the system being compiled for and you could easily 
> still make the type alias extensions for each type work the same.
> 
>> 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 {
>>  ...
>> }
>> 
>> or with any similar compatibility typealiases.
>> 
>>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
>>>  wrote:
>>> 
>>> +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 aliases (and 
>>> only the type alias), or if it were possible to inherit from structs so 
>>> that we could create a custom string type like so:
>>> 
>>> struct HeaderKey: String {
>>> static var lastModified: String { return “Last-Modified” }
>>> static var host: String { return “Host” }
>>> }
>>> 
>>> I realize that struct inheritance is far less likely, since that defeats 
>>> one of the main pieces of what makes a struct a struct. So I’m all for this 
>>> proposal of allowing type aliases to be extended as though they were their 
>>> own struct/class.
>>> 
>>> Unfortunately, I’m not sure how feasible this kind of functionality would 
>>> actually be, but if it’s possible then I’m in favor of implementing it.
>>> 
 On Jun 8, 2017, at 10:14 PM, 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.
 
 Let's say I'm creating a web server framework and I've created a simple 
 dictionary to store HTTP headers (I know that headers are more complex 
 than that, but as an example). I could write something like this:
 
 typealias HeaderKey = String
 
   var headers = [HeaderKey: String]()
   headers["Host"] = "domain.com"
 
 Now I can define a couple of default headers like this:
 
   extension HeaderKey {
 static var lastModified: String { return "Last-Modified" }
 static var host: String { return "Host" }
   }
 
 After that I can do this:
 
   var headers = [HeaderKey: String]()
   headers[.host] = "domain.com"
   headers[.lastModified] = "some date"
   headers["X-MyHeader"] = "This still works too"
 
 But unfortunately the extension is also applied to normal strings:
 
 var normalString: String = .host
 
 Perhaps it would be better if the extension would only apply to the parts 
 of my code where I use the HeaderKey typealias and not to all Strings. 
 This could be a great tool to specialize classes by creating a typealias 

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

[Jacob Williams via swift-evolution]

> 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 {
>   ...
> }

I really don’t see how this disallows code sharing between the two systems? 
Could you explain further? Based on my understanding of the pitch, this is 
valid code still. (Although I do like the suggestion of a new keyword rather 
than just limiting type alias).

Even if your example was invalid, you could also just do something like this:

#if os(iOS)
typealias XUView = UIView
extension XUView {
//extension code here
}
#if os(macOS)
typealias XUView = UIView
extension XUView {
// extension code here
}
#endif

While not as pretty, still just as effective if you have to deal with different 
types based on the system being compiled for and you could easily still make 
the type alias extensions for each type work the same.

> 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 {
>   ...
> }
> 
> or with any similar compatibility typealiases.
> 
>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
>> > wrote:
>> 
>> +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 aliases (and 
>> only the type alias), or if it were possible to inherit from structs so that 
>> we could create a custom string type like so:
>> 
>> struct HeaderKey: String {
>>  static var lastModified: String { return “Last-Modified” }
>>  static var host: String { return “Host” }
>> }
>> 
>> I realize that struct inheritance is far less likely, since that defeats one 
>> of the main pieces of what makes a struct a struct. So I’m all for this 
>> proposal of allowing type aliases to be extended as though they were their 
>> own struct/class.
>> 
>> Unfortunately, I’m not sure how feasible this kind of functionality would 
>> actually be, but if it’s possible then I’m in favor of implementing it.
>> 
>>> On Jun 8, 2017, at 10:14 PM, 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.
>>> 
>>> Let's say I'm creating a web server framework and I've created a simple 
>>> dictionary to store HTTP headers (I know that headers are more complex than 
>>> that, but as an example). I could write something like this:
>>> 
>>> typealias HeaderKey = String
>>> 
>>>   var headers = [HeaderKey: String]()
>>>   headers["Host"] = "domain.com "
>>> 
>>> Now I can define a couple of default headers like this:
>>> 
>>>   extension HeaderKey {
>>> static var lastModified: String { return "Last-Modified" }
>>> static var host: String { return "Host" }
>>>   }
>>> 
>>> After that I can do this:
>>> 
>>>   var headers = [HeaderKey: String]()
>>>   headers[.host] = "domain.com "
>>>   headers[.lastModified] = "some date"
>>>   headers["X-MyHeader"] = "This still works too"
>>> 
>>> But unfortunately the extension is also applied to normal strings:
>>> 
>>> var normalString: String = .host
>>> 
>>> Perhaps it would be better if the extension would only apply to the parts 
>>> of my code where I use the HeaderKey typealias and not to all Strings. This 
>>> could be a great tool to specialize classes by creating a typealias and 
>>> adding functionality to it. Another example I can think of is typealiases 
>>> for dictionaries or arrays with added business logic through extensions 
>>> (especially since you can't inherit from structs).
>>> 
>>> If you want to create an extension that adds functionality to all Strings 
>>> you could have created an extension for String instead of HeaderKey.
>>> 
>>> Please let me know what you think. I'm not sure how complex this change 
>>> would be.
>>> I could write a proposal if you're interested.
>>> 
>>> Kind regards,
>>> Yvo
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 

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

[Charlie Monroe via swift-evolution]

-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 swift-evolution 
>  wrote:
> 
> +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 aliases (and only 
> the type alias), or if it were possible to inherit from structs so that we 
> could create a custom string type like so:
> 
> struct HeaderKey: String {
>   static var lastModified: String { return “Last-Modified” }
>   static var host: String { return “Host” }
> }
> 
> I realize that struct inheritance is far less likely, since that defeats one 
> of the main pieces of what makes a struct a struct. So I’m all for this 
> proposal of allowing type aliases to be extended as though they were their 
> own struct/class.
> 
> Unfortunately, I’m not sure how feasible this kind of functionality would 
> actually be, but if it’s possible then I’m in favor of implementing it.
> 
>> On Jun 8, 2017, at 10:14 PM, 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.
>> 
>> Let's say I'm creating a web server framework and I've created a simple 
>> dictionary to store HTTP headers (I know that headers are more complex than 
>> that, but as an example). I could write something like this:
>> 
>> typealias HeaderKey = String
>> 
>>   var headers = [HeaderKey: String]()
>>   headers["Host"] = "domain.com "
>> 
>> Now I can define a couple of default headers like this:
>> 
>>   extension HeaderKey {
>> static var lastModified: String { return "Last-Modified" }
>> static var host: String { return "Host" }
>>   }
>> 
>> After that I can do this:
>> 
>>   var headers = [HeaderKey: String]()
>>   headers[.host] = "domain.com "
>>   headers[.lastModified] = "some date"
>>   headers["X-MyHeader"] = "This still works too"
>> 
>> But unfortunately the extension is also applied to normal strings:
>> 
>> var normalString: String = .host
>> 
>> Perhaps it would be better if the extension would only apply to the parts of 
>> my code where I use the HeaderKey typealias and not to all Strings. This 
>> could be a great tool to specialize classes by creating a typealias and 
>> adding functionality to it. Another example I can think of is typealiases 
>> for dictionaries or arrays with added business logic through extensions 
>> (especially since you can't inherit from structs).
>> 
>> If you want to create an extension that adds functionality to all Strings 
>> you could have created an extension for String instead of HeaderKey.
>> 
>> Please let me know what you think. I'm not sure how complex this change 
>> would be.
>> I could write a proposal if you're interested.
>> 
>> Kind regards,
>> Yvo
>> ___
>> 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

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

[Will Field-Thompson via swift-evolution]

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(_ value: String) { self.value = value }
   /* Possibly insert methods from String here, possibly do something else,
whatever */
}

I've always thought this might be interesting, but there's a few reasons I
suggest it in place of extending a typealias:
1) Backwards compatibility — this could very easily break existing code
2) Semantically it seems to me that an *alias* is a useful distinction
from *"let's
make a new type" *— sometimes you actually just want to call one type by
another name in some context

Regardless, I think you could solve your particular problem like this:

public struct HeaderKey {
   let value: String
   public init(_ value: String) { self.value = value }
}

and conform HeaderKey to ExpressibleByStringLiteral. That way your
framework's users can still use headers[.lastModified] and
headers["X-MyHeader"] syntax, and it makes your library's code only very
slightly more complicated.

Not trying to tell you how to write your library, but this approach worked
really well for me recently.

Best,

Will

On Fri, Jun 9, 2017 at 12:14 AM Yvo van Beek via swift-evolution <
swift-evolution@swift.org> 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.
>
> Let's say I'm creating a web server framework and I've created a simple
> dictionary to store HTTP headers (I know that headers are more complex than
> that, but as an example). I could write something like this:
>
> typealias HeaderKey = String
>
>   var headers = [HeaderKey: String]()
>   headers["Host"] = "domain.com"
>
> Now I can define a couple of default headers like this:
>
>   extension HeaderKey {
> static var lastModified: String { return "Last-Modified" }
> static var host: String { return "Host" }
>   }
>
> After that I can do this:
>
>   var headers = [HeaderKey: String]()
>   headers[.host] = "domain.com"
>   headers[.lastModified] = "some date"
>   headers["X-MyHeader"] = "This still works too"
>
> But unfortunately the extension is also applied to normal strings:
>
> var normalString: String = .host
>
> Perhaps it would be better if the extension would only apply to the parts
> of my code where I use the HeaderKey typealias and not to all Strings. This
> could be a great tool to specialize classes by creating a typealias and
> adding functionality to it. Another example I can think of is typealiases
> for dictionaries or arrays with added business logic through extensions
> (especially since you can't inherit from structs).
>
> If you want to create an extension that adds functionality to all Strings
> you could have created an extension for String instead of HeaderKey.
>
> Please let me know what you think. I'm not sure how complex this change
> would be.
> I could write a proposal if you're interested.
>
> Kind regards,
> Yvo
> ___
> 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: Limit typealias extensions to the typealias

[Jacob Williams via swift-evolution]

+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 aliases (and only the type alias), 
or if it were possible to inherit from structs so that we could create a custom 
string type like so:

struct HeaderKey: String {
static var lastModified: String { return “Last-Modified” }
static var host: String { return “Host” }
}

I realize that struct inheritance is far less likely, since that defeats one of 
the main pieces of what makes a struct a struct. So I’m all for this proposal 
of allowing type aliases to be extended as though they were their own 
struct/class.

Unfortunately, I’m not sure how feasible this kind of functionality would 
actually be, but if it’s possible then I’m in favor of implementing it.

> On Jun 8, 2017, at 10:14 PM, 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.
> 
> Let's say I'm creating a web server framework and I've created a simple 
> dictionary to store HTTP headers (I know that headers are more complex than 
> that, but as an example). I could write something like this:
> 
> typealias HeaderKey = String
> 
>   var headers = [HeaderKey: String]()
>   headers["Host"] = "domain.com "
> 
> Now I can define a couple of default headers like this:
> 
>   extension HeaderKey {
> static var lastModified: String { return "Last-Modified" }
> static var host: String { return "Host" }
>   }
> 
> After that I can do this:
> 
>   var headers = [HeaderKey: String]()
>   headers[.host] = "domain.com "
>   headers[.lastModified] = "some date"
>   headers["X-MyHeader"] = "This still works too"
> 
> But unfortunately the extension is also applied to normal strings:
> 
> var normalString: String = .host
> 
> Perhaps it would be better if the extension would only apply to the parts of 
> my code where I use the HeaderKey typealias and not to all Strings. This 
> could be a great tool to specialize classes by creating a typealias and 
> adding functionality to it. Another example I can think of is typealiases for 
> dictionaries or arrays with added business logic through extensions 
> (especially since you can't inherit from structs).
> 
> If you want to create an extension that adds functionality to all Strings you 
> could have created an extension for String instead of HeaderKey.
> 
> Please let me know what you think. I'm not sure how complex this change would 
> be.
> I could write a proposal if you're interested.
> 
> Kind regards,
> Yvo
> ___
> 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] Introduction of OrderedSet

[Remy Demarest via swift-evolution]

+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, 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 been available.
>> 
>> 
>> Jeff Kelley
>> 
>> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
>> 
>>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> in the past there have been a few requests for an OrderedSet implementation 
>>> in Swift. In the proposal 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>>  was mentioned that the OrderedSet will be considered for the feature.
>>> 
>>> However, since then there were a few discussions on OrderedSet but it 
>>> doesn’t get much attention and there wasn’t any comment about it from the 
>>> swift team.
>>> 
>>> I want to bring up some points, why an OrderedSet is needed in the base 
>>> library.
>>> 
>>> 1. CoreData is probably the most obvious place where people would use an 
>>> ordered set. Especially when working with large amounts of data, presorting 
>>> can save a lot of time and battery life. If a bridgeable ordered set was 
>>> part of the standard library we could use a ordered set in swift without 
>>> having to use the NSOrderedSet from objective c. Which would be pretty nice 
>>> in my opinion. Even when using a NSOrderedSet we couldn’t have a generic 
>>> version of it.
>>> 
>>> 2. A shared datamodel between App and Server. One main advantage of having 
>>> web servers written in Swift is that we can share code between the server 
>>> and the app. For servers performance does matter a lot, since they are 
>>> usually working with much more data than apps. Databases are represented as 
>>> sets and fetching sorted data from the database can be represented as an 
>>> ordered set. However, since we don’t have ordered sets we have to choose 
>>> either a normal set or an array. Sets don’t have an order and arrays can 
>>> contain the same object multiple times, which makes them both a less 
>>> suitable choice.
>>> 
>>> 3. Swift has the potential to be used for education. There is a lot of 
>>> support, for example the playground app on iPad. When it comes to the 
>>> theory behind data structures and algorithms or to the theory of 
>>> computation a defined order plays an important role.
>>> 
>>> The biggest issue is that we always have to copy data from a set into an 
>>> array to have it in a sorted order with losing the safety of uniqueness. 
>>> Which is not suitable for a safe and performance oriented programming 
>>> language at all.
>>> 
>>> Last but not least, it fits in the goals of Swift 4 stage 2 and an ordered 
>>> set can be found in other popular programming languages, too.
>>> 
>>> What do you think?
>>> 
>>> Best regards,
>>> 
>>> Maik
>>> 
>>> ___
>>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

> 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 tuples **exclusively** for all 
> purposes that involve parentheses, as well as dividing tuples into two 
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.
> - All closures (a.k.a. function pointers) take exactly one parameter, which 
> is a bare tuple.
> - All functions return exactly one parameter, which is a tuple.
> - Pattern matching is done on a single bare tuple using a single bare tuple 
> pattern.
> 
> The currently ongoing proposal to make a single-element tuple auto-flatten 
> would work extremely well with this idea, by making all these changes 
> completely backward-compatible.

If I have well understood, Swift has evolved away from this.

If what you describe were true, added to the fact that there is no such thing 
as a one-element tuple in the language, then (A,B) -> C and ((A, B)) -> C could 
not be distinguished, for the simple reason that ((A, B)) -> C could not be 
defined.

For ((A, B)) -> C to be defined, we'd need a function that takes exactly one 
parameter, which is a tuple (your idea), whose single element is a tuple (oops, 
there is no single-valued tuples).

No opinion here, just they way I have understood recent Swift history.
Gwendal

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

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

[Gor Gyolchanyan via swift-evolution]

> 
> 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:
- Bare tuples, which do not have labels.
- Rich tuples, which do.
As a consequence, here's a list of statements that would become true:
- All functions take exactly one parameter, which is a tuple.
- All closures (a.k.a. function pointers) take exactly one parameter, which is 
a bare tuple.
- All functions return exactly one parameter, which is a tuple.
- Pattern matching is done on a single bare tuple using a single bare tuple 
pattern.

The currently ongoing proposal to make a single-element tuple auto-flatten 
would work extremely well with this idea, by making all these changes 
completely backward-compatible.

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

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

[Robert Bennett via swift-evolution]

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, String) {
return ("\(tuple.0)", "\(tuple.1)")
}

func concat(_ tuple: (String, String)) -> String {
return tuple.0 + tuple.1
}

print(String(reflecting: compose(concat, strung)(3, 4))) // "34"; but shouldn't 
we need a tuple?
print(String(reflecting: compose(concat, strung)((3, 4 // "34"; this makes 
sense

let f = compose(concat, strung)
print(String(reflecting: f(3, 4))) // ERROR: extra argument in call; but if the 
first line works, shouldn't this too?
print(String(reflecting: f((3, 4 // "34"; also makes sense

On Jun 07, 2017, at 03:03 PM, Jens Persson via swift-evolution 
 wrote:

Swift uses parentheses for a lot of different things (tuples, parameters, 
calls, grouping, pattern matching, etc), this has led to some confusion, for 
both language designers and users.

Here's a practical introduction that is possibly worth more than a thousand 
words (or perhaps even swift-evo posts):

  Exercise 1
    Write a (generic) function composition operator in Swift 4
    (working as expected for all function types).

  Exercise 2
    Write a generic type WrappedFunction that can wrap any function in Swift 4
    (with type parameters for Input and Output).

When you have completed (or given up) the exercises, please note that once in 
the history of Swift, these were simple tasks. You could come up with working 
solutions very quickly without any boilerplate or special casing (although 
perhaps not entirely without some of the parentheses-related inconsistencies of 
that time).

I've been reporting a lot of parentheses-related bugs since the first Swift 
beta, and I'm only getting more and more worried that the current incremental 
approach to fixing these is not working very well, resulting in a language that 
is more complex and less expressive than it could be.

Discussions often seem to end up being a bit too focused on particular use 
cases and details, and less on how everything fit together as a system.


So I wonder if any of you have had any thoughts about what Swift's 
parentheses-related future (or evolutionary baggage) will be?


PS

My perhaps unpopular thoughts:

I wish the parentheses-related parts of Swift could be carefully evaluated and 
redesigned from scratch, as a whole, in order to arrive at a solution that is 
as simple and expressive as possible.

But perhaps this has already happened and we are now just taking some steps 
back that are necessary for reimplementing some of the good stuff (that has 
been - at least IMHO - sort of hinted in earlier versions of Swift). But it 
feels like there is not enough time ...

Swift, please break my code all you want before it's too late, as long as it 
results in increased (rather than decreased) consistency, simplicity, 
expressiveness, optimizability and safety. Otherwise I could have used 
Objective C++. 

/Jens

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

[Xiaodi Wu via swift-evolution]

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, 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 the signature:
>
> mutating func `init`() -> Self?
>
> Which would make the returned result optional, but leave `self`
> non-optional.
> This would make `return nil` less out-of-place, like you said, while still
> leaving `self` as a set-exactly-once `inout Self`.
> A factory initializer would then have the signature:
>
> static func `init`(...) -> Self
>
> or in case of a failable factory initializer:
>
> static func `init`(...) -> Self?
>
> Which would still make sense with the now legal `return ...` syntax, while
> adding the restriction of not having any `self` at all.
> So, annotating the initializer with the keyword `factory` would cause it
> to change the signature as well as remove any compiler assumptions about
> the dynamic type of the returned instance.
>
> In addition, idea #3 would be available for more deterministic in-place
> initialization.
>
> On Jun 9, 2017, at 2:47 PM, Xiaodi Wu  wrote:
>
> 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 `return nil` is just as much of a
>> special rule and is also largely counter-intuitive.
>>
>
> `return nil` is “special,” but it doesn’t conflict with any other syntax
> because the initializer notionally has no return value. Personally, I have
> always disliked `return nil` in failable initializers for that reason, but
> I couldn’t come up with a better alternative.
>
> Your proposed idea to allow returning any value is interesting because, in
> the case of a failable initializer, `return nil` continues to have the same
> meaning if we consider the return value of the initializer to be of type
> `Self?`. For that reason, I think your idea #2 is quite clever, and it
> would go a long way in making `return nil` a lot less odd. It also
> increases the expressivity of initializers because it allows one to set the
> value of self and also return in one statement, clearly demonstrating the
> intention that no other code in the initializer should be run before
> returning.
>
> For all of those reasons, I think idea #2 is a winning idea.
>
> The benefit of `self = nil` is that it's much more in line with
>> initialization semantics, it provides more uniform syntax and it's a bit
>> less restrictive.
>>
>> 2. It's an `inout Self!`, like Greg said, which can be seen as more
>> cumbersome. Implicitly unwrapped optionals are a bit difficult, but this
>> "variation" of it is much more restrictive then the normal ones, because
>> unlike normal implicitly unwrapped optionals, this one cannot be accessed
>> after being assigned nil (and it also cannot be indirectly assigned `nil`,
>> because escaping `self` is not allowed before full initialization), so
>> there is only one possible place it can be set to nil and that's directly
>> in the initializer. This means that `self` can be safely treated as `inout
>> Self` before being set to nil (and after being set to nil, it doesn't
>> matter any more because you aren't allowed to access it, due to not being
>> fully initialized).
>>
>
> I have to say, I don’t like either of these explanations at all. I think
> having a “special” IUO is a difficult sell; it is just conceptually too
> complicated, and I don’t agree that it gains you much.
>
> By your own admission, `self = nil` is wonky, and making the language
> wonkier because it currently has a parallel wonky feature in `return nil`
> seems like the wrong way to go. In addition, there’s nothing gained here
> that cannot be done with a defer statement; of course, defer statements
> might not be very elegant, but it would certainly be less wonky than
> inventing a new variation on an IUO to allow assignment of nil to self...
> For those reasons, I conclude that I’m not excited about your idea #1.
>
> Overall, I'd go with #2 because it involves much less confusing magic and
>> the restrictions of `self as inout Self!` are imposed by already existing
>> and well-understood initialization logic, so the provided guarantees don't
>> really come at the cost of much clarity.
>>
>> On Jun 9, 2017, at 2:23 PM, Xiaodi Wu  wrote:
>>
>>
>> On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan  wrote:
>>
>>> I think a good approach 

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

[Gor Gyolchanyan via swift-evolution]

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 the signature:

mutating func `init`() -> Self?

Which would make the returned result optional, but leave `self` non-optional.
This would make `return nil` less out-of-place, like you said, while still 
leaving `self` as a set-exactly-once `inout Self`.
A factory initializer would then have the signature:

static func `init`(...) -> Self

or in case of a failable factory initializer:

static func `init`(...) -> Self?

Which would still make sense with the now legal `return ...` syntax, while 
adding the restriction of not having any `self` at all.
So, annotating the initializer with the keyword `factory` would cause it to 
change the signature as well as remove any compiler assumptions about the 
dynamic type of the returned instance.

In addition, idea #3 would be available for more deterministic in-place 
initialization.

> On Jun 9, 2017, at 2:47 PM, Xiaodi Wu  wrote:
> 
> 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 `return nil` is just as much of a special rule and is also 
> largely counter-intuitive.
> 
> `return nil` is “special,” but it doesn’t conflict with any other syntax 
> because the initializer notionally has no return value. Personally, I have 
> always disliked `return nil` in failable initializers for that reason, but I 
> couldn’t come up with a better alternative.
> 
> Your proposed idea to allow returning any value is interesting because, in 
> the case of a failable initializer, `return nil` continues to have the same 
> meaning if we consider the return value of the initializer to be of type 
> `Self?`. For that reason, I think your idea #2 is quite clever, and it would 
> go a long way in making `return nil` a lot less odd. It also increases the 
> expressivity of initializers because it allows one to set the value of self 
> and also return in one statement, clearly demonstrating the intention that no 
> other code in the initializer should be run before returning.
> 
> For all of those reasons, I think idea #2 is a winning idea.
> 
> The benefit of `self = nil` is that it's much more in line with 
> initialization semantics, it provides more uniform syntax and it's a bit less 
> restrictive.
> 
> 2. It's an `inout Self!`, like Greg said, which can be seen as more 
> cumbersome. Implicitly unwrapped optionals are a bit difficult, but this 
> "variation" of it is much more restrictive then the normal ones, because 
> unlike normal implicitly unwrapped optionals, this one cannot be accessed 
> after being assigned nil (and it also cannot be indirectly assigned `nil`, 
> because escaping `self` is not allowed before full initialization), so there 
> is only one possible place it can be set to nil and that's directly in the 
> initializer. This means that `self` can be safely treated as `inout Self` 
> before being set to nil (and after being set to nil, it doesn't matter any 
> more because you aren't allowed to access it, due to not being fully 
> initialized).
> 
> I have to say, I don’t like either of these explanations at all. I think 
> having a “special” IUO is a difficult sell; it is just conceptually too 
> complicated, and I don’t agree that it gains you much.
> 
> By your own admission, `self = nil` is wonky, and making the language wonkier 
> because it currently has a parallel wonky feature in `return nil` seems like 
> the wrong way to go. In addition, there’s nothing gained here that cannot be 
> done with a defer statement; of course, defer statements might not be very 
> elegant, but it would certainly be less wonky than inventing a new variation 
> on an IUO to allow assignment of nil to self... For those reasons, I conclude 
> that I’m not excited about your idea #1.
> 
> Overall, I'd go with #2 because it involves much less confusing magic and the 
> restrictions of `self as inout Self!` are imposed by already existing and 
> well-understood initialization logic, so the provided guarantees don't really 
> come at the cost of much clarity.
> 
>> On Jun 9, 2017, at 2:23 PM, Xiaodi Wu > > wrote:
>> 
>> 
>> 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 
>> 

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

[Xiaodi Wu via swift-evolution]

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 `return nil` is just as much of a
> special rule and is also largely counter-intuitive.
>

`return nil` is “special,” but it doesn’t conflict with any other syntax
because the initializer notionally has no return value. Personally, I have
always disliked `return nil` in failable initializers for that reason, but
I couldn’t come up with a better alternative.

Your proposed idea to allow returning any value is interesting because, in
the case of a failable initializer, `return nil` continues to have the same
meaning if we consider the return value of the initializer to be of type
`Self?`. For that reason, I think your idea #2 is quite clever, and it
would go a long way in making `return nil` a lot less odd. It also
increases the expressivity of initializers because it allows one to set the
value of self and also return in one statement, clearly demonstrating the
intention that no other code in the initializer should be run before
returning.

For all of those reasons, I think idea #2 is a winning idea.

The benefit of `self = nil` is that it's much more in line with
> initialization semantics, it provides more uniform syntax and it's a bit
> less restrictive.
>
> 2. It's an `inout Self!`, like Greg said, which can be seen as more
> cumbersome. Implicitly unwrapped optionals are a bit difficult, but this
> "variation" of it is much more restrictive then the normal ones, because
> unlike normal implicitly unwrapped optionals, this one cannot be accessed
> after being assigned nil (and it also cannot be indirectly assigned `nil`,
> because escaping `self` is not allowed before full initialization), so
> there is only one possible place it can be set to nil and that's directly
> in the initializer. This means that `self` can be safely treated as `inout
> Self` before being set to nil (and after being set to nil, it doesn't
> matter any more because you aren't allowed to access it, due to not being
> fully initialized).
>

I have to say, I don’t like either of these explanations at all. I think
having a “special” IUO is a difficult sell; it is just conceptually too
complicated, and I don’t agree that it gains you much.

By your own admission, `self = nil` is wonky, and making the language
wonkier because it currently has a parallel wonky feature in `return nil`
seems like the wrong way to go. In addition, there’s nothing gained here
that cannot be done with a defer statement; of course, defer statements
might not be very elegant, but it would certainly be less wonky than
inventing a new variation on an IUO to allow assignment of nil to self...
For those reasons, I conclude that I’m not excited about your idea #1.

Overall, I'd go with #2 because it involves much less confusing magic and
> the restrictions of `self as inout Self!` are imposed by already existing
> and well-understood initialization logic, so the provided guarantees don't
> really come at the cost of much clarity.
>
> On Jun 9, 2017, at 2:23 PM, Xiaodi Wu  wrote:
>
>
> 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 meaning as if your type was not ExpressibleByNilLiteral
>> and was an optional instead, so having a failable initializer doesn't
>> really make sense in that case (since you could've initialized `self` to
>> its own `nil` in case of failure). Still, some valid use cases may exist,
>> so the natural (and quite intuitive) way to circumvent this would be to
>> call `self.init(nilLiteral: ())` directly.
>>
>
> So you would create a special rule that `self = nil` means a different
> thing in an initializer than it does in a function? Essentially, then,
> you’re creating your own variation on an implicitly unwrapped optional,
> where `self` is of type `inout Self?` for assignment in initializers only
> but not for any other purpose. Implicitly unwrapped optionals are hard to
> reason about, and having a variation on it would be even harder to
> understand. I don’t think this is a workable design.
>
> It might be possible to have `self` be of type `inout Self?`; however, I
> do think Greg is right that it would create more boilerplate than the
> current situation.
>
> On Jun 9, 2017, at 2:07 PM, Xiaodi Wu  wrote:
>>
>>
>> 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 

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

[Gor Gyolchanyan via swift-evolution]

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 counter-intuitive. The benefit of `self = nil` is that it's much more 
in line with initialization semantics, it provides more uniform syntax and it's 
a bit less restrictive.

2. It's an `inout Self!`, like Greg said, which can be seen as more cumbersome. 
Implicitly unwrapped optionals are a bit difficult, but this "variation" of it 
is much more restrictive then the normal ones, because unlike normal implicitly 
unwrapped optionals, this one cannot be accessed after being assigned nil (and 
it also cannot be indirectly assigned `nil`, because escaping `self` is not 
allowed before full initialization), so there is only one possible place it can 
be set to nil and that's directly in the initializer. This means that `self` 
can be safely treated as `inout Self` before being set to nil (and after being 
set to nil, it doesn't matter any more because you aren't allowed to access it, 
due to not being fully initialized).

Overall, I'd go with #2 because it involves much less confusing magic and the 
restrictions of `self as inout Self!` are imposed by already existing and 
well-understood initialization logic, so the provided guarantees don't really 
come at the cost of much clarity.

> On Jun 9, 2017, at 2:23 PM, Xiaodi Wu  wrote:
> 
> 
> 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 meaning as if your type was not ExpressibleByNilLiteral and was an 
> optional instead, so having a failable initializer doesn't really make sense 
> in that case (since you could've initialized `self` to its own `nil` in case 
> of failure). Still, some valid use cases may exist, so the natural (and quite 
> intuitive) way to circumvent this would be to call `self.init(nilLiteral: 
> ())` directly.
> 
> So you would create a special rule that `self = nil` means a different thing 
> in an initializer than it does in a function? Essentially, then, you’re 
> creating your own variation on an implicitly unwrapped optional, where `self` 
> is of type `inout Self?` for assignment in initializers only but not for any 
> other purpose. Implicitly unwrapped optionals are hard to reason about, and 
> having a variation on it would be even harder to understand. I don’t think 
> this is a workable design.
> 
> It might be possible to have `self` be of type `inout Self?`; however, I do 
> think Greg is right that it would create more boilerplate than the current 
> situation.
> 
>> On Jun 9, 2017, at 2:07 PM, Xiaodi Wu > > wrote:
>> 
>> 
>> 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 the 
>> initialization logic.
>> 
>> The idea is to define all different ways initialization can take place and 
>> expand them to be used uniformly on both `self` and all its members, as well 
>> as remove the ways that do not make sense for their purpose.
>> 
>> Currently, there are 3 ways of initializing self as a whole:
>>  1. delegating initializer
>>  2. assigning to self
>>  3. returning nil
>> 
>> #1: The delegating initializer is pretty much perfect at this point, in my 
>> opinion, so no changes there.
>> 
>> #2: The only exception in assigning to self is the `nil` inside failable 
>> initializers.
>> 
>> #3:  The only thing that can be returned from an initializer is `nil`, which 
>> is compiler magic, so we can thing of it as a misnomer (because we aren't 
>> really **returning** anything).
>> 
>> If, for a second, we forget about potential factory initializers, returning 
>> anything from an initializer doesn't make much sense, because an initializer 
>> is conceptually meant to bring an existing object in memory to a 
>> type-specific valid state. This semantic was very explicitly in Objective-C 
>> with `[[MyType alloc] init]`. Especially since even syntactically, the 
>> initializer does not specify any return type, the idea of returning from an 
>> initializer is counter-intuitive both syntactically and semantically.
>> 
>> The actual *behavior* of `return nil` is very sensible, so the behavior, I 
>> imagine `self = nil`, would largely mean the same (except not needed to 
>> return immediately and allowing 

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

[Xiaodi Wu via swift-evolution]

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 meaning as if your type was not ExpressibleByNilLiteral
> and was an optional instead, so having a failable initializer doesn't
> really make sense in that case (since you could've initialized `self` to
> its own `nil` in case of failure). Still, some valid use cases may exist,
> so the natural (and quite intuitive) way to circumvent this would be to
> call `self.init(nilLiteral: ())` directly.
>

So you would create a special rule that `self = nil` means a different
thing in an initializer than it does in a function? Essentially, then,
you’re creating your own variation on an implicitly unwrapped optional,
where `self` is of type `inout Self?` for assignment in initializers only
but not for any other purpose. Implicitly unwrapped optionals are hard to
reason about, and having a variation on it would be even harder to
understand. I don’t think this is a workable design.

It might be possible to have `self` be of type `inout Self?`; however, I do
think Greg is right that it would create more boilerplate than the current
situation.

On Jun 9, 2017, at 2:07 PM, Xiaodi Wu  wrote:
>
>
> 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
>> the initialization logic.
>>
>> The idea is to define all different ways initialization can take place
>> and expand them to be used uniformly on both `self` and all its members, as
>> well as remove the ways that do not make sense for their purpose.
>>
>> Currently, there are 3 ways of initializing self as a whole:
>> 1. delegating initializer
>> 2. assigning to self
>> 3. returning nil
>>
>> #1: The delegating initializer is pretty much perfect at this point, in
>> my opinion, so no changes there.
>>
>> #2: The only exception in assigning to self is the `nil` inside failable
>> initializers.
>>
>> #3:  The only thing that can be returned from an initializer is `nil`,
>> which is compiler magic, so we can thing of it as a misnomer (because we
>> aren't really **returning** anything).
>>
>> If, for a second, we forget about potential factory initializers,
>> returning anything from an initializer doesn't make much sense, because an
>> initializer is conceptually meant to bring an existing object in memory to
>> a type-specific valid state. This semantic was very explicitly in
>> Objective-C with `[[MyType alloc] init]`. Especially since even
>> syntactically, the initializer does not specify any return type, the idea
>> of returning from an initializer is counter-intuitive both syntactically
>> and semantically.
>>
>> The actual *behavior* of `return nil` is very sensible, so the behavior,
>> I imagine `self = nil`, would largely mean the same (except not needed to
>> return immediately and allowing non-self-accessing code to be executed
>> before return). Being able to assign `nil` to a non-optional
>> (ExpressibleByNilLiteral doesn't count) may feel a bit wonky,
>>
>
> What happens when Self is ExpressibleByNilLiteral and you want to
> initialize self to nil? That is what `self = nil` means if `self` is of
> type `inout Self`. If `self` is of type `inout Self` and Self is not
> ExpressibleByNilLiteral, then it must be an error to assign nil to self.
> Anything else does not make sense, unless `self` is of type `inout Self?`.
>
> but not as wonky as returning nil from something that is meant to
>> initialize an object in-place and doesn't look like it should return
>> anything.
>>
>> # Factory Initializers
>>
>> In case of factory initializers, the much discussed `factory init` syntax
>> could completely flip this logic, but making the initializer essentially a
>> static function that returns an object. In this case the initializer could
>> be made to specify the return type (that is the supertype of all possible
>> factory-created objects) and assigning to self would be forbidden because
>> there is not self yet:
>>
>> extension MyProtocol {
>>
>> public factory init(weCool: Bool) -> MyProtocol {
>> self = MyImpl() // error: cannot assign to `self` in a factory initializer
>> self.init(...) // error: cannot make a delegating initializer call in a
>> factory initializer
>> if weCool {
>> return MyCoolImpl()
>> } else {
>> return MyUncoolImpl()
>> }
>> }
>>
>> }
>>
>> # In-place Member Initializers
>>
>> In addition, member initialization currently is only possible with #2 (as
>> in `self.member = value`), which could be extended in a non-factory
>> initializer to be initializable in-place like this:
>>
>> 

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

[Xiaodi Wu via swift-evolution]

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
> the initialization logic.
>
> The idea is to define all different ways initialization can take place and
> expand them to be used uniformly on both `self` and all its members, as
> well as remove the ways that do not make sense for their purpose.
>
> Currently, there are 3 ways of initializing self as a whole:
> 1. delegating initializer
> 2. assigning to self
> 3. returning nil
>
> #1: The delegating initializer is pretty much perfect at this point, in my
> opinion, so no changes there.
>
> #2: The only exception in assigning to self is the `nil` inside failable
> initializers.
>
> #3:  The only thing that can be returned from an initializer is `nil`,
> which is compiler magic, so we can thing of it as a misnomer (because we
> aren't really **returning** anything).
>
> If, for a second, we forget about potential factory initializers,
> returning anything from an initializer doesn't make much sense, because an
> initializer is conceptually meant to bring an existing object in memory to
> a type-specific valid state. This semantic was very explicitly in
> Objective-C with `[[MyType alloc] init]`. Especially since even
> syntactically, the initializer does not specify any return type, the idea
> of returning from an initializer is counter-intuitive both syntactically
> and semantically.
>
> The actual *behavior* of `return nil` is very sensible, so the behavior, I
> imagine `self = nil`, would largely mean the same (except not needed to
> return immediately and allowing non-self-accessing code to be executed
> before return). Being able to assign `nil` to a non-optional
> (ExpressibleByNilLiteral doesn't count) may feel a bit wonky,
>

What happens when Self is ExpressibleByNilLiteral and you want to
initialize self to nil? That is what `self = nil` means if `self` is of
type `inout Self`. If `self` is of type `inout Self` and Self is not
ExpressibleByNilLiteral, then it must be an error to assign nil to self.
Anything else does not make sense, unless `self` is of type `inout Self?`.

but not as wonky as returning nil from something that is meant to
> initialize an object in-place and doesn't look like it should return
> anything.
>
> # Factory Initializers
>
> In case of factory initializers, the much discussed `factory init` syntax
> could completely flip this logic, but making the initializer essentially a
> static function that returns an object. In this case the initializer could
> be made to specify the return type (that is the supertype of all possible
> factory-created objects) and assigning to self would be forbidden because
> there is not self yet:
>
> extension MyProtocol {
>
> public factory init(weCool: Bool) -> MyProtocol {
> self = MyImpl() // error: cannot assign to `self` in a factory initializer
> self.init(...) // error: cannot make a delegating initializer call in a
> factory initializer
> if weCool {
> return MyCoolImpl()
> } else {
> return MyUncoolImpl()
> }
> }
>
> }
>
> # In-place Member Initializers
>
> In addition, member initialization currently is only possible with #2 (as
> in `self.member = value`), which could be extended in a non-factory
> initializer to be initializable in-place like this:
>
> self.member.init(...)
>
> This would compliment the delegating initialization syntax, while giving a
> more reliable performance guarantee that this member will not be
> copy-initialized.
>
> On Jun 9, 2017, at 1:32 PM, Xiaodi Wu  wrote:
>
> 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 times–but that has a totally different meaning.
>
> Could `self` be of type `inout Self!`? Now that implicitly unwrapped
> optionals are no longer their own type, I’m not sure that’s possible. But
> even if it were, that seems unintuitive and potentially error-prone.
>
> So I think Greg is quite right that, to enable this feature, `self` would
> have to be of type `inout Self?`–which is intriguing but potentially more
> boilerplatey than the status quo.
> On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 though.
>> Also, since there can be only one `self = nil`, there's no reason to

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

[Gor Gyolchanyan via swift-evolution]

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, so 
having a failable initializer doesn't really make sense in that case (since you 
could've initialized `self` to its own `nil` in case of failure). Still, some 
valid use cases may exist, so the natural (and quite intuitive) way to 
circumvent this would be to call `self.init(nilLiteral: ())` directly.

> On Jun 9, 2017, at 2:07 PM, Xiaodi Wu  wrote:
> 
> 
> 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 the 
> initialization logic.
> 
> The idea is to define all different ways initialization can take place and 
> expand them to be used uniformly on both `self` and all its members, as well 
> as remove the ways that do not make sense for their purpose.
> 
> Currently, there are 3 ways of initializing self as a whole:
>   1. delegating initializer
>   2. assigning to self
>   3. returning nil
> 
> #1: The delegating initializer is pretty much perfect at this point, in my 
> opinion, so no changes there.
> 
> #2: The only exception in assigning to self is the `nil` inside failable 
> initializers.
> 
> #3:  The only thing that can be returned from an initializer is `nil`, which 
> is compiler magic, so we can thing of it as a misnomer (because we aren't 
> really **returning** anything).
> 
> If, for a second, we forget about potential factory initializers, returning 
> anything from an initializer doesn't make much sense, because an initializer 
> is conceptually meant to bring an existing object in memory to a 
> type-specific valid state. This semantic was very explicitly in Objective-C 
> with `[[MyType alloc] init]`. Especially since even syntactically, the 
> initializer does not specify any return type, the idea of returning from an 
> initializer is counter-intuitive both syntactically and semantically.
> 
> The actual *behavior* of `return nil` is very sensible, so the behavior, I 
> imagine `self = nil`, would largely mean the same (except not needed to 
> return immediately and allowing non-self-accessing code to be executed before 
> return). Being able to assign `nil` to a non-optional 
> (ExpressibleByNilLiteral doesn't count) may feel a bit wonky,
> 
> What happens when Self is ExpressibleByNilLiteral and you want to initialize 
> self to nil? That is what `self = nil` means if `self` is of type `inout 
> Self`. If `self` is of type `inout Self` and Self is not 
> ExpressibleByNilLiteral, then it must be an error to assign nil to self. 
> Anything else does not make sense, unless `self` is of type `inout Self?`.
> 
> but not as wonky as returning nil from something that is meant to initialize 
> an object in-place and doesn't look like it should return anything.
> 
> # Factory Initializers
> 
> In case of factory initializers, the much discussed `factory init` syntax 
> could completely flip this logic, but making the initializer essentially a 
> static function that returns an object. In this case the initializer could be 
> made to specify the return type (that is the supertype of all possible 
> factory-created objects) and assigning to self would be forbidden because 
> there is not self yet:
> 
> extension MyProtocol {
> 
>   public factory init(weCool: Bool) -> MyProtocol {
>   self = MyImpl() // error: cannot assign to `self` in a factory 
> initializer
>   self.init(...) // error: cannot make a delegating initializer 
> call in a factory initializer
>   if weCool {
>   return MyCoolImpl()
>   } else {
>   return MyUncoolImpl()
>   }
>   }
> 
> }
> 
> # In-place Member Initializers
> 
> In addition, member initialization currently is only possible with #2 (as in 
> `self.member = value`), which could be extended in a non-factory initializer 
> to be initializable in-place like this:
> 
> self.member.init(...)
> 
> This would compliment the delegating initialization syntax, while giving a 
> more reliable performance guarantee that this member will not be 
> copy-initialized.
> 
>> On Jun 9, 2017, at 1:32 PM, Xiaodi Wu > > wrote:
>> 
>> 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 

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

[Gor Gyolchanyan via swift-evolution]

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 initialization can take place and 
expand them to be used uniformly on both `self` and all its members, as well as 
remove the ways that do not make sense for their purpose.

Currently, there are 3 ways of initializing self as a whole:
1. delegating initializer
2. assigning to self
3. returning nil

#1: The delegating initializer is pretty much perfect at this point, in my 
opinion, so no changes there.

#2: The only exception in assigning to self is the `nil` inside failable 
initializers.

#3:  The only thing that can be returned from an initializer is `nil`, which is 
compiler magic, so we can thing of it as a misnomer (because we aren't really 
**returning** anything).

If, for a second, we forget about potential factory initializers, returning 
anything from an initializer doesn't make much sense, because an initializer is 
conceptually meant to bring an existing object in memory to a type-specific 
valid state. This semantic was very explicitly in Objective-C with `[[MyType 
alloc] init]`. Especially since even syntactically, the initializer does not 
specify any return type, the idea of returning from an initializer is 
counter-intuitive both syntactically and semantically.

The actual *behavior* of `return nil` is very sensible, so the behavior, I 
imagine `self = nil`, would largely mean the same (except not needed to return 
immediately and allowing non-self-accessing code to be executed before return). 
Being able to assign `nil` to a non-optional (ExpressibleByNilLiteral doesn't 
count) may feel a bit wonky, but not as wonky as returning nil from something 
that is meant to initialize an object in-place and doesn't look like it should 
return anything.

# Factory Initializers

In case of factory initializers, the much discussed `factory init` syntax could 
completely flip this logic, but making the initializer essentially a static 
function that returns an object. In this case the initializer could be made to 
specify the return type (that is the supertype of all possible factory-created 
objects) and assigning to self would be forbidden because there is not self yet:

extension MyProtocol {

public factory init(weCool: Bool) -> MyProtocol {
self = MyImpl() // error: cannot assign to `self` in a factory 
initializer
self.init(...) // error: cannot make a delegating initializer 
call in a factory initializer
if weCool {
return MyCoolImpl()
} else {
return MyUncoolImpl()
}
}

}

# In-place Member Initializers

In addition, member initialization currently is only possible with #2 (as in 
`self.member = value`), which could be extended in a non-factory initializer to 
be initializable in-place like this:

self.member.init(...)

This would compliment the delegating initialization syntax, while giving a more 
reliable performance guarantee that this member will not be copy-initialized.

> On Jun 9, 2017, at 1:32 PM, Xiaodi Wu  wrote:
> 
> 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 times–but that has a totally different meaning.
> 
> Could `self` be of type `inout Self!`? Now that implicitly unwrapped 
> optionals are no longer their own type, I’m not sure that’s possible. But 
> even if it were, that seems unintuitive and potentially error-prone.
> 
> So I think Greg is quite right that, to enable this feature, `self` would 
> have to be of type `inout Self?`–which is intriguing but potentially more 
> boilerplatey than the status quo.
> On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution 
> > wrote:
> 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 though.
> Also, since there can be only one `self = nil`, there's no reason to treat 
> `self` as `inout Self?`, because the only place it can be `nil` is the place 
> it cannot be accessed any more.
> 
> 
>> On Jun 9, 2017, at 7:45 AM, Greg Parker > > wrote:
>> 
>> 
>>> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution 
>>> 

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

[Xiaodi Wu via swift-evolution]

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 times–but that has a totally different meaning.

Could `self` be of type `inout Self!`? Now that implicitly unwrapped
optionals are no longer their own type, I’m not sure that’s possible. But
even if it were, that seems unintuitive and potentially error-prone.

So I think Greg is quite right that, to enable this feature, `self` would
have to be of type `inout Self?`–which is intriguing but potentially more
boilerplatey than the status quo.
On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 though.
> Also, since there can be only one `self = nil`, there's no reason to treat
> `self` as `inout Self?`, because the only place it can be `nil` is the
> place it cannot be accessed any more.
>
>
> On Jun 9, 2017, at 7:45 AM, Greg Parker  wrote:
>
>
> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 1. Arbitrary `self` Assignments In Intializers
>
> The first ideas is to allow `self = nil` inside failable initializers
> (essentially making `self` look like `inout Self?` instead of `inout Self`
> with magical `return nil`), so that all initializers uniformly can be
> written in `self = ...` form for clarity and convenience purposes. This
> should, theoretically, be nothing but a `defer { return nil }` type of
> rewrite, so I don't see any major difficulties implementing this. This is
> especially useful for failable-initializing enums where the main switch
> simply assigns to self in all cases and the rest of the initializer does
> some post-processing.
>
>
> I don't see how to avoid source incompatibility and uglification of
> failable initializer implementations here. Allowing `self = nil` inside a
> failable initializer would require `self` to be an optional. That in turn
> would require every use of `self` in the initializer to be nil-checked or
> forced. I don't think that loss everywhere outweighs the gain of `self =
> nil` in some places.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
> ___
> 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] Introduction of OrderedSet

[Robert Bennett via swift-evolution]

+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 been available.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> 
>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
>>  wrote:
>> 
>> Hello,
>> 
>> in the past there have been a few requests for an OrderedSet implementation 
>> in Swift. In the proposal 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  was mentioned that the OrderedSet will be considered for the feature.
>> 
>> However, since then there were a few discussions on OrderedSet but it 
>> doesn’t get much attention and there wasn’t any comment about it from the 
>> swift team.
>> 
>> I want to bring up some points, why an OrderedSet is needed in the base 
>> library.
>> 
>> 1. CoreData is probably the most obvious place where people would use an 
>> ordered set. Especially when working with large amounts of data, presorting 
>> can save a lot of time and battery life. If a bridgeable ordered set was 
>> part of the standard library we could use a ordered set in swift without 
>> having to use the NSOrderedSet from objective c. Which would be pretty nice 
>> in my opinion. Even when using a NSOrderedSet we couldn’t have a generic 
>> version of it.
>> 
>> 2. A shared datamodel between App and Server. One main advantage of having 
>> web servers written in Swift is that we can share code between the server 
>> and the app. For servers performance does matter a lot, since they are 
>> usually working with much more data than apps. Databases are represented as 
>> sets and fetching sorted data from the database can be represented as an 
>> ordered set. However, since we don’t have ordered sets we have to choose 
>> either a normal set or an array. Sets don’t have an order and arrays can 
>> contain the same object multiple times, which makes them both a less 
>> suitable choice.
>> 
>> 3. Swift has the potential to be used for education. There is a lot of 
>> support, for example the playground app on iPad. When it comes to the theory 
>> behind data structures and algorithms or to the theory of computation a 
>> defined order plays an important role.
>> 
>> The biggest issue is that we always have to copy data from a set into an 
>> array to have it in a sorted order with losing the safety of uniqueness. 
>> Which is not suitable for a safe and performance oriented programming 
>> language at all.
>> 
>> Last but not least, it fits in the goals of Swift 4 stage 2 and an ordered 
>> set can be found in other popular programming languages, too.
>> 
>> What do you think?
>> 
>> Best regards,
>> 
>> Maik
>> 
>> ___
>> 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

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

[Gor Gyolchanyan via swift-evolution]

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 though.
Also, since there can be only one `self = nil`, there's no reason to treat 
`self` as `inout Self?`, because the only place it can be `nil` is the place it 
cannot be accessed any more.

> On Jun 9, 2017, at 7:45 AM, Greg Parker  wrote:
> 
> 
>> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution 
>> > wrote:
>> 
>> 1. Arbitrary `self` Assignments In Intializers
>> 
>> The first ideas is to allow `self = nil` inside failable initializers 
>> (essentially making `self` look like `inout Self?` instead of `inout Self` 
>> with magical `return nil`), so that all initializers uniformly can be 
>> written in `self = ...` form for clarity and convenience purposes. This 
>> should, theoretically, be nothing but a `defer { return nil }` type of 
>> rewrite, so I don't see any major difficulties implementing this. This is 
>> especially useful for failable-initializing enums where the main switch 
>> simply assigns to self in all cases and the rest of the initializer does 
>> some post-processing.
> 
> I don't see how to avoid source incompatibility and uglification of failable 
> initializer implementations here. Allowing `self = nil` inside a failable 
> initializer would require `self` to be an optional. That in turn would 
> require every use of `self` in the initializer to be nil-checked or forced. I 
> don't think that loss everywhere outweighs the gain of `self = nil` in some 
> places.
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 

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

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

[Gwendal Roué via swift-evolution]

> 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 subjective statement” 
> to make a subjective statement.

Yes, sorry: It's so easy to sound assertive even when we just want to share and 
communicate opinions.

>> I *do* suggest a specific handling of { _ ... }. I have shown how it can be 
>> implemented in a non-ambiguous fashion. 
> 
> Your own comment says this should be considered ambiguous. It’s unambiguous 
> now. What I am asking is how is that an improvement?

I suggest { _ in ... } is ambiguous only in case of function overloading. In 
this case, you have { (_) in ... } and { (_,_) in ... } for disambiguation:

func overloaded(_ closure: (Int, Int) -> Int) -> String { return 
"overloaded 1" }
func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
return "overloaded 2" }
overloaded { _ in 1 }  // error: ambiguous use of ‘overloaded'
overloaded { (_) in 1 }// "overloaded 1”
overloaded { (_, _) in 1 } // "overloaded 2”

When a function is not overloaded, then { _ in ... } would always mean "I don't 
care", and is always accepted except for closures that take no argument at all:

func f1(_ closure: () -> Int) -> String { return "f1" }
func f2(_ closure: (Int) -> Int) -> String { return "f2" }
func f3(_ closure: (Int, Int) -> Int) -> String { return "f3" }
func f4(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "f4" }

f1 { _ in 1 }  // error

f2 { _ in 1 }  // OK, you don't care

f3 { _ in 1 }  // OK, you don't care
f3 { (_, _) in 1 } // OK, just what I expected!

f4 { _ in 1 }  // OK, you don't care
f4 { (_) in 1 }// OK, just what I expected!
f4 { (_, _) in 1 } // OK, maybe you use tuple splatting somewhere else and 
want to be consistent

All this is *possible*. And I don't see how it breaks anything. On the other 
side, it eases everyday life, reduces clutter, and avoids useless punctuation.
Gwendal

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

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

[Mark Lacey via swift-evolution]

> 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é >> > wrote:
>>> 
> 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 
> "overloaded 1" }
> func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
> return "overloaded 2" }
> 
> // not overloaded => not ambiguous
> notOverloaded1 { x, y in x + y }
> notOverloaded1 { (x, y) in x + y }
> notOverloaded1 { _ in 1 }
> notOverloaded2 { x, y in x + y }
> notOverloaded2 { (x, y) in x + y }
> notOverloaded2 { _ in 1 }
> 
> // overloaded => resolve ambiguity on closure argument, when possible
> overloaded { x, y in x + y }// "overloaded 1"
> overloaded { (x, y) in x + y }  // "overloaded 1"
> overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
> overloaded { (t) in t.lhs + t.rhs } // "overloaded 2”
 
 This is exactly what happens today as a result of SE-0110 since the first 
 two calls take two arguments, and the next two take a single argument.
>>> 
>>> No, as a playground quickly reveals:
>> 
>> I was specifically referring to the last four statements but could have made 
>> that more clear.
>> 
>>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return 
>>> "notOverloaded1" }
>>> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String 
>>> { return "notOverloaded3" }
>>> 
>>> // not overloaded => not ambiguous
>>> notOverloaded1 { x, y in x + y }
>>> notOverloaded1 { (x, y) in x + y }
>>> notOverloaded1 { _ in 1 }  // Swift 4 error
>> 
>> This really should be an error.
> 
> I argue this is a subjective statement, and my own subjective statement is 
> that it should not to be an error. So that { _ in ... } would always mean "I 
> don't care".
> 
>> It’s one thing to say that { x, y in } should work as it used to in the case 
>> where a closure taking a tuple is expected, but something else entirely to 
>> say that _ should work in any case, regardless of whether a closure taking N 
>> arguments or a closure taking an N-tuple is expected for any N. I can see a 
>> desire to make _ work for any tuple, and _, _ work for a two-tuple based on 
>> context if e.g. “x, y in” also works, but not for _ working where a closure 
>> requiring N independent arguments is expected.
> 
> Yes. That's why it's subjective. You argue that you don't like it, not that 
> it's impossible to do. Because you can't prove it's impossible to do.

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 subjective statement” to 
make a subjective statement.

> Because I have shown that it is.
> In a nice manner that is easy to developers.
> 
>> 
>>> notOverloaded2 { x, y in x + y }   // Swift 4 error
>>> notOverloaded2 { (x, y) in x + y } // Swift 4 error
>> 
>> In these cases using the tuple labels works as well (as it does in your 
>> examples where the overloaded function is involved). I’m not arguing that 
>> it’s as good as being able to do the apparent destructuring, but just want 
>> to point out that it works. I didn’t get the sense from your email that you 
>> found that objectionable in the cases involving overloads, but perhaps you 
>> do.
>> 
>>> notOverloaded2 { _ in 1 }
>>> 
>>> Those errors are the famous regressions we want to fix.
>>> 
> overloaded { _ in 1 }   // error: ambiguous use of 
> ‘overloaded'
 
 With SE-0110 in its current form, this calls the tuple version since there 
 is a single closure parameter listed.
>>> 
>>> It would be nicer if. { _ in ... } would always mean "I don't care". With 
>>> an ambiguity in the sample code we're looking at, and a compiler error.
>> 
>> How does making something that is unambiguous today actually be ambiguous 
>> improve things?
> 
> I *do* suggest a specific handling of { _ ... }. I have shown how it can be 
> implemented in a non-ambiguous fashion.

Your own comment says this should be considered ambiguous. It’s unambiguous 
now. What I am asking is how is that an improvement?

Mark

> Please don't act as if I did not.

> 
> Now the specific case of { _ ... } is interesting, but I wouldn't make it as 
> important as the other regressions.
> 
> I should make an exhaustive compilation of Swift 4 

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

[Gwendal Roué via swift-evolution]

> 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" }
 func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> 
 String { return "notOverloaded3" }
 
 func overloaded(_ closure: (Int, Int) -> Int) -> String { return 
 "overloaded 1" }
 func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
 return "overloaded 2" }
 
 // not overloaded => not ambiguous
 notOverloaded1 { x, y in x + y }
 notOverloaded1 { (x, y) in x + y }
 notOverloaded1 { _ in 1 }
 notOverloaded2 { x, y in x + y }
 notOverloaded2 { (x, y) in x + y }
 notOverloaded2 { _ in 1 }
 
 // overloaded => resolve ambiguity on closure argument, when possible
 overloaded { x, y in x + y }// "overloaded 1"
 overloaded { (x, y) in x + y }  // "overloaded 1"
 overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
 overloaded { (t) in t.lhs + t.rhs } // "overloaded 2”
>>> 
>>> This is exactly what happens today as a result of SE-0110 since the first 
>>> two calls take two arguments, and the next two take a single argument.
>> 
>> No, as a playground quickly reveals:
> 
> I was specifically referring to the last four statements but could have made 
> that more clear.
> 
>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return 
>> "notOverloaded1" }
>> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String 
>> { return "notOverloaded3" }
>> 
>> // not overloaded => not ambiguous
>> notOverloaded1 { x, y in x + y }
>> notOverloaded1 { (x, y) in x + y }
>> notOverloaded1 { _ in 1 }  // Swift 4 error
> 
> This really should be an error.

I argue this is a subjective statement, and my own subjective statement is that 
it should not to be an error. So that { _ in ... } would always mean "I don't 
care".

> It’s one thing to say that { x, y in } should work as it used to in the case 
> where a closure taking a tuple is expected, but something else entirely to 
> say that _ should work in any case, regardless of whether a closure taking N 
> arguments or a closure taking an N-tuple is expected for any N. I can see a 
> desire to make _ work for any tuple, and _, _ work for a two-tuple based on 
> context if e.g. “x, y in” also works, but not for _ working where a closure 
> requiring N independent arguments is expected.

Yes. That's why it's subjective. You argue that you don't like it, not that 
it's impossible to do. Because you can't prove it's impossible to do. Because I 
have shown that it is. In a nice manner that is easy to developers.

> 
>> notOverloaded2 { x, y in x + y }   // Swift 4 error
>> notOverloaded2 { (x, y) in x + y } // Swift 4 error
> 
> In these cases using the tuple labels works as well (as it does in your 
> examples where the overloaded function is involved). I’m not arguing that 
> it’s as good as being able to do the apparent destructuring, but just want to 
> point out that it works. I didn’t get the sense from your email that you 
> found that objectionable in the cases involving overloads, but perhaps you do.
> 
>> notOverloaded2 { _ in 1 }
>> 
>> Those errors are the famous regressions we want to fix.
>> 
 overloaded { _ in 1 }   // error: ambiguous use of 
 ‘overloaded'
>>> 
>>> With SE-0110 in its current form, this calls the tuple version since there 
>>> is a single closure parameter listed.
>> 
>> It would be nicer if. { _ in ... } would always mean "I don't care". With an 
>> ambiguity in the sample code we're looking at, and a compiler error.
> 
> How does making something that is unambiguous today actually be ambiguous 
> improve things?

I *do* suggest a specific handling of { _ ... }. I have shown how it can be 
implemented in a non-ambiguous fashion. Please don't act as if I did not.

Now the specific case of { _ ... } is interesting, but I wouldn't make it as 
important as the other regressions.

I should make an exhaustive compilation of Swift 4 regressions, so that you 
opponents can see how *far* things have changed, fixing a few corner cases, and 
breaking tons of valid code. At least we could discuss each case in isolation.

Gwendal

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

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

[Mark Lacey via swift-evolution]

> 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" }
>>> 
>>> func overloaded(_ closure: (Int, Int) -> Int) -> String { return 
>>> "overloaded 1" }
>>> func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
>>> return "overloaded 2" }
>>> 
>>> // not overloaded => not ambiguous
>>> notOverloaded1 { x, y in x + y }
>>> notOverloaded1 { (x, y) in x + y }
>>> notOverloaded1 { _ in 1 }
>>> notOverloaded2 { x, y in x + y }
>>> notOverloaded2 { (x, y) in x + y }
>>> notOverloaded2 { _ in 1 }
>>> 
>>> // overloaded => resolve ambiguity on closure argument, when possible
>>> overloaded { x, y in x + y }// "overloaded 1"
>>> overloaded { (x, y) in x + y }  // "overloaded 1"
>>> overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
>>> overloaded { (t) in t.lhs + t.rhs } // "overloaded 2”
>> 
>> This is exactly what happens today as a result of SE-0110 since the first 
>> two calls take two arguments, and the next two take a single argument.
> 
> No, as a playground quickly reveals:

I was specifically referring to the last four statements but could have made 
that more clear.

> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return 
> "notOverloaded1" }
> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
> return "notOverloaded3" }
> 
> // not overloaded => not ambiguous
> notOverloaded1 { x, y in x + y }
> notOverloaded1 { (x, y) in x + y }
> notOverloaded1 { _ in 1 }  // Swift 4 error

This really should be an error. It’s one thing to say that { x, y in } should 
work as it used to in the case where a closure taking a tuple is expected, but 
something else entirely to say that _ should work in any case, regardless of 
whether a closure taking N arguments or a closure taking an N-tuple is expected 
for any N. I can see a desire to make _ work for any tuple, and _, _ work for a 
two-tuple based on context if e.g. “x, y in” also works, but not for _ working 
where a closure requiring N independent arguments is expected.

> notOverloaded2 { x, y in x + y }   // Swift 4 error
> notOverloaded2 { (x, y) in x + y } // Swift 4 error

In these cases using the tuple labels works as well (as it does in your 
examples where the overloaded function is involved). I’m not arguing that it’s 
as good as being able to do the apparent destructuring, but just want to point 
out that it works. I didn’t get the sense from your email that you found that 
objectionable in the cases involving overloads, but perhaps you do.

> notOverloaded2 { _ in 1 }
> 
> Those errors are the famous regressions we want to fix.
> 
>>> overloaded { _ in 1 }   // error: ambiguous use of 
>>> ‘overloaded'
>> 
>> With SE-0110 in its current form, this calls the tuple version since there 
>> is a single closure parameter listed.
> 
> It would be nicer if. { _ in ... } would always mean "I don't care". With an 
> ambiguity in the sample code we're looking at, and a compiler error.

How does making something that is unambiguous today actually be ambiguous 
improve things?

Mark

> The { (_, _) in ... } form is arguably cluttered, and it would be nicer it is 
> was required only for disambiguition.
> 
>>> overloaded { (_) in 1 } // "overloaded 1”
>> 
>> With SE-0110 in its current form, this calls the tuple version since there 
>> is a single closure parameter listed. I don’t understand why you would 
>> suggest this should call the two-argument version since that’s inconsistent 
>> with the other closures above that have a single argument.
>> 
>>> overloaded { (_, _) in 1 }  // "overloaded 2”
>> 
>> With SE-0110 in its current form, this calls the two-argument version since 
>> there are two listed arguments.
> 
> I was wrong, sorry. I meant what you replied.
> 
> Gwendal
> 

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

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

[Gwendal Roué via swift-evolution]

>> 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 
>> "overloaded 1" }
>> func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
>> return "overloaded 2" }
>> 
>> // not overloaded => not ambiguous
>> notOverloaded1 { x, y in x + y }
>> notOverloaded1 { (x, y) in x + y }
>> notOverloaded1 { _ in 1 }
>> notOverloaded2 { x, y in x + y }
>> notOverloaded2 { (x, y) in x + y }
>> notOverloaded2 { _ in 1 }
>> 
>> // overloaded => resolve ambiguity on closure argument, when possible
>> overloaded { x, y in x + y }// "overloaded 1"
>> overloaded { (x, y) in x + y }  // "overloaded 1"
>> overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
>> overloaded { (t) in t.lhs + t.rhs } // "overloaded 2”
> 
> This is exactly what happens today as a result of SE-0110 since the first two 
> calls take two arguments, and the next two take a single argument.

No, as a playground quickly reveals:

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

// not overloaded => not ambiguous
notOverloaded1 { x, y in x + y }
notOverloaded1 { (x, y) in x + y }
notOverloaded1 { _ in 1 }  // Swift 4 error
notOverloaded2 { x, y in x + y }   // Swift 4 error
notOverloaded2 { (x, y) in x + y } // Swift 4 error
notOverloaded2 { _ in 1 }

Those errors are the famous regressions we want to fix.

>> overloaded { _ in 1 }   // error: ambiguous use of 
>> ‘overloaded'
> 
> With SE-0110 in its current form, this calls the tuple version since there is 
> a single closure parameter listed.

It would be nicer if. { _ in ... } would always mean "I don't care". With an 
ambiguity in the sample code we're looking at, and a compiler error.

The { (_, _) in ... } form is arguably cluttered, and it would be nicer it is 
was required only for disambiguition.

>> overloaded { (_) in 1 } // "overloaded 1”
> 
> With SE-0110 in its current form, this calls the tuple version since there is 
> a single closure parameter listed. I don’t understand why you would suggest 
> this should call the two-argument version since that’s inconsistent with the 
> other closures above that have a single argument.
> 
>> overloaded { (_, _) in 1 }  // "overloaded 2”
> 
> With SE-0110 in its current form, this calls the two-argument version since 
> there are two listed arguments.

I was wrong, sorry. I meant what you replied.

Gwendal

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

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

[Mark Lacey via swift-evolution]

> 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* 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 Swift 4.
>> 
>> But, as was said by Mark Lacey in this thread later, there is an "overload" 
>> problem for such solution, when closure of kind {x, y in ..} can be sent to 
>> overloaded func like here:
>> 
>> func overloaded(_ fn: (Int, Int) -> Int) { fn(1,2) }
>> func overloaded(_ fn: ((Int, Int)) -> Int) { fn((3,4)) }
>> 
>> overloaded { x, y in x + y }
>> overloaded { (x, y) in x + y }
>> 
>> Compiler is not able to determinate which type of closure do you want in 
>> each case. For ((Int,Int))->Int you still need some 'specific' syntax which 
>> disambiguate the call. So we *still* need some good syntax to destructure 
>> tuple argument in closure to use in place of ((Int,Int))->Int closure.
>> 
>> This means that there is no sense to allow very 'magic' {x,y in ..} syntax 
>> and compiler-detected type of closure if we still need good syntax 
>> for destructuring tuple argument in ((Int,Int))->().
> 
> Yes, Mark was very right asking about overloads. But is it a problem that 
> does not have a solution which preserves ergonomics?
> 
> 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 
> "overloaded 1" }
> func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
> return "overloaded 2" }
> 
> // not overloaded => not ambiguous
> notOverloaded1 { x, y in x + y }
> notOverloaded1 { (x, y) in x + y }
> notOverloaded1 { _ in 1 }
> notOverloaded2 { x, y in x + y }
> notOverloaded2 { (x, y) in x + y }
> notOverloaded2 { _ in 1 }
> 
> // overloaded => resolve ambiguity on closure argument, when possible
> overloaded { x, y in x + y }// "overloaded 1"
> overloaded { (x, y) in x + y }  // "overloaded 1"
> overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
> overloaded { (t) in t.lhs + t.rhs } // "overloaded 2”

This is exactly what happens today as a result of SE-0110 since the first two 
calls take two arguments, and the next two take a single argument.

> overloaded { _ in 1 }   // error: ambiguous use of 
> ‘overloaded'

With SE-0110 in its current form, this calls the tuple version since there is a 
single closure parameter listed.

> overloaded { (_) in 1 } // "overloaded 1”

With SE-0110 in its current form, this calls the tuple version since there is a 
single closure parameter listed. I don’t understand why you would suggest this 
should call the two-argument version since that’s inconsistent with the other 
closures above that have a single argument.

> overloaded { (_, _) in 1 }  // "overloaded 2”

With SE-0110 in its current form, this calls the two-argument version since 
there are two listed arguments.

Mark

> See the error on `overloaded { _ in 1 }`, because _ means "I don't care". 
> Well, here you have to care because of overloading. Ambiguity is resolved 
> with parenthesis. This is a specific behavior for `_`.
> 
> Gwendal
> 
> ---
> 
> PS, I had a little look at how Swift 3 currently behave with overloading ? 
> Badly, actually:
> 
> // SWIFT 3
> 
> func f(_ closure: (Int, Int) -> Int) -> String { return "two arguments" }
> // error: invalid redeclaration of 'f'
> // func f(_ closure: ((Int, Int)) -> Int) -> String { return "one 
> anonymous tuple argument" }
> func f(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "one 
> named tuple argument" }
> 
> // error: ambiguous use of 'f'
> // f { x, y in x + y }
> 
> f { t in t.rhs + t.lhs } // "one named tuple argument"
> 
> // error: ambiguous use of 'f'
> // f { t in t.0 + t.1 } // "one named tuple argument"
> 
> // error: ambiguous use of 'f'
> let c = { (a: Int, b: Int) -> Int in a + b }
> type(of: c) // ((Int, Int) -> Int).Type
> // error: ambiguous use of 'f'
> // f(c)
> 
> Swift 3 does not allow overloading ((Int, Int)) -> Int and (Int, Int) -> Int, 
> but allows overloading ((lhs: Int, rhs: Int)) -> Int and (Int, Int) -> Int.
> 
> Yet I could never call the (Int, Int) -> Int version, even when I provide 
> with a function that exactly matches its signature. And there are much too 
> many ambiguous situations the compiler can't deal with.
> 
> So yes, there is a problem with Swift 3.
> 
> How is it with Swift 4 (2017-06-02 snapshot)?
> 
> // 

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

[Gwendal Roué via swift-evolution]

> 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 Swift 4.
> 
> But, as was said by Mark Lacey in this thread later, there is an "overload" 
> problem for such solution, when closure of kind {x, y in ..} can be sent to 
> overloaded func like here:
> 
> func overloaded(_ fn: (Int, Int) -> Int) { fn(1,2) }
> func overloaded(_ fn: ((Int, Int)) -> Int) { fn((3,4)) }
> 
> overloaded { x, y in x + y }
> overloaded { (x, y) in x + y }
> 
> Compiler is not able to determinate which type of closure do you want in each 
> case. For ((Int,Int))->Int you still need some 'specific' syntax which 
> disambiguate the call. So we *still* need some good syntax to destructure 
> tuple argument in closure to use in place of ((Int,Int))->Int closure.
> 
> This means that there is no sense to allow very 'magic' {x,y in ..} syntax 
> and compiler-detected type of closure if we still need good syntax 
> for destructuring tuple argument in ((Int,Int))->().

Yes, Mark was very right asking about overloads. But is it a problem that does 
not have a solution which preserves ergonomics?

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 
"overloaded 1" }
func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { 
return "overloaded 2" }

// not overloaded => not ambiguous
notOverloaded1 { x, y in x + y }
notOverloaded1 { (x, y) in x + y }
notOverloaded1 { _ in 1 }
notOverloaded2 { x, y in x + y }
notOverloaded2 { (x, y) in x + y }
notOverloaded2 { _ in 1 }

// overloaded => resolve ambiguity on closure argument, when possible
overloaded { x, y in x + y }// "overloaded 1"
overloaded { (x, y) in x + y }  // "overloaded 1"
overloaded { t in t.lhs + t.rhs }   // "overloaded 2"
overloaded { (t) in t.lhs + t.rhs } // "overloaded 2"
overloaded { _ in 1 }   // error: ambiguous use of 'overloaded'
overloaded { (_) in 1 } // "overloaded 1"
overloaded { (_, _) in 1 }  // "overloaded 2"

See the error on `overloaded { _ in 1 }`, because _ means "I don't care". Well, 
here you have to care because of overloading. Ambiguity is resolved with 
parenthesis. This is a specific behavior for `_`.

Gwendal

---

PS, I had a little look at how Swift 3 currently behave with overloading ? 
Badly, actually:

// SWIFT 3

func f(_ closure: (Int, Int) -> Int) -> String { return "two arguments" }
// error: invalid redeclaration of 'f'
// func f(_ closure: ((Int, Int)) -> Int) -> String { return "one anonymous 
tuple argument" }
func f(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "one 
named tuple argument" }

// error: ambiguous use of 'f'
// f { x, y in x + y }

f { t in t.rhs + t.lhs } // "one named tuple argument"

// error: ambiguous use of 'f'
// f { t in t.0 + t.1 } // "one named tuple argument"

// error: ambiguous use of 'f'
let c = { (a: Int, b: Int) -> Int in a + b }
type(of: c) // ((Int, Int) -> Int).Type
// error: ambiguous use of 'f'
// f(c)

Swift 3 does not allow overloading ((Int, Int)) -> Int and (Int, Int) -> Int, 
but allows overloading ((lhs: Int, rhs: Int)) -> Int and (Int, Int) -> Int.

Yet I could never call the (Int, Int) -> Int version, even when I provide with 
a function that exactly matches its signature. And there are much too many 
ambiguous situations the compiler can't deal with.

So yes, there is a problem with Swift 3.

How is it with Swift 4 (2017-06-02 snapshot)?

// SWIFT 4

func f(_ closure: (Int, Int) -> Int) -> String { return "two arguments" }
// error: invalid redeclaration of 'f'
// func f(_ closure: ((Int, Int)) -> Int) -> String { return "one anonymous 
tuple argument" }
func f(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "one 
named tuple argument" }

f { x, y in x + y }  // "two arguments"
f { t in t.rhs + t.lhs } // "one named tuple argument"
f { t in t.0 + t.1 } // "one named tuple argument"

let c = { (a: Int, b: Int) -> Int in a + b }
type(of: c)  // ((Int, Int) -> Int).Type
f(c) // "two arguments"

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

Re: [swift-evolution] Int indexing into UTF16View

[Félix Cloutier via swift-evolution]

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 working with Strings which are known to be ASCII, I tend to use the 
>>> UTF16View for the performance of random access. 
>> 
>> About the performance. Do we have a guarantee that 'barcode' declared in 
>> code and/or containing only ASCII chars internally stored as UTF16 ? 
>> Otherwise, as I understand, you'll have a performance penalty calling utf16 
>> when internal storage is in UTF8 for example, no?
> 
> I'm fairly sure the internal storage of String is always UTF16.
> 
>> I would also like to have the convenience of indexing with Int:
>>> let barcode = "M1X/CLEMENT   EELT9QBQGVAAMSEZY1353 244 21D 531  
>>> 10A1311446838”
>>> let name = barcode.utf16[2..<22]
>>> let pnrCode = barcode.utf16[23..<30]
>>> let seatNo = barcode.utf16[47..<51]
>>> let fromCity = barcode.utf16[30..<33]
>>> let toCity = barcode.utf16[33..<36]
>>> let carrier = barcode.utf16[36..<39]
>>> let flightNumber = barcode.utf16[39..<44]
>>> let day = barcode.utf16[44..<47]
>>> I define my own subscript in an extension to UTF16View but I think this 
>>> should go in the Standard Library.
>>> Any thoughts?
>>> David.
>>> ___
>>> 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