Re: [swift-evolution] Removing "_ in" from empty closures

[Chris Lattner via swift-evolution]

On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution 
 wrote:
>> This encourages the use of empty closures over optional closures, which I 
>> think is open for debate. In general I try to avoid optionals when they can 
>> be precisely replaced with a non-optional value. Furthermore, most Cocoa 
>> completion handlers are not optional.
>> 
>> The alternative is to not do this, but encourage that any closure that could 
>> reasonably be empty should in fact be optional. I would then want Cocoa 
>> functions with void-returning closures to be imported as optionals to avoid 
>> "{ _ in }".
> 
> +1. In general, I think we should allow implicit arguments, without requiring 
> the closure to use all the implicit $n variables like we do today. These 
> should all be valid:
> 
> let _: () -> () = {}
> let _: (Int) -> () = {}
> let _: (Int, Int) -> Int = { 5 }
> let _: (Int, Int) -> Int = { $0 }
> let _: (Int, Int) -> Int = { $1 }

I agree, but I consider this to be an obvious bug in the compiler.  I don’t 
think it requires a proposal.

Unfortunately it is non-trivial to fix…

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

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

[Chris Lattner via swift-evolution]

> On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution 
>  wrote:
> 
> For some protocols we'd like to require top-level (free) functions, e.g. for 
> many math functions such as abs() or sin(). We already do this implicitly for 
> operators. 

Hi Patrick,

FYI, we’re very likely to remove this special behavior for operators, by making 
operator requirements only find operators declared in a conforming type.  This 
would eliminate the special case for operators that exists now, and has other 
advantages as well.  Check out this proposal for more information:
https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md

-Chris

> 
> Proposal
> Allow top-level function/property requirements in protocols, e.g.:
> 
> public protocol AbsoluteValuable : SignedNumber {
>   /// Returns the absolute value of `x`.
>   @warn_unused_result
>   toplevel func abs(_ x: Self) -> Self
> }
> 
> We'd probably want to require this for operators. This also opens up syntax 
> if we ever get dynamically dispatched operators.
> 
> public protocol SignedNumber : Comparable, IntegerLiteralConvertible {
>   /// Returns the result of negating `x`.
>   @warn_unused_result
>   toplevel prefix func - (x: Self) -> Self
> }
> 
> Currently this is done using the combination of a static method and a 
> top-level generic function on that protocol. As I understand that approach 
> does have some benefits in terms of type-checker performance, though I'm not 
> sure whether that is likely to stay relevant in the future.
> 
> Advantages
> Cleaner than current approach (esp. floating point types have tons of 
> top-level functions)
> Makes operators less of a special case
> Opens up syntax for member operators
> Could also apply to top-level properties (esp. useful if we get generic 
> properties, for e.g. π<...>)
> ___
> 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] "AnyValue", "protocol MyProtocol : value" as counterpart to "AnyObject", ": class"

[Karl via swift-evolution]

I was building a collection object recently, which stores an array of tuples: 
(Range, T) - some generic type, and a range. 
Part of the workings of the collection involves splitting these tuples, which 
means we need to split the Range (easy enough) and duplicate T.

In practice, I was using value types for T (it was another Array), so I could 
duplicate by assignment; but what if somebody stuck an NSArray or other 
reference-type in instead?

My first thought was - I could allow it, create some “Copyable” protocol and 
require conformance. But there are other guarantees I get from value types as 
well. Let’s say I had a sorted Array of T; if T could be a reference-type, 
anybody who gets a T from the collection could mutate it and invalidate the 
sort order at any time! That could lead to unexpected behaviour, such as 
infinite loops in binary-search algorithms, and it might not be obvious to a 
user of the collection how that happened (or that it’s even their fault - how 
are they supposed to know this is kept in a sorted Array, especially if it’s 
wrapped by another type, and that this particular search algorithm could 
infinitely loop if the Array is not sorted?). I could return a copy from the 
getter, but at this point I’m basically re-inventing value-type semantics for 
classes while creating burdensome requirements for actual value-types.

Actually, this is a problem with the language in general. While we have a way 
to specify that a generic type or protocol must obey reference-type semantics 
(via “”, “protocol MyProtocol : class”), we don’t have a 
value-type semantic counterpart.

So I’d like to see us provide an “AnyValue” and “value” equivalent. We should 
be able to require that generic types or protocols are satisfied by values so 
we know how to treat them.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Karl Wagner via swift-evolution]

> IMHO proposals like this should never be discussed in the context of trivial 
> examples as the full scope of their value gets lost. I have written enough 
> generics code in other languages to appreciate the idea of a 
> 'headline-form-followed-by-the-details-idea' for any complex declaration. My 
> understanding is that the proposal offers to make us write explicitely what 
> anyone reading the code will try to extract out of the declaration. Instead 
> of 100's or 1000's doing the work in their heads, the code author does it 
> once for all subsequent readers. What's not to like about this idea?

There is a lot not to like about the idea; even if it was optional. Personally, 
I feel the problem is solved in a much, much more elegant manner by other 
proposals.

Firstly, the stuff after the ‘where’ clause is getting shorter once typealiases 
come to protocols. C.Iterator.Element become C.Element. In this one example, 
that’s 18 characters down to 9 - a 50% reduction in length. We tend to use 
quite expressive names for associated types, so I expect we’ll see similar 
gains elsewhere from this very simple proposal.

Not only that, but there’s a very good proposal to add ‘where’ clauses to 
associated types in the protocols themselves, which will likely further reduce 
the verbosity of the constraints you need to specify at each declaration site. 
https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/-associated-types-constraints.md
 


And then we have generic typealiases and generalised existentials, which would 
allow us to wrap those ‘where’ clauses in to something much more intelligible 
to a human being at first glance. ‘StringCollection’ or ‘CollectionOfStrings’ 
is much clearer than , no matter how you 
chop it up.

If I look at the other proposals, and where we are headed with much more 
expressive typealiases and associated types, I just feel that that’s the 
future: that’s the “swift’ way. It’s like type inference - all of the strict 
constraints are still there under-the-hood, but you’re able to work at a much 
clearer and more obvious abstraction level. This proposal pulls us further away 
from things like ‘obviousness’, and like I said, simply feels like an inelegant 
solution.

At the very least, I think we should shelve the discussion until the larger 
expansion of typealiases, etc is complete. We should re-evaluate at that time, 
with a bigger set of more general-purpose tools to produce readable code.


> On 14 May 2016, at 22:28, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> 
> 
> On May 14, 2016, at 9:43 PM, Pyry Jahkola via swift-evolution 
> > wrote:
> 
>> Tony & Haravikk,
>> 
>> (Reformatting your quoted examples just a bit…)
>> 
 It enables things like:
 func someMethod(value: S) -> AnySequence
 where S.Generator.Element == T { ... }
>>> 
>>> I'm not assuming that. Under the current syntax, I would format your 
>>> example as:
>>> 
>>> func someMethod<
>>> S : SequenceType, T
>>> where S.Generator.Element == T
>>> >(value: S) -> AnySequence {
>>> ...
>>> }
>> 
>> You are both right here, but please note that the proposal still also allows 
>> moving all constraints to the `where` clause:
>> 
>> func someMethod(value: S) -> AnySequence
>> where S : SequenceType,
>>   S.Generator.Element == T
>> {
>> ...
>> }
>> 
>> just like Swift 2 allows doing so within the `<...>` brackets:
>> 
>> func someMethod> where S : SequenceType, S.Generator.Element == T
>> >(value: S) -> AnySequence {
>> ...
>> }
>> 
>> The reason I'd recommend that style for anything but simple constraints is 
>> because:
>> 
>> 1) It makes the call site `let items = someMethod(value: things)` lightest 
>> to visually match to the declaration, because the only thing between the 
>> function name and its argument list is the `<...>` bracketed list of 
>> introduced generic types which you'll expect to see in the function 
>> signature and constraints.
>> 
>> 2) In general, the `where` constraints really apply to the whole 
>> function/type declaration, not just a single generic parameter.
>> 
>> 3) It was claimed that all constraints should go right next to the 
>> introduction of the generic parameters. But that isn't the whole case 
>> because Swift also applies implicit constraints onto any generic parameters 
>> that are used in constrained positions. If that wasn't clearly said, take 
>> the following example in Swift 2.x:
>> 
>> func aMethod(value: 
>> S) -> Set {
>> return Set(value)
>> }
>> 
>> That declaration actually makes you wait all the way until the return type 
>> `Set` until 

[swift-evolution] Allow commits or branches in the Swift Package Manager instead of Version

[Tyler Fleming Cloutier via swift-evolution]

Has there been any discussion on allowing direct specification of commits or 
branches for the Swift Package Manager on the list? Currently it only supports 
semantic versioning tags, which makes for a tricky development process for 
developers adding Swift 3 support to their packages.

For example, consider a Swift 2.2 library that is tagged with 0.2.0. If 
developer wants to support Swift 3, they have to either add Swift 3 support 
with #if swift directives which is difficult due to the large number of source 
changes in Swift 3 and then tag an maintain the new version in the normal way, 
or maintain a separate Swift 3 branch. Maintaining a separate branch is tricky 
because in order to use Swift PM you have to tag commits on the new branch. 
Would this new branch be tagged 0.3.0? What if there needs to be a new release 
under Swift 2.2? It’s also unfortunate because the developer has no way of 
letting other developers use the package without creating a release tag.

This difficultly would me drastically mitigated if Swift PM allowed the 
tracking of the latest commit on a branch, or the ability to specify a 
particular commit as a version.

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Maximilian Hünenberger via swift-evolution]

One point which should be discussed is the following behaviour:

let array = [0]
// ranges are completely out of bounds and produce an error
array[clamping: 1...2] // error
array[clamping: -2...-1] // error

Should a range which has no intersection with the indices of the collection 
produce an error or just clamp to 0..<0 respectively endIndex.. Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution 
> :
> 
> It seems that there is a consensus that this proposal might be a good 
> addition to the standard library. All comments on this thread in the past few 
> weeks were related to naming, not around the behaviour or validity of the 
> proposed methods. So I will submit this proposal for review very soon 
> assuming that nobody else has strong arguments against it. :-)
> 
> Proposal: 
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
> 
> If you have any corrections or suggestions to the proposal text itself, 
> please comment on this gist:
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
> (or pull request to my repo)
> 
> Regards,
> 
> - Luis
> 
>> On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa  
>> wrote:
>> Please let me know if you have more suggestions or corrections on this 
>> proposal. 
>> I'm tempted to submit it for review. :-)
>> 
>> - Luis
>> 
>>> On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa 
>>>  wrote:
>>> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
>>> 
>>> I've just updated the proposal: 
>>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>>> 
>>> - Luis
>>> 
 On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution 
  wrote:
 Yes, I feel like 'within' is much better than 'bounded'.
 
 How about such changes in proposal:
 
 a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or a[inside: -1 ..< 5] )
 
 a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
 a[optional: 5]-->  a[checking: 5]
 
 ?
 
> On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:
> I like the idea of the of the bounded subscript, however the optional one 
> I
> feel could be used for clumsy code.
> 
> .first and .last have value, but once you start stepping several arbitrary
> indices in, then that code is likely fragile?
> 
> 
> I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names
> for ‘bounded’ that attempt to explain what is going on:
> 
> let a = [1, 2, 3]
> 
> a[within: 0 ..< 5] // [1, 2, 3]
> a[inside: 0 ..< 5] // [1, 2, 3]
> a[intersecting: 0 ..< 5] // [1, 2, 3]
> 
> 
>> On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution
>> > wrote:
>> 
>> As we have discussed throughout this thread, the initial proposal was
>> modified to include alternative subscript methods instead of modifying
>> the default operator/subscript behaviour.
>> The first draft is
>> here: 
>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>> 
>> I've also put this as a gist so that you can leave comments with respect
>> to the proposal document itself. Any suggestion or help is very welcome.
>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
>> 
>> Regards,
>> 
>> - Luis
>> 
>> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa
>> > wrote:
>> 
>> This proposal seeks to provide a safer ..< (aka half-open range
>> operator) in order to avoid **Array index out of range** errors in
>> execution time.
>> 
>> Here is my first draft for this proposal:
>> 
>> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
>> 
>> In short, doing that in Swift causes a runtime error:
>> 
>> leta =[1,2,3]
>> letb =a[0..<5]
>> print(b)
>> 
>> > Error running code:
>> > fatal error: Array index out of range
>> 
>> The proposed solution is to slice the array returning all elements
>> that are below the half-open operator, even though the number of
>> elements is lesser than the ending of the half-open operator. So the
>> example above would return [1,2,3].
>> We can see this very behaviour in other languages, such as Python and
>> Ruby as shown in the proposal draft.
>> 
>> This would 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

Sorry... to be clear, I think what WHERE worked very well when included in each 
declaration, but that WITH works much better when ALL clauses are coalesced at 
the end.

> On May 14, 2016, at 10:39 PM, L. Mihalkovic  
> wrote:
> 
> My only reservation would be the choice of WHERE which I would have kept for=
> more *dynamic* situations int the language. My first choice for this would h=
> ave been WITH which in my minds carries a more permanent, intemporal connota=
> tion in my mind. But that is off topic for this discussion.
> 
>> On May 14, 2016, at 9:43 PM, Pyry Jahkola via swift-evolution 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

My only reservation would be the choice of WHERE which I would have kept for 
more *dynamic* situations int the language. My first choice for this would have 
been WITH which in my minds carries a more permanent, intemporal connotation in 
my mind. But that is off topic for this discussion.

> On May 14, 2016, at 9:43 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Tony & Haravikk,
> 
> (Reformatting your quoted examples just a bit…)
> 
>>> It enables things like:
>>> func someMethod(value: S) -> AnySequence
>>> where S.Generator.Element == T { ... }
>> 
>> I'm not assuming that. Under the current syntax, I would format your example 
>> as:
>> 
>> func someMethod<
>> S : SequenceType, T
>> where S.Generator.Element == T
>> >(value: S) -> AnySequence {
>> ...
>> }
> 
> You are both right here, but please note that the proposal still also allows 
> moving all constraints to the `where` clause:
> 
> func someMethod(value: S) -> AnySequence
> where S : SequenceType,
>   S.Generator.Element == T
> {
> ...
> }
> 
> just like Swift 2 allows doing so within the `<...>` brackets:
> 
> func someMethod where S : SequenceType, S.Generator.Element == T
> >(value: S) -> AnySequence {
> ...
> }
> 
> The reason I'd recommend that style for anything but simple constraints is 
> because:
> 
> 1) It makes the call site `let items = someMethod(value: things)` lightest to 
> visually match to the declaration, because the only thing between the 
> function name and its argument list is the `<...>` bracketed list of 
> introduced generic types which you'll expect to see in the function signature 
> and constraints.
> 
> 2) In general, the `where` constraints really apply to the whole 
> function/type declaration, not just a single generic parameter.
> 
> 3) It was claimed that all constraints should go right next to the 
> introduction of the generic parameters. But that isn't the whole case because 
> Swift also applies implicit constraints onto any generic parameters that are 
> used in constrained positions. If that wasn't clearly said, take the 
> following example in Swift 2.x:
> 
> func aMethod(value: 
> S) -> Set {
> return Set(value)
> }
> 
> That declaration actually makes you wait all the way until the return type 
> `Set` until you learn that `T` must also necessarily be `Hashable`. So I 
> don't see how it's that different if the `where` clause isn't right next to 
> the generic type arguments' introduction:
> 
> func aMethod(value: S) -> Set // FWIW, this line contains what I 
> usually have in mind when browsing code.
> where // T : Hashable, // (implicit)
>   S : SequenceType,
>   S.Generator.Element == T
> {
> return Set(value)
> }
> 
> — Pyry
> 
> PS. Besides, neither the original example nor mine was really fair; you don't 
> need `where` for these. Instead, you'd just write:
> 
> func someMethod(value: S) -> 
> AnySequence {
> ...
> }
> 
> which SE-0081 has nothing to argue for or against.
> 
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

I think an important point is that `all<>` should NOT be restricted to having 
only one reference or value type!

Ceylon does not have any restrictions like that. You can form the type 
intersection of String and Integer for example, which are both classes in 
Ceylon and because Ceylon like Swift only knows single inheritance between 
classes, the result is simply `Nothing` (the bottom type which has no 
elements). So there is no need to forbid this explicitly, because the types 
work out just fine.

Furthermore you can form type intersections between reference types which 
inherit from each other. The resulting intersection type is valid and is just 
equal to the more specific type. And of course you can form type intersections 
of a reference or value type with itself (i.e. all).

Why should that be useful you may ask?

This generality is important when using intersection types with generics: let’s 
consider the type of a function forming the intersection of two sets with 
different element types:

func union(a: Set, b: Set) -> Set> { … }


Requiring all to have at most one reference or value type (which must be 
at first position) would impose some unnecessary restrictions:

Given the following:

protocol Named {}
class Person : Named {}
class Employee : Person {}

let people: Set
let otherPeople: Set
let employees: Set
let namedOnes: Set

// unnecessary restriction:
let x1 = union(namedOnes, people)  // not allowed, because result type contains 
all 

// the restriction would require us to write:
let x2 = union(people, namedOnes)  // ok, result type would be Set> which would be simplified by the compiler to Set (Ceylon does 
this!)

// unnecessary restriction:
let x3 = union(people, employees)   // not allowed, because result type would 
contain all with two reference types

// unnecessary restriction
let x4 = union(people, otherPeople)   // not allowed, because result type 
contains all with two reference types

IMO these should all be allowed (and are possible in Ceylon). 
The result type of x1 would be Set> which would be 
simplified by the compiler to Set.
The result type of x2 would be Set> which would be 
simplified by the compiler to Set.
The result type of x3 would be Set> which would be 
simplified by the compiler to Set.
The result type of x4 would be Set> which would be 
simplified by the compiler to Set.

-Thorsten



> Am 14.05.2016 um 01:50 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> If anyone is interested, I started a draft proposal with detailed design 
> here: 
> https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-merging-types-with-protocols.md
>  
> 
> 
> I didn’t post it here, because it is a bit huge and could lose its markdown 
> formats. `all<>` is always bold, because this is what we are interested in, 
> but I provided all possible combinations if the other formats would exists 
> (at least all combinations I could think of, anything else is derived from 
> these). 
> 
> `class<>` etc. can be seen as a future direction (I would say), otherwise 
> this would easily become out of scope for Swift 3. (I will  move `class<>` 
> etc. from detailed design to future direction later.)
> 
> I’d love to hear your feedback and strong arguments for the motivation part I 
> could include into this proposal.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 23:16:20, Vladimir.S (sva...@gmail.com 
> ) schrieb:
> 
>> You asked for any example, I give it to you ;-) 
>> (as I said, it is syntactical, just to show that such struct<> can be used  
>> to test some struct for conforming to protocol, that was not conformed at  
>> writing time) 
>> Probably we can invent useful examples for this struct<> - but I don't  
>> believe it will be introduced in Swift ;-) 
>> 
>> On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote: 
>> > Can we really do that? I mean, I thought about that myself but I came to 
>> > the conclusion that this scenario is like: I was to lazy to couple this 
>> > structs to my library protocols, will you do that for me? 
> ___
> 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] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

> On May 14, 2016, at 9:43 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Tony & Haravikk,
> 
> (Reformatting your quoted examples just a bit…)
> 
>>> It enables things like:
>>> func someMethod(value: S) -> AnySequence
>>> where S.Generator.Element == T { ... }
>> 
>> I'm not assuming that. Under the current syntax, I would format your example 
>> as:
>> 
>> func someMethod<
>> S : SequenceType, T
>> where S.Generator.Element == T
>> >(value: S) -> AnySequence {
>> ...
>> }
> 
> You are both right here, but please note that the proposal still also allows 
> moving all constraints to the `where` clause:
> 
> func someMethod(value: S) -> AnySequence
> where S : SequenceType,
>   S.Generator.Element == T
> {
> ...
> }
> 
> just like Swift 2 allows doing so within the `<...>` brackets:
> 
> func someMethod where S : SequenceType, S.Generator.Element == T
> >(value: S) -> AnySequence {
> ...
> }
> 
> The reason I'd recommend that style for anything but simple constraints is 
> because:
> 
> 1) It makes the call site `let items = someMethod(value: things)` lightest to 
> visually match to the declaration, because the only thing between the 
> function name and its argument list is the `<...>` bracketed list of 
> introduced generic types which you'll expect to see in the function signature 
> and constraints.
> 
> 2) In general, the `where` constraints really apply to the whole 
> function/type declaration, not just a single generic parameter.
> 
> 3) It was claimed that all constraints should go right next to the 
> introduction of the generic parameters. But that isn't the whole case because 
> Swift also applies implicit constraints onto any generic parameters that are 
> used in constrained positions. If that wasn't clearly said, take the 
> following example in Swift 2.x:
> 
> func aMethod(value: 
> S) -> Set {
> return Set(value)
> }
> 
> That declaration actually makes you wait all the way until the return type 
> `Set` until you learn that `T` must also necessarily be `Hashable`. So I 
> don't see how it's that different if the `where` clause isn't right next to 
> the generic type arguments' introduction:
> 
> func aMethod(value: S) -> Set // FWIW, this line contains what I 
> usually have in mind when browsing code.
> where // T : Hashable, // (implicit)
>   S : SequenceType,
>   S.Generator.Element == T
> {
> return Set(value)
> }
> 
> — Pyry
> 

IMHO proposals like this should never be discussed in the context of trivial 
examples as the full scope of their value gets lost. I have written enough 
generics code in other languages to appreciate the idea of a 
'headline-form-followed-by-the-details-idea' for any complex declaration. My 
understanding is that the proposal offers to make us write explicitely what 
anyone reading the code will try to extract out of the declaration. Instead of 
100's or 1000's doing the work in their heads, the code author does it once for 
all subsequent readers. What's not to like about this idea?

> PS. Besides, neither the original example nor mine was really fair; you don't 
> need `where` for these. Instead, you'd just write:
> 
> func someMethod(value: S) -> 
> AnySequence {
> ...
> }
> 
> which SE-0081 has nothing to argue for or against.
> 
> ___
> 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] Typealiases in protocols and protocol extensions

[David Hart via swift-evolution]

Hi everybody,

I added details suggested by Xiaodi and opened a pull request. Any last minute 
modifications before it gets merged in?

https://github.com/hartbit/swift-evolution/blob/a1b883132588bd0ceff5e5c9787bcef140f6674a/proposals/-typealiases-in-protocols.md

Typealiases in protocols and protocol extensions

Proposal: SE- 

Authors: David Hart , Doug Gregor 

Status: TBD
Review manager: TBD
 
Introduction

This proposal is from the Generics Manifesto 
 and 
brings the typealias keyword back into protocols for type aliasing.

 
Motivation

In Swift versions prior to 2.2, the typealias keyword was used outside of 
protocols to declare type aliases and in protocols to declare associated types. 
Since SE-0011 

 and Swift 2.2, associated type now use the associatedtypekeyword and typealias 
is available for implementing true associated type aliases. 

 
Proposed
 solution

The solution allows the creation of associated type aliases. Here is an example 
from the standard library:

protocol Sequence {
  associatedtype Iterator : IteratorProtocol
  typealias Element = Iterator.Element
}
The example above shows how this simplifies referencing indirect associated 
types:

func sum(sequence: T) -> Int {
return sequence.reduce(0, combine: +)
}
Allowing typealias in protocol extensions also allows extensions to use aliases 
to simplify code that the protocol did not originally propose:

extension Sequence {
typealias Element = Iterator.Element

func concat(other: Self) -> [Element] {
return Array(self) + Array(other)
}
}
 
Detailed
 design

The following grammar rules needs to be added:

protocol-member-declaration → protocol-typealias-declaration

protocol-typealias-declaration → typealias-declaration

 
Impact
 on existing code

This will initially have no impact on existing code, but will probably require 
improving the Fix-It that was created for migrating typealias to associatedtype 
in Swift 2.2.

But once typealias starts being used inside protocols, especially in the 
Standard Library, name clashes might start cropping up between the type aliases 
and associated types. For example:

protocol Sequence {
typealias Element = Iterator.Element // once this is added
}

protocol MySequence: Sequence {
associatedtype Element // MySequence.Element is ambiguous
}
But there is no reason that those name clashes behave differently than current 
clashes between associated types:

protocol Foo {
associatedtype Inner: IntegerType
func foo(inner: Inner)
}

protocol Bar {
associatedtype Inner: FloatingPointType
var inner: Inner { get }
}

struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform to 
protocol ‘Bar'
func foo(inner: Int) {}
var inner: Float
}


> On 09 May 2016, at 22:18, Xiaodi Wu  wrote:
> 
> Sorry--I'm not at all saying that I think there's a problem. As you asked, I 
> attempted to supply a contrived use case for a typealias declared in a 
> protocol having a more restricted scope than the protocol itself. I was 
> asking if it would be supported as part of your proposal.
> 
> 
> On Mon, May 9, 2016 at 3:11 PM, David Hart  > wrote:
> I don’t see a problem with your example. Because the typealias is 
> fileprivate, it doesn’t exist as far as MyUsefulType is concerned. The same 
> way the following works:
> 
> ```
> class Base {
> private typealias Foo = Int
> func foo() -> Int {
> return Foo()
> }
> }
> ```
> 
> Other file:
> 
> ```
> class Derived: Base {
> typealias Foo = String
> func bar() -> String {
> return "Hello \(foo())"
> }
> }
> ```
> 
>> On 09 May 2016, at 10:37, Xiaodi Wu > > wrote:
>> 
>> On Mon, May 9, 2016 at 2:31 AM, David Hart > 

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Kevin Ballard via swift-evolution]

AnySequence is specifically used to erase the type of an underlying
sequence, and I'm guessing that using it here will make it harder to
optimize loops that use this.
 
-Kevin Ballard
 
On Fri, May 13, 2016, at 10:20 PM, Patrick Smith wrote:
> Would there be any issue with the return type being AnySequence? It’s
> used in other areas:
>
> LazySequence & FlattenSequence’s
> dropFirst(n: Int) -> AnySequence
> dropLast(n: Int) -> AnySequence
>
> No need to introduce another type, and it’s straight forward to
> implement with AnySequence.
>
>
>> On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
>>> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution
>>>  wrote:

> The proposal has been updated as per feedback from the core team
> (https://github.com/apple/swift-evolution/pull/275). This includes
> removing some last vestiges of Swift 2 naming as well as replacing
> `iterate(_:apply:)` with an overloaded function
> `unfold(_:applying:)`.

 The proposal says this:

 public func unfold(_ initialState: State, applying: State
 -> (T, State)?) -> UnfoldSequence
 public func unfold(_ initialElement: T, apply: T -> T) ->
 UnfoldSequence

 However, the comment implies that the second one should instead be
 this:

 public func unfold(_ initialElement: T, applying: T -> T?) ->
 UnfoldSequence

 I'm not sure I like having these be overloaded on only the return
 type of the closure. Maybe we could do something like this?

 public func unfold(fromState initialState: State,
 applying: State -> (T, State)?) -> UnfoldSequence
 public func unfold(fromFirst initialElement: T, apply: T -> T)
 -> UnfoldSequence

 That way you're calling either `unfold(fromState:applying:)` or
 `unfold(fromFirst:applying:)`. (Some further bikeshedding might be
 needed here—it's late and I'm tired.)
>>>
>>> I really don't want to see this discussion die as I have a vested
>>> interest in getting this functionality into
>>> Swift 3. So let me suggest that
>>>
>>> `sequence(_:, next:) -> AdHocSequence`
>>>
>>> might be a Swift acceptable solution.  We're not going to see
>>> fold/unfold pair happen. It's a given that
>>> `reduce` is a fixed point in Swift space and `sequence` well
>>> describes what this should be doing.
>>>
>>> So is it possible to push forward with `sequence`, whose only
>>> negative seems to be that it's not as well
>>> loved as `unfold`?
>>
>> I do like `sequence`, though I'm not sold on the name AdHocSequence
>> (just from that name it's hard to figure out what it does). An
>> alternative is `expand`, which is nice because it pairs with
>> `reduce`, but it's less obvious that it produces a sequence and the
>> name isn't as good with the stateful version.
>>
>> As for return type name, we could go ahead and use UnfoldSequence
>> anyway even though the function isn't named `unfold`, because this
>> name will make sense to people who do know what unfold is, and I'm
>> not convinced we can have a meaningful name for people who don't
>> (since SequenceSequence is too silly).
>>
>> So given that, I'll suggest the following:
>>
>> func sequence(initial: T, next: T -> T?) -> UnfoldSequence
>> func sequence(state: State, next: (inout State) -> T?) ->
>> UnfoldSequence
>>
>> I'm suggesting `sequence(initial:next:)` instead of the previously-
>> suggested `sequence(from:applying:)` because the term "from" could
>> equally well mean the first element or the state, whereas "initial"
>> should make it more obvious that this value is the first element of
>> the resulting sequence. And I'm using "next" as suggested by Erica
>> because the function does return the next element, and it's similar
>> to the IteratorProtocol method. I've also chosen to change the
>> stateful version to use an inout parameter, as previously suggested,
>> because it's equivalent to the State -> (T, State)? in functionality
>> but is less likely to produce unwanted COW copies.
>>
>> -Kevin Ballard
>> ___
>> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

> Am 14.05.2016 um 20:08 schrieb Thorsten Seitz via swift-evolution 
> :
> 
>> protocols conformance of `type<>` is tested with the actual type `type<>` 
>> not with the first element of `type<>` (hard to describe this one, does this 
>> makes sense to you?)
> 
> The components of type<> are unrelated and do not have to conform to each 
> other. They are just a union type. Did you mean that?

Ooops, I meant of course, the complete expression forms an *intersection* type 
(not a union type). 

To recap:

In Ceylon A & B is an intersection type which means a type that conforms to A 
*and* B. This could be written as all in Swift.
In Ceylon A | B is a union type which means a type that conforms to A *or* B 
(maybe to both but at least to one of them). This could be written as any 
in Swift.

-Thorsten


> 
> -Thorsten
> 
>> Does this proposal need more than the base `type<>`?
>> 
>> Maybe, but I think we should start with `type<>` before we will introduce a 
>> type operator for this.
>> 
>> Did I missed anything out here? 
>> 
>> PS: Feel free to help me with my English, because it’s not so well.
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com 
>> ) schrieb:
>> 
>>> I think there would be a certain elegance to allowing Boolean type 
>>> expressions wherever types are currently allowed, so `A & B` being a 
>>> replacement for `protocol` might look nice, and then extend that to 
>>> allow concrete types as well. Then, if Swift ever decided to support union 
>>> types, the `|` operator naturally fits there.
>>> 
>>> One concern though would be whether parsing would get more complicated with 
>>> deeply composed expressions. If we only supported `&`, there's no real 
>>> nesting going on. But if we wanted to be forward thinking and leave the 
>>> door open for `|`, we might need to support things like `(String | Int) & 
>>> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
>>> would really complicate things (e.g., could the compiler decide easily 
>>> enough that those parentheses are part of a type expression and not a 
>>> function type?).
>>> 
>>> `all` would be a nice compromise in that case, and leave the door 
>>> open for `any` in the future. So I'd be supportive of either option.
>>> 
>>> 
>>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>>> > wrote:
>>> We've been over this a few times before on the list. I personally like 
>>> naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and 
>>> "AnySequence". I also see Thorsten (and in the past Brent's?) argument for 
>>> calling it "all" or "All", because it's enforcing multiple constraints.
>>> 
>>> I will say that "type" is unlikely to see much traction simply because it 
>>> is an incredibly common name for both properties and locals. We went 
>>> through that exercise when trying to name both "static" and "dynamicType" 
>>> and decided that it would be too confusing, even if we could make the 
>>> parsing work.
>>> 
>>> The feature itself has definitely been shown to be useful when working with 
>>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>>> have it internally tracked in Radar as rdar://problem/15873071 <>.
>>> 
>>> Jordan
>>> 
>>> 
 On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
 > wrote:
 
 I don’t get the part how `all<>` should allow `any<>`. Could you explain 
 that a little bit in detail (I’m not familiar with Ceylon)?
 
 From my point of view `any<>` is something different that I pitched here. 
 `any<>` could be proposed in its own thread, because it is way different 
 than `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
 
 Here is a little example where `any<>` gets strange:
 
 func foo(value: any) -> any {
 
 // how would one use value here?
 // what about its properties
 // what will foo return and how to use the result
 }
 
 One benefit of `any<>` is the replacement of overloading, at least for the 
 type part of the function.
 
 I’d like to propose `type<>` as the base extension to the language in that 
 direction, before we’ll move forward with more complex scenarios (just 
 like Chris did with generic typealias).
 
 This function is clear that it only will work if you provide a subclass of 
 an UIView which conforms to SomeProtocol (nice addition for library 
 design).
 
 func foo(value: type) -> type {
 
 // use it as a UIView and SomeProtocol at the same type
 return value // return type works great
 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Pyry Jahkola via swift-evolution]

Tony & Haravikk,

(Reformatting your quoted examples just a bit…)

>> It enables things like:
>> func someMethod(value: S) -> AnySequence
>> where S.Generator.Element == T { ... }
> 
> I'm not assuming that. Under the current syntax, I would format your example 
> as:
> 
> func someMethod<
> S : SequenceType, T
> where S.Generator.Element == T
> >(value: S) -> AnySequence {
> ...
> }

You are both right here, but please note that the proposal still also allows 
moving all constraints to the `where` clause:

func someMethod(value: S) -> AnySequence
where S : SequenceType,
  S.Generator.Element == T
{
...
}

just like Swift 2 allows doing so within the `<...>` brackets:

func someMethod(value: S) -> AnySequence {
...
}

The reason I'd recommend that style for anything but simple constraints is 
because:

1) It makes the call site `let items = someMethod(value: things)` lightest to 
visually match to the declaration, because the only thing between the function 
name and its argument list is the `<...>` bracketed list of introduced generic 
types which you'll expect to see in the function signature and constraints.

2) In general, the `where` constraints really apply to the whole function/type 
declaration, not just a single generic parameter.

3) It was claimed that all constraints should go right next to the introduction 
of the generic parameters. But that isn't the whole case because Swift also 
applies implicit constraints onto any generic parameters that are used in 
constrained positions. If that wasn't clearly said, take the following example 
in Swift 2.x:

func aMethod(value: S) 
-> Set {
return Set(value)
}

That declaration actually makes you wait all the way until the return type 
`Set` until you learn that `T` must also necessarily be `Hashable`. So I 
don't see how it's that different if the `where` clause isn't right next to the 
generic type arguments' introduction:

func aMethod(value: S) -> Set // FWIW, this line contains what I 
usually have in mind when browsing code.
where // T : Hashable, // (implicit)
  S : SequenceType,
  S.Generator.Element == T
{
return Set(value)
}

— Pyry

PS. Besides, neither the original example nor mine was really fair; you don't 
need `where` for these. Instead, you'd just write:

func someMethod(value: S) -> 
AnySequence {
...
}

which SE-0081 has nothing to argue for or against.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Kenny Leung via swift-evolution]

I am against this proposal.

- I think it makes the code look ugly and incomplete when there is a trailing 
comma
- I much prefer the counter-proposal which would allow newline to be the 
separator for items in a list.
- in general, it’s much better when you can remove something from your code 
rather than add something to it
- this proposal serves the same purpose as allowing the trailing comma

-Kenny


> On May 10, 2016, at 11:53 AM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
> begins now and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

Thank you for pointing me to the right reading.

I just read both pages:
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
https://github.com/apple/swift/blob/master/docs/Generics.rst

I’ll have to rewrite my proposal a bit. Btw. is there any better name for 
Ceylon `Any<>`? Maybe `Either<>`?

`Any` - "Any type that conforms to T and U“ 

Could someone explain to me what existentials suppose to be? I didn’t get that 
part from the article, where everything else made somehow sense to me. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 14. Mai 2016 bei 20:21:04, Austin Zheng via swift-evolution 
(swift-evolution@swift.org) schrieb:

Yes, this is theoretically possible, but why is it useful? (I am genuinely 
curious.) 

If the intention is to allow B to be a user-defined extension point for T, this 
goes back to the core team's arguments (in the thread about optional protocol 
requirements) about why having checking for conformance to some requirement at 
the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the core 
team has already ruled out a number of features (user-defined variance on 
generics, generic protocols) because they don't believe in their general 
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S  wrote:
FWIW, yes, protocols available for struct are known at compile-time, but could 
be unknown at the *moment of writing* the code.

What I mean:

Step 1. I write source code:

protocol A {}
protocol B {}
struct S:A {}

func f(a: A) {
  if a is struct {...} // I expect that S could be conformed to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}




On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.


___
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] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

That makes sense, thanks for pointing out a possibility I missed!

Austin

On Sat, May 14, 2016 at 11:34 AM, Vladimir.S  wrote:

> On 14.05.2016 21:20, Austin Zheng wrote:
>
>> Yes, this is theoretically possible, but why is it useful? (I am genuinely
>> curious.)
>>
>
> I just showing that we *can* invent the situation when checking for
> struct have a sense. Not more, not less.
> I'm not going to discuss if that can have any (or never can have at all)
> useful intention.
>
>
>> If the intention is to allow B to be a user-defined extension point for T,
>> this goes back to the core team's arguments (in the thread about optional
>> protocol requirements) about why having checking for conformance to some
>> requirement at the use site is a suboptimal idea.
>>
>> If the intention is to make the type system as expressive as possible, the
>> core team has already ruled out a number of features (user-defined
>> variance
>> on generics, generic protocols) because they don't believe in their
>> general
>> applicability.
>>
>> Austin
>>
>> On Sat, May 14, 2016 at 11:13 AM, Vladimir.S > > wrote:
>>
>> FWIW, yes, protocols available for struct are known at compile-time,
>> but could be unknown at the *moment of writing* the code.
>>
>> What I mean:
>>
>> Step 1. I write source code:
>>
>> protocol A {}
>> protocol B {}
>> struct S:A {}
>>
>> func f(a: A) {
>>   if a is struct {...} // I expect that S could be conformed to B
>> }
>>
>> Step 2. I give my code to someone, who can do somewhere in his
>> project:
>>
>> extension S:B{..}
>>
>>
>>
>>
>> On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
>>
>> 1. struct. In this case
>> the
>> struct<...> representation is unnecessary; the protocols that are
>> available
>> to the user are known at compile-time, and structs can't have
>> subtypes that
>> conform to additional protocols like classes can. There is an
>> example
>> marked "func boo(value: struct) /* equivalent to */
>> func
>> boo(value: SomeStruct)"; my question is why having more than two
>> ways to
>> express the same idea makes the language better, easier to use,
>> etc.
>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S via swift-evolution]

On 14.05.2016 21:20, Austin Zheng wrote:

Yes, this is theoretically possible, but why is it useful? (I am genuinely
curious.)


I just showing that we *can* invent the situation when checking for 
struct have a sense. Not more, not less.
I'm not going to discuss if that can have any (or never can have at all) 
useful intention.




If the intention is to allow B to be a user-defined extension point for T,
this goes back to the core team's arguments (in the thread about optional
protocol requirements) about why having checking for conformance to some
requirement at the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the
core team has already ruled out a number of features (user-defined variance
on generics, generic protocols) because they don't believe in their general
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S > wrote:

FWIW, yes, protocols available for struct are known at compile-time,
but could be unknown at the *moment of writing* the code.

What I mean:

Step 1. I write source code:

protocol A {}
protocol B {}
struct S:A {}

func f(a: A) {
  if a is struct {...} // I expect that S could be conformed to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}




On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:

1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are
available
to the user are known at compile-time, and structs can't have
subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two
ways to
express the same idea makes the language better, easier to use, etc.



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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

On 14.05.2016 20:53, Tino Heth via swift-evolution wrote:

The idea of using newlines as separators (making "," obsolete, like ";" in
other situations) imho is much nicer and would address the same issues that
this proposal tries to improve.


Tino, would you like to form an 'official' proposal for this(newlines as 
separators) feature? As I can see, there is a much support in community for 
this idea, but no one said yet he/she will create a proposal for this.(or I 
just missed this)


It seems like we'll need separate proposal for this, as 'traliling commas' 
proposal already in review and probably(I don't know) will be accepted(I 
saw support in comments from @apple.com)

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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

Union types are to enums as tuples are to structs. There's room for both in
the language. Sometimes it makes sense to have a more formalized construct
that has specific semantics (like an error type) and methods that operate
upon that type. Sometimes, you just want an int OR a string.

On Sat, May 14, 2016 at 10:58 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > func f(obj: A) {..}
> > if obj is A {...}
> > obj2 = obj as! A
> >
> > (but I still don't understand real use case of things like (String |
> Int))
> Ceylon has already been mentioned: It uses the concept for its optionals.
> Swift uses enums, and those could be made obsolete by union types.
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Austin Zheng via swift-evolution]

Yes, this is theoretically possible, but why is it useful? (I am genuinely
curious.)

If the intention is to allow B to be a user-defined extension point for T,
this goes back to the core team's arguments (in the thread about optional
protocol requirements) about why having checking for conformance to some
requirement at the use site is a suboptimal idea.

If the intention is to make the type system as expressive as possible, the
core team has already ruled out a number of features (user-defined variance
on generics, generic protocols) because they don't believe in their general
applicability.

Austin

On Sat, May 14, 2016 at 11:13 AM, Vladimir.S  wrote:

> FWIW, yes, protocols available for struct are known at compile-time, but
> could be unknown at the *moment of writing* the code.
>
> What I mean:
>
> Step 1. I write source code:
>
> protocol A {}
> protocol B {}
> struct S:A {}
>
> func f(a: A) {
>   if a is struct {...} // I expect that S could be conformed to B
> }
>
> Step 2. I give my code to someone, who can do somewhere in his project:
>
> extension S:B{..}
>
>
>
>
> On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
>
>> 1. struct. In this case the
>> struct<...> representation is unnecessary; the protocols that are
>> available
>> to the user are known at compile-time, and structs can't have subtypes
>> that
>> conform to additional protocols like classes can. There is an example
>> marked "func boo(value: struct) /* equivalent to */ func
>> boo(value: SomeStruct)"; my question is why having more than two ways to
>> express the same idea makes the language better, easier to use, etc.
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Tony Allevato via swift-evolution]

On 2016-05-14 16:29:40 +, Haravikk via swift-evolution said:



On 14 May 2016, at 16:52, Tony Allevato via swift-evolution 
 wrote:


To me, this makes declarations with complex sets of constraints much 
harder to read, because I have to hunt them down instead of finding 
them all in one place. Under this proposal, the longer an argument list 
gets, the further separated the constraints are from the type 
parameters that use them.


This is partly an issue of how you use the feature rather than an issue 
with the feature itself, as you’re assuming that everything is all on 
one line, but really I think the intent of this feature is to better 
support multi-line declarations. It enables things like:


func someMethod(value:S) -> AnySequence
where S.Generator.Element == T { … }


I'm not assuming that. Under the current syntax, I would format your 
example as:


   func someMethod<
   S: SequenceType, T
   where S.Generator.Element == T
   >(value: S) -> AnySequence {
   ...
   }

which I find to be quite readable across multiple lines without 
scattering the generic type information in two places across the 
function.



The actual function signature stays on the top, but the constraint can 
now move down neatly, since it’s a supplementary condition that you may 
not to consider right away, or at all, if it’s just reinforcing some 
kind of common-sense limitation.


That's kind of a judgment call, though. Not all constraints fit that 
mold—some encode very important information that it makes sense to keep 
up front.



This is partly why I’d prefer to see it optional though, as some things 
will fit on one line reasonably well (you probably could with the above 
for example), but like you say, with it all on one line the return type 
becomes less visible.


No matter how you format the proposed syntax, the return type is 
sandwiched in the middle of two things that describe generic type 
information—whether it's on one line or not doesn't change that. I 
believe that harms readability, especially if you have some constraints 
(conformance) on the left and some (associated types) on the right.


I would be strongly opposed to making this optional—that adds 
complexity to the language to support parsing two patterns, as well as 
the cognitive load of someone reading Swift code, especially if written 
in the different style. As was mentioned in another thread, "Swift is 
an opinionated languge", and I hope we'd be prescriptive about 
syntactic constructs like this that are more significant than "does the 
curly brace go on the same line or the next line". (Even if the choice 
is one that I disagree with in the end, I'd rather there be one way 
than multiple ways!)




___
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] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S via swift-evolution]

FWIW, yes, protocols available for struct are known at compile-time, but 
could be unknown at the *moment of writing* the code.


What I mean:

Step 1. I write source code:

protocol A {}
protocol B {}
struct S:A {}

func f(a: A) {
  if a is struct {...} // I expect that S could be conformed to B
}

Step 2. I give my code to someone, who can do somewhere in his project:

extension S:B{..}



On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:

1. struct. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.


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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

> Am 13.05.2016 um 17:25 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> Lets sum things up before I try to write a draft proposal for this feature 
> `type<>` aka `all<>`.
> 
> Is this feature out of scope for Swift 3?
> 
> From my point of view it’s definitely not. 
> 
> Is the name `type<>` really that bad for the compiler?
> 
> Here I’m not sure, because that is out of my experience. From a readers 
> perspective it’s more clear than `all<>`, I would say, even though this is a 
> perfect explanation why it should be called `all<>`:
> 
>> I also see Thorsten (and in the past Brent's?) argument for calling it "all" 
>> or "All", because it's enforcing multiple constraints.
> 
> Do we miss any rules here?
> 
> `type<>` can contain only one value-type or reference-type and n protocols
> the value-type or reference-type should always be the first element between 
> angle brackets
> `type<>` should always contain at least 2 types (one value-type or a 
> reference-type and at least one protocol)
I think type<> (or all<>) should replace protocol<>, otherwise the idea of 
having all<> and any<> loses its charm.
Is there a reason why type<> should exist in parallel to protocol<>?
> reference-types do represent a possible super/base type/class
> nesting `type<>` is not allowed, however `type<>` can contain `protocol<>`
> protocols conformance of `type<>` is tested with the actual type `type<>` not 
> with the first element of `type<>` (hard to describe this one, does this 
> makes sense to you?)
The components of type<> are unrelated and do not have to conform to each 
other. They are just a union type. Did you mean that?

-Thorsten

> Does this proposal need more than the base `type<>`?
> 
> Maybe, but I think we should start with `type<>` before we will introduce a 
> type operator for this.
> 
> Did I missed anything out here? 
> 
> PS: Feel free to help me with my English, because it’s not so well.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com 
> ) schrieb:
> 
>> I think there would be a certain elegance to allowing Boolean type 
>> expressions wherever types are currently allowed, so `A & B` being a 
>> replacement for `protocol` might look nice, and then extend that to 
>> allow concrete types as well. Then, if Swift ever decided to support union 
>> types, the `|` operator naturally fits there.
>> 
>> One concern though would be whether parsing would get more complicated with 
>> deeply composed expressions. If we only supported `&`, there's no real 
>> nesting going on. But if we wanted to be forward thinking and leave the door 
>> open for `|`, we might need to support things like `(String | Int) & 
>> SomeProtocol`, and I'm not enough of a parser expert to know whether that 
>> would really complicate things (e.g., could the compiler decide easily 
>> enough that those parentheses are part of a type expression and not a 
>> function type?).
>> 
>> `all` would be a nice compromise in that case, and leave the door open 
>> for `any` in the future. So I'd be supportive of either option.
>> 
>> 
>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution 
>> > wrote:
>> We've been over this a few times before on the list. I personally like 
>> naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and 
>> "AnySequence". I also see Thorsten (and in the past Brent's?) argument for 
>> calling it "all" or "All", because it's enforcing multiple constraints.
>> 
>> I will say that "type" is unlikely to see much traction simply because it is 
>> an incredibly common name for both properties and locals. We went through 
>> that exercise when trying to name both "static" and "dynamicType" and 
>> decided that it would be too confusing, even if we could make the parsing 
>> work.
>> 
>> The feature itself has definitely been shown to be useful when working with 
>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we 
>> have it internally tracked in Radar as rdar://problem/15873071 <>.
>> 
>> Jordan
>> 
>> 
>>> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> I don’t get the part how `all<>` should allow `any<>`. Could you explain 
>>> that a little bit in detail (I’m not familiar with Ceylon)?
>>> 
>>> From my point of view `any<>` is something different that I pitched here. 
>>> `any<>` could be proposed in its own thread, because it is way different 
>>> than `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
>>> 
>>> Here is a little example where `any<>` gets strange:
>>> 
>>> func foo(value: any) -> any {
>>> 
>>> // how would one use value here?
>>> // what about its properties
>>> // what will foo return 

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Tino Heth via swift-evolution]

> func f(obj: A) {..}
> if obj is A {...}
> obj2 = obj as! A
> 
> (but I still don't understand real use case of things like (String | Int))
Ceylon has already been mentioned: It uses the concept for its optionals.
Swift uses enums, and those could be made obsolete by union types.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Tino Heth via swift-evolution]

>> Would you then recommend removing trailing comma support for collections on 
>> the same principle?
me too — so, for the review-part: -0.5, no trailing commas (it's not a full -1 
as long as I'm not forced to add those trailing commas)
I don't think they are convenient, and even if that is wrong: The 
convenience-argument could be used to cripple the language (skipping closing 
parens could be convenient, using "l" and "v" instead of "let" & "var" could be 
convenient, inferring the return-type of methods could be convenient... and 
possibly hundreds of small changes in the syntax as well).
The idea of using newlines as separators (making "," obsolete, like ";" in 
other situations) imho is much nicer and would address the same issues that 
this proposal tries to improve.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Erica Sadun via swift-evolution]

> On May 14, 2016, at 8:45 AM, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> I appreciate your rework on this - I still don’t understand one thing and 
> disagree with a second:
> 
> (1) I don’t understand what the word “Custom” adds to 
> CustomStringRepresentable and CustomDebugStringRepresentable and would drop 
> that prefix (even if it remains Convertible).

We did not introduce "Custom". That is sourced from the Swift core team. 
Reevaluating that name would have to fall under the umbrella of a separate 
proposal. Our focus is keyword conventions.

> (2) The use case for these two still stands out from every other protocol on 
> the list. The intent is (was) better captured by “Describable”. i.e. these 
> are things for which there is a description. I think it is more descriptive 
> to name them Describable and DebugDescribable.

It is a representation suitable for printing or debug printing. We included 
them because they are a part of the existing art in the standard library.

-- E

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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Haravikk via swift-evolution]

> On 14 May 2016, at 16:52, Tony Allevato via swift-evolution 
>  wrote:
> 
> To me, this makes declarations with complex sets of constraints much harder 
> to read, because I have to hunt them down instead of finding them all in one 
> place. Under this proposal, the longer an argument list gets, the further 
> separated the constraints are from the type parameters that use them.

This is partly an issue of how you use the feature rather than an issue with 
the feature itself, as you’re assuming that everything is all on one line, but 
really I think the intent of this feature is to better support multi-line 
declarations. It enables things like:

func someMethod(value:S) -> AnySequence
where S.Generator.Element == T { … }

The actual function signature stays on the top, but the constraint can now move 
down neatly, since it’s a supplementary condition that you may not to consider 
right away, or at all, if it’s just reinforcing some kind of common-sense 
limitation.

This is partly why I’d prefer to see it optional though, as some things will 
fit on one line reasonably well (you probably could with the above for 
example), but like you say, with it all on one line the return type becomes 
less visible.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Tony Allevato via swift-evolution]

On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said:


Hello Swift community,

The review of "SE-0081: Move where clause to end of declaration" begins 
now and runs through May 16. The proposal is available here:


 
https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md 



Reviews are an important part of the Swift evolution process. All 
reviews should be sent to the swift-evolution mailing list at


https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the 
review manager.


What goes into a review?

The goal of the review process is to improve the proposal under review 
through constructive criticism and contribute to the direction of 
Swift. When writing your review, here are some questions you might want 
to answer in your review:


* What is your evaluation of the proposal?


-1. My thoughts essentially mirror those of Jon Shier, Karl Wagner, and 
Nicola Salmoria.


To me, this makes declarations with complex sets of constraints much 
harder to read, because I have to hunt them down instead of finding 
them all in one place. Under this proposal, the longer an argument list 
gets, the further separated the constraints are from the type 
parameters that use them.


This solution also obfuscates function definitions. Having the 
function's return type be the very last thing in the header line is has 
very nice readability benefit, and this proposal takes that away by 
sandwiching the return type awkwardly in the middle.


The admission that some constraints should be allowed inside the angle 
brackets (conformance constraints) while moving others (associated type 
constraints) out introduces inconsistency in the language and seems 
like an incomplete fix. From a teaching point of view, I would find it 
more difficult to explain to users of the language "constraints that 
look like *this* go here, but constraints that look like *that* go way 
over there". The current model of "all generic constraints go between < 
and >" is clean and simple.


Lastly, from a bit of a pedantic point of view, moving the where-clause 
to the end of a function declaration makes it look like the function is 
satisfying some constraints, when it's actually the generic type 
parameters that are satisfying them. In that sense, it's better to keep 
them closer together.


	* Is the problem being addressed significant enough to warrant a 
change to Swift?


Yes, but not in this fashion. I agree with some of the other sentiment 
that there should be better ways of satisfying complex constraint sets 
(through generic typealiases or something else) to clean them up, but 
moving the where-clause creates more readability problems than it 
solves.



* Does this proposal fit well with the feel and direction of Swift?


I don't believe so; it adds inconsistency rather than removes it.

	* If you have used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?


No languages that allow generics to be expressed so richly as Swift's.

	* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?


Read the proposal and followed the mailing list threads.



More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

___
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] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Daniel Steinberg via swift-evolution]

I like this much better but would recommend the word “Custom” be dropped from 
StringRepresentable and DebugS
> On May 13, 2016, at 12:31 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> While the community feedback on our SE-0041 proposal "Updating Protocol 
> Naming Conventions for Conversions" 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>  
> )
>  has been positive about the need to establish conventions, feedback has been 
> mixed to negative with regard to the specific conventions suggested in the 
> proposal.
> 
> With that in mind, Erica and I have been working on refactoring those 
> recommendations. We put together the following update and invite the 
> community to bikeshed further with us. We hope this offers the Swift core 
> team the flexibility to accept our proposal "with revision" if an alternative 
> garners more support. With luck, we'll reach a naming consensus during the 
> review period.
> 
> UPDATED APPROACH
> 
> Our updated approach focuses on the two most important conventions: one for 
> initialization and one for representation.
> 
> 1. `Initializable`
> 
> `Initializable` designates protocols that convert *from* a type or from an 
> associated type mentioned in the protocol name, such as the current 
> `LiteralConvertible` protocols.  This convention would include member 
> requirements for initializers, factory methods, and any other way an instance 
> can be imported to establish a new instance of the conforming type.
> 
> For example, conforming to `ArrayLiteralInitializable` would allow a set to 
> be created with `Set(arrayLiteral: )` and `var set: Set = []`.
> 
> This phrase replaces the `Creatable` form from our original proposal.
> 
> 2. `Representable`
> 
> `Representable` designates protocols whose primary purpose is to project *to* 
> a type or associated type mentioned in the protocol name.  Items in the 
> standard library that would be subsumed into this naming include 
> `CustomStringConvertible`, `CustomDebugStringConvertible`, and 
> `RawRepresentable`, which we imagine would become 
> `CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as 
> current) `RawRepresentable`.
> 
> This second category groups together the `Convertible` and `Representable` 
> categories from our original proposal and is predicated on the feedback from 
> the design team review. The `Representable` designation does not promise 
> bidirectional conversion although some `Representable` protocols may include 
> requirements to allow attempted initialization *from* the type of the 
> representation. Doing so falls outside the naming contract we are proposing. 
> 
> FUTURE DIRECTIONS
> 
> We did not include a third category for bidirectional conversion in this 
> update. We recognize that style of contract is rare in Swift. Lossless 
> conversion does not appear in the standard library outside of 
> `RawRepresentable`, which we agreed was better covered by `Representable`. If 
> such a convention is needed or adopted, we reserve the `Isomorphic` 
> designation for future use.
> 
> Sent from my iPad
> 
> On May 10, 2016, at 7:51 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On May 10, 2016, at 11:48 AM, Chris Lattner >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0041: Updating Protocol Naming Conventions for 
>>> Conversions" begins now and runs through May 16. The proposal is available 
>>> here:
>>> 
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>  
>>> 
>> 
>> Here are comments from someone who preferred to stay anonymous.  These are 
>> not my own:
>> 
>> 
>> 
>> 
>> * What is your evaluation of the proposal?
>> 
>> I rather agree with the comments mentioned in the proposal from the Standard 
>> Library design team, in that I agree with the basic intention of the 
>> proposal, but I’m not convinced about the proposed answer. Specifically:
>> 
>> 1) I agree with the proposal that Representable seems more suited to meaning 
>> “a representation can be created from this type”. This is in line with 
>> existing Cocoa APIs that use “dictionaryRepresentation” to generate a 
>> dictionary that represents the object (for e.g. serialization to JSON). See, 
>> for example, NSUbiquitousKeyValueStore, NSUserDefaults, and SCNTechnique. 
>> Out of those, only the last one can also be initialized from a dictionary, 
>> so the term “representation” as used in existing Cocoa frameworks seems 
>> better suited for implying only a one-way conversion (and also feels natural 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Daniel Steinberg via swift-evolution]

I appreciate your rework on this - I still don’t understand one thing and 
disagree with a second:

(1) I don’t understand what the word “Custom” adds to CustomStringRepresentable 
and CustomDebugStringRepresentable and would drop that prefix (even if it 
remains Convertible).

(2) The use case for these two still stands out from every other protocol on 
the list. The intent is (was) better captured by “Describable”. i.e. these are 
things for which there is a description. I think it is more descriptive to name 
them Describable and DebugDescribable.

Best,

Daniel
> On May 13, 2016, at 12:31 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> While the community feedback on our SE-0041 proposal "Updating Protocol 
> Naming Conventions for Conversions" 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>  
> )
>  has been positive about the need to establish conventions, feedback has been 
> mixed to negative with regard to the specific conventions suggested in the 
> proposal.
> 
> With that in mind, Erica and I have been working on refactoring those 
> recommendations. We put together the following update and invite the 
> community to bikeshed further with us. We hope this offers the Swift core 
> team the flexibility to accept our proposal "with revision" if an alternative 
> garners more support. With luck, we'll reach a naming consensus during the 
> review period.
> 
> UPDATED APPROACH
> 
> Our updated approach focuses on the two most important conventions: one for 
> initialization and one for representation.
> 
> 1. `Initializable`
> 
> `Initializable` designates protocols that convert *from* a type or from an 
> associated type mentioned in the protocol name, such as the current 
> `LiteralConvertible` protocols.  This convention would include member 
> requirements for initializers, factory methods, and any other way an instance 
> can be imported to establish a new instance of the conforming type.
> 
> For example, conforming to `ArrayLiteralInitializable` would allow a set to 
> be created with `Set(arrayLiteral: )` and `var set: Set = []`.
> 
> This phrase replaces the `Creatable` form from our original proposal.
> 
> 2. `Representable`
> 
> `Representable` designates protocols whose primary purpose is to project *to* 
> a type or associated type mentioned in the protocol name.  Items in the 
> standard library that would be subsumed into this naming include 
> `CustomStringConvertible`, `CustomDebugStringConvertible`, and 
> `RawRepresentable`, which we imagine would become 
> `CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as 
> current) `RawRepresentable`.
> 
> This second category groups together the `Convertible` and `Representable` 
> categories from our original proposal and is predicated on the feedback from 
> the design team review. The `Representable` designation does not promise 
> bidirectional conversion although some `Representable` protocols may include 
> requirements to allow attempted initialization *from* the type of the 
> representation. Doing so falls outside the naming contract we are proposing. 
> 
> FUTURE DIRECTIONS
> 
> We did not include a third category for bidirectional conversion in this 
> update. We recognize that style of contract is rare in Swift. Lossless 
> conversion does not appear in the standard library outside of 
> `RawRepresentable`, which we agreed was better covered by `Representable`. If 
> such a convention is needed or adopted, we reserve the `Isomorphic` 
> designation for future use.
> 
> Sent from my iPad
> 
> On May 10, 2016, at 7:51 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On May 10, 2016, at 11:48 AM, Chris Lattner >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0041: Updating Protocol Naming Conventions for 
>>> Conversions" begins now and runs through May 16. The proposal is available 
>>> here:
>>> 
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>  
>>> 
>> 
>> Here are comments from someone who preferred to stay anonymous.  These are 
>> not my own:
>> 
>> 
>> 
>> 
>> * What is your evaluation of the proposal?
>> 
>> I rather agree with the comments mentioned in the proposal from the Standard 
>> Library design team, in that I agree with the basic intention of the 
>> proposal, but I’m not convinced about the proposed answer. Specifically:
>> 
>> 1) I agree with the proposal that Representable seems more suited to meaning 
>> “a representation can be created from this type”. This is in line with 
>> 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Nicola Salmoria via swift-evolution]

> * What is your evaluation of the proposal?

-1.

I'm in strong agreement with what Karl Wagner and Jon Shier said.

The current 'where' syntax seems perfectly fine to me. It puts the
constraints in the logical place, next to the type declarations, which is
clear and intuitive.

The proposed change seems akin to declaring a variable:

var x

and then, several lines later, after unrelated code, specifying its type:

where x: Int

I can't see the advantage in doing that.

Yes, the 'where' statements can get long, but that's because they need to
express complex constraints. Moving them to a different place doesn't make
them any shorter, it just makes the problem less apparent by sweeping the
dirt under the carpet.

To make the 'where' statements better, what we need to do is make them
simpler. To do that, we need to reduce the complexity of the constraints
that need to be specified in a declaration.

The most obvious ways to do that are:
* add generic constraints to associatedtype;
* support typealias in protocols;
* add generic constraints to typealias.

Those improvements would allow to break up the complexity, making the
'where' clauses in declarations much shorter and simpler.

protocol Collection {
associatedtype Iterator: IteratorProtocol
typealias Element = Iterator.Element
associatedtype SubSequence: Sequence where SubSequence.Element == Element
}

typealias SortableCollection = protocol where
Collection.Element: Comparable

being able to use the above constructs would go a long way to making the
'where' clauses simpler without needing to change their syntax.

> * Is the problem being addressed significant enough to warrant a change to
Swift?

Yes, but the proposed change seems to do little to actually address the real
problem.

> * Does this proposal fit well with the feel and direction of Swift?

Swift excels at being terse and focused. The proposed change doesn't improve
terseness and reduces focus by putting related information in two different
places. So I don't think it is going in the right direction.

> * If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

I can't think of anything similar to this.

> * How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

A full reading of the proposal, a quick reading of the relevant threads, and
careful thought about the issue and my experience using Swift's type system.

Nicola


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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Matt Whiteside via swift-evolution]

-1.  This has always looked like a typo to me.

-Matt


> On May 10, 2016, at 11:53, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
> begins now and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I’ve done some progress on the draft proposal. There are still a few things to 
fill, but now it should be clear what `all<>` will solve (empty cells in the 
table) and what types it might produce (equivalent refined type). 
`protocol<>` could completely be replaced with `all<>`.

I have rewritten the examples for `all<>` to be more specific and moved 
`class<>` etc. to future directions with some examples what can be done with 
these.

Due the fact that Swift 3 will have generic typealias and possible `any<>`, 
`struct<>` and `enum<>` in the future, we could also build `value<>` which I 
showed at the button of the proposal.

Feel free to give me some feedback. :)

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

[Leonardo Pessoa via swift-evolution]

Operators will overload the function with new arguments. That's why I
suggested this change in syntax only for operators and force them to have
the first argument or the type Self.

- Leonardo

On 14 May 2016 at 03:39, Patrick Pijnappel via swift-evolution <
swift-evolution@swift.org> wrote:

> Hmm good point. Defining a toplevel function or property could reserve
> that name in toplevel scope, but you'd be in trouble when two protocols
> from different modules require a toplevel function or property with the
> same signature.
>
> I'm not sure how operators deal with this because they should have the
> same problem...
>
> On Friday, 13 May 2016, Leonardo Pessoa via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> To me this makes more sense for operators than for other functions or
>> properties. For the former you could create conflict with previously
>> declared function (or properties with variables) and there is no
>> restriction in Swift that says you cannot or should not create a top level
>> function or property.
>>
>> In this sense, having an operator declared inside a class/struct/enum
>> would already make them top level as you proposed, no need for another
>> keyword. I would only add one requirement: that the first argument should
>> always be of type Self (and have it checked by the compiler). It ensures
>> the operator operates on that type and helps minimising conflicts with a
>> previously declared operator.
>>
>> - Leonardo
>>
>> On 13 May 2016 at 04:12, Patrick Pijnappel via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> For some protocols we'd like to require top-level (free) functions, e.g.
>>> for many math functions such as abs() or sin(). We already do this
>>> implicitly for operators.
>>>
>>> *Proposal*
>>> Allow top-level function/property requirements in protocols, e.g.:
>>>
>>> public protocol AbsoluteValuable : SignedNumber { /// Returns the
>>> absolute value of `x`. @warn_unused_result toplevel func abs(_ x: Self)
>>> -> Self }
>>>
>>> We'd probably want to require this for operators. This also opens up
>>> syntax if we ever get dynamically dispatched operators.
>>>
>>>
>>> public protocol SignedNumber : Comparable, IntegerLiteralConvertible { ///
>>> Returns the result of negating `x`. @warn_unused_result toplevel prefix
>>> func - (x: Self) -> Self }
>>>
>>> Currently this is done using the combination of a static method and a
>>> top-level generic function on that protocol. As I understand that approach
>>> does have some benefits in terms of type-checker performance, though I'm
>>> not sure whether that is likely to stay relevant in the future.
>>>
>>> *Advantages*
>>>
>>>- Cleaner than current approach (esp. floating point types have tons
>>>of top-level functions)
>>>- Makes operators less of a special case
>>>- Opens up syntax for member operators
>>>- Could also apply to top-level properties (esp. useful if we get
>>>generic properties, for e.g. π<...>)
>>>
>>>
>>> ___
>>> 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] Consistent bridging for NSErrors at the language boundary

[Charles Srstka via swift-evolution]

> On May 14, 2016, at 3:51 AM, Michael Peternell  
> wrote:
> 
> For interoperability, ErrorType and NSError should be toll-free-bridged, like 
> CFStringRef and NSString. Converting between them should be a no-op at 
> runtime.

That would be technically infeasible without restricting ErrorType to reference 
types using the Objective-C runtime, which I don’t think anyone wants to do.

> I prefer runtime/ABI consistency over syntax/language consistency. 
> MyErrorType2 should be represented as an NSError with domain @"MyErrorType2", 
> whatever code is defined in that error type, and if you want userInfo you 
> have to create the beast as an NSError object in the first place. I think 
> userInfo is not visible in the Swift-enum-representation. If you want to have 
> a Swift Error representation that includes userInfo, you'd have to either 
> change the architecture or introduce special support on the language level 
> (e.g. a magic `er.userInfo` of type `Dictionary` for every 
> `er: ErrorType` and a `er.withUserInfo(userInfo)` to add a userInfo 
> dictionary to an error type: e.g. 
> `MyErrorType2.fooConditionFound.withUserInfo([NSLocalizedDescriptionKey: 
> "that was really bad"])` and maybe even a convenience method as a protocol 
> extension like 
> `MyErrorType.fooConditionFound.withLocalizedDescription(localizedString: 
> "ReallyBad")`.

Adding a userInfo property to the protocol declaration (with a default 
implementation for those that don’t want to implement it) would solve this 
without any low-level hacking.

> And the key of a dictionary should really always be a String, not just an 
> NSObject.)

I actually agree; I used [NSObject : AnyObject] since that’s what NSError’s 
userInfo is currently defined as. Putting [String : AnyObject] in the protocol 
instead would be fine, although you’d have to do a little sanity checking in 
the bridging to filter out non-string keys from the dictionary.

> (I know if you have something like `case SpecialError(Int)` in your ErrorType 
> declaration, the above method does not work; you'd have to create an 
> NSError-subclass for it. Or maybe not? Just add a "SpecialError_arg0" key to 
> userInfo, value can be an NSNumber? There are more edge cases here but they 
> are all solvable.)
> 
> On the other hand, I don't think that enumerations in general should support 
> instance variables. One of the nice things for an enum is that I as a 
> programmer can always be sure that it *is* just an enum, and nothing else. 
> Adding iVars to enums would effectively turning enums to structs, and each 
> time I see a switch statement I'll have to think "is this really all? or is 
> there some stealth value attached to this enum? is every .MadeAMistake object 
> always the same?" Keeping the inconsistency constrained to the ErrorType is 
> much nicer than turning every enum into a struct.

Adding instance variables to enums is not necessary for this. The userInfo here 
can be implemented as a computed property, as it would be in enums (in classes 
and structs, of course, it would be up to the developer whether to make it a 
stored or computed property).

> There will always be rough edges when converting between two languages, 
> that's unavoidable. Try to translate a text that contains a lot of the words 
> "safety" and "security" into German. Good luck, they both translate to the 
> same word. And so there also cannot be a perfectly consistent translation 
> between ErrorType and NSError. If you want to achieve a good translation, 
> you'd have to change the ErrorType to something different. E.g. a special 
> language construct `def-error MyErrorType { case MadeAMistake; case 
> RanOutOfCake }` - matching works the same as now and you have a userInfo 
> property. And on non-objc-platforms, the NSError() name becomes unavailable 
> and .userInfo always returns `[:]`. I'm not saying that this would be a 
> beautiful solution; I'm saying that there is no beautiful solution to this 
> problem.


I think that creating wrappers for both directions could work pretty well if we 
had a userInfo property on ErrorType/Protocol. We’ve got one going in one 
direction already.

Charles

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

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

[Michael Peternell via swift-evolution]

> Am 14.05.2016 um 09:31 schrieb Charles Srstka via swift-evolution 
> :
> 
> I don’t think Cocoa is going away for a very, very long time. Even if it did, 
> you’d still need some consistent way to turn an ErrorType into something 
> human-readable, and currently we don’t have that. NSError’s userInfo field 
> actually does a fairly decent job, aside from the absurdly long constant 
> names.

I think Apple's Chief Deprecating Officer is already getting nervous and that 
point in time may be sooner. IMHO it's one of the big pains of Apple 
development that you have to learn new stuff every year, because oftentimes 
APIs are changed for no convincing reasons. Or one API is removed and a new API 
introduced, with no migration time. It's one of the reasons why I sometimes 
think about leaving the Apple platform as a developer (where I could go to is 
another question..). Having to adapt a program every two years at least just to 
keep it compiling is not programmer friendly. It's a good playground for 
language developers though. With Swift 3 it's a similar problem. At a company I 
work, we decided not to use Swift yet, because of Swift 3. Because with Swift 3 
everything has to be re-done, so we better wait until Swift 3 comes out. And 
even after Swift 3 will be released, we will probably wait until the mid of 
2017, just to be really sure that no breaking changes are planned and no "Swift 
4" is coming. Until that point I'm going to use Swift only for small or 
educational projects (I'm currently writing a game in Swift on iOS). IMHO it 
would be nice to have a language that is *stable* and that keeps stable for at 
least 10 years. But can Swift really ever become fully stable? Or will it be 
replaced with something else as soon as it becomes stable, in the same way it 
is happening to Objective-C now?

For interoperability, ErrorType and NSError should be toll-free-bridged, like 
CFStringRef and NSString. Converting between them should be a no-op at runtime. 
I prefer runtime/ABI consistency over syntax/language consistency. MyErrorType2 
should be represented as an NSError with domain @"MyErrorType2", whatever code 
is defined in that error type, and if you want userInfo you have to create the 
beast as an NSError object in the first place. I think userInfo is not visible 
in the Swift-enum-representation. If you want to have a Swift Error 
representation that includes userInfo, you'd have to either change the 
architecture or introduce special support on the language level (e.g. a magic 
`er.userInfo` of type `Dictionary` for every `er: ErrorType` 
and a `er.withUserInfo(userInfo)` to add a userInfo dictionary to an error 
type: e.g. 
`MyErrorType2.fooConditionFound.withUserInfo([NSLocalizedDescriptionKey: "that 
was really bad"])` and maybe even a convenience method as a protocol extension 
like `MyErrorType.fooConditionFound.withLocalizedDescription(localizedString: 
"ReallyBad")`. And the key of a dictionary should really always be a String, 
not just an NSObject.)

(I know if you have something like `case SpecialError(Int)` in your ErrorType 
declaration, the above method does not work; you'd have to create an 
NSError-subclass for it. Or maybe not? Just add a "SpecialError_arg0" key to 
userInfo, value can be an NSNumber? There are more edge cases here but they are 
all solvable.)

On the other hand, I don't think that enumerations in general should support 
instance variables. One of the nice things for an enum is that I as a 
programmer can always be sure that it *is* just an enum, and nothing else. 
Adding iVars to enums would effectively turning enums to structs, and each time 
I see a switch statement I'll have to think "is this really all? or is there 
some stealth value attached to this enum? is every .MadeAMistake object always 
the same?" Keeping the inconsistency constrained to the ErrorType is much nicer 
than turning every enum into a struct.

There will always be rough edges when converting between two languages, that's 
unavoidable. Try to translate a text that contains a lot of the words "safety" 
and "security" into German. Good luck, they both translate to the same word. 
And so there also cannot be a perfectly consistent translation between 
ErrorType and NSError. If you want to achieve a good translation, you'd have to 
change the ErrorType to something different. E.g. a special language construct 
`def-error MyErrorType { case MadeAMistake; case RanOutOfCake }` - matching 
works the same as now and you have a userInfo property. And on 
non-objc-platforms, the NSError() name becomes unavailable and .userInfo always 
returns `[:]`. I'm not saying that this would be a beautiful solution; I'm 
saying that there is no beautiful solution to this problem.

Regards,
Michael

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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Karl via swift-evolution]

Oops, StringCollection and IntegerSequence are bad examples, because we’d need 
to improve existentials before it could apply to those specific examples.

But that’s desperately needed anyway. I’d still recommend ‘Generalised 
Existentials’ (generics manifesto) + generic typealiases over moving the where 
clause.

> On 14 May 2016, at 10:37, Karl Wagner  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> -1
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> More than a quick reading, but not really “in-depth” study…
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> I don’t really think it does. I don’t remember anything in Swift that went 
> through such a bizarre change just because it looks ugly. 
> 
> I mean, the where clause isn’t a comment; it’s not documentation. It’s 
> absolutely vital to anybody and everybody who uses anything with one. Really, 
> I can’t see any logic to splitting the parameter name and constraints. It’s 
> completely baffling, and if it wasn’t that they’re “ugly” I don’t think 
> anybody would give this proposal a second thought. Besides, when I need to 
> look up which parameters I need for a type, it’s nice to have them all in one 
> place in a clearly delimited section of the declaration.
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> * If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
> 
> I’m with Jon Shier on this - it is a problem, but it’s one inherent to 
> generics. In some languages, you have great big whoppers for type parameters 
> and have to pass them around everywhere you go; we’re relatively clean with 
> Swift. Nobody writing swift should complain about our type parameters being 
> too messy:
> 
> interface Feeder, S extends Store> { 
>  public void buyFoodAndFeed(A animal, S store); 
> } 
> class StoreFeeder implements Feeder, Store> { 
>  public void buyFoodAndFeed(Animal animal, Store store) { 
>animal.eat(store.buyFood()); 
>  } 
> }
> 
> I have a counter-proposal to tackle the readability issue: that we extend 
> SE-0048: Generic Typealiases [1] to include where clauses. The proposal 
> already mentions this, and simply says "If there is a compelling reason to 
> add this, we can consider extending the model to support them in the future, 
> based on the merits of those reasons.” If we did that, we could drastically 
> shorten function/class declarations - using, say, “StringCollection” or 
> “IntegerSequence” rather than .
> 
> [1](https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md)
> 
> 
>> On 10 May 2016, at 20:51, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0081: Move where clause to end of declaration" begins now 
>> and runs through May 16. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> 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] [Review] SE-0081: Move where clause to end of declaration

[Karl Wagner via swift-evolution]

>   * What is your evaluation of the proposal?

-1

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

More than a quick reading, but not really “in-depth” study…

> * Does this proposal fit well with the feel and direction of Swift?

I don’t really think it does. I don’t remember anything in Swift that went 
through such a bizarre change just because it looks ugly. 

I mean, the where clause isn’t a comment; it’s not documentation. It’s 
absolutely vital to anybody and everybody who uses anything with one. Really, I 
can’t see any logic to splitting the parameter name and constraints. It’s 
completely baffling, and if it wasn’t that they’re “ugly” I don’t think anybody 
would give this proposal a second thought. Besides, when I need to look up 
which parameters I need for a type, it’s nice to have them all in one place in 
a clearly delimited section of the declaration.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

I’m with Jon Shier on this - it is a problem, but it’s one inherent to 
generics. In some languages, you have great big whoppers for type parameters 
and have to pass them around everywhere you go; we’re relatively clean with 
Swift. Nobody writing swift should complain about our type parameters being too 
messy:

interface Feeder, S extends Store> { 
  public void buyFoodAndFeed(A animal, S store); 
} 
class StoreFeeder implements Feeder, Store> { 
  public void buyFoodAndFeed(Animal animal, Store store) { 
animal.eat(store.buyFood()); 
  } 
}

I have a counter-proposal to tackle the readability issue: that we extend 
SE-0048: Generic Typealiases [1] to include where clauses. The proposal already 
mentions this, and simply says "If there is a compelling reason to add this, we 
can consider extending the model to support them in the future, based on the 
merits of those reasons.” If we did that, we could drastically shorten 
function/class declarations - using, say, “StringCollection” or 
“IntegerSequence” rather than .

[1](https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md)


> On 10 May 2016, at 20:51, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0081: Move where clause to end of declaration" begins now 
> and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I apologize for any possible flood (if there is any restriction in this mail 
list).

One other example that comes to mind, where I can’t really tell if this would 
be possible to express with `struct<>`, can be defined outside of the generic 
scope just like `class` or `all`:

var structArray: [struct]

Would this work? This is an interesting case, where no values inside the struct 
can be reference-types!
Actually I can answer this question by myself, because `Any` is just a 
typealias for `protocol<>` and does not violate any rule here.

This also adds a few more type combinations I missed out in my proposal:

e.g. `struct` is equivalent to `struct>`

This can allow us to use any struct without the need of generic scope! Isn’t it 
great or what?

Have you ever wanted to store any class references with conformance to a 
protocol without the generic system, with this you could do so `class`: 

var classArray: [class]



Best Regards,

Adrian Zubarev



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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I don't think the struct functionality makes much sense. There are two ways you 
can use the struct<...> construct:
So does `enum<>` makes not much sense, I guess? I can’t think of any use-case 
were `enum<>` could do something what `struct<>` can’t.

1. struct. In this case the 
struct<...> representation is unnecessary; the protocols that are available to 
the user are known at compile-time, and structs can't have subtypes that 
conform to additional protocols like classes can. There is an example marked 
"func boo(value: struct) /* equivalent to */ func boo(value: 
SomeStruct)"; my question is why having more than two ways to express the same 
idea makes the language better, easier to use, etc.
Was this clarified somewhere, I mean that value types won’t have subtypes ever? 
This would be nice to know.

We already can write the same (ugly) scenario with protocols:
protocol A {}
extension A {
     func foo() {
          print("f")
     }
}

// this is the refined design that we all use
func boo(value: A) {
     value.foo()
}

// this might be the original design  
func zoo(value: protocol) {
     boo(value)
}

struct B: A {}
let value = B()

zoo(value)
boo(value)
The main idea behind `struct<>` etc. is not to make the language complicated, 
but to add symmetry to the type system, which should already have been there 
from the beginning. Compared to the little example I just wrote, we all already 
use the refined format of the (not present) base `struct<>`.

So if value types might have subtypes one day, this wouldn’t be hard to upgrade 
I suppose. Anyways I’ll move that part of the proposal to the future direction.

2. struct. In this case struct<...> is being used as 
an add-on to the generics system to denote a 'must be value type' constraint. 
However, I think a 'T : class'-like 'struct' constraint makes more sense, both 
because it fits better with the existing 'class' constraint and because it can 
be used anywhere the generic system allows a type parameter to be constrained.  
A generic 'struct' constraint would give the currently generics system as much 
expressive power as struct<...>.
True, but I feel like there is a change incoming in that direction 
([swift-evolution] Should we rename "class" when referring to protocol 
conformance?) and I don’t think the core team will decide to introduce `T: 
class`-like `struct` or `enum` constraint. :/

struct C {

    var value: T?

    func set(value: T) {

        self.value = value

    }

}

This would be nice to have. And yes this does look way better than:

struct C> {

    […]

}

But isn’t this again a refined usage of the base format (`struct<>` in this 
case)!? 

One other example that comes to mind, where I can’t really tell if this would 
be possible to express with `struct<>`, can be defined outside of the generic 
scope just like `class` or `all`:

var structArray: [struct]

Would this work? This is an interesting case, where no values inside the struct 
can be reference-types!

Overall, rather than having this be a separate feature I think it should be 
developed as part of the "Generalized Existentials" feature that is already on 
the roadmap for Swift 3. The cases where adding class<...>, struct<...>, etc 
can improve expressive power are covered by allowing variables to take 
existential types with constraints. The one big feature that Generalized 
Existentials should absorb from this proposal is allowing the representation of 
a concrete class type with protocol constraints ().
Is there any reading you can point me to, so I can include or quote it into the 
proposal?

-- 
Adrian Zubarev
Sent with Airmail

Am 14. Mai 2016 bei 06:06:12, Austin Zheng (austinzh...@gmail.com ) schrieb:


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

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Austin Zheng via swift-evolution]

I'm not quite sure I understand the 'Additional Utility' section. A given class 
hierarchy can only have one implementation of a given static method; static  
methods are effectively final. Therefore, the 'Self' introduced in the previous 
proposal should be completely sufficient for invoking a static method on a 
class. (Likewise, for moving around code.) In fact, the previous proposal for 
'Self' used a very similar example.

I think the example would make more sense if it involved class methods. 
However, *without considering the protocol applications* I wouldn't consider 
that a compelling enough use case, by itself, to add StaticSelf.

As for StaticSelf's impact on protocols, I defer to the opinions of the other 
folks who've commented on the thread.

Austin


> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Erica Sadun and I have written a proposal are following up the recent 
> discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an 
> invariant Self.
> 
> The recent discussion can be found here: 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565 
> 
> 
> The proposal can be found here: 
> https://github.com/anandabits/swift-evolution/blob/static-self/proposals/-static-self.md
>  
> 
> 
> We look forward to continuing the discussion.  We plan to submit a PR in the 
> near future after incorporating your final feedback.
> 
> Thanks,
> Matthew
> Introducing StaticSelf, an Invariant Self
> 
> Proposal: TBD
> Authors: Matthew Johnson , Erica Sadun 
> 
> Status: TBD
> Review manager: TBD
> Introduction
> 
> This proposal introduces a new keyword that provides consistent invariant 
> type semantics in all contexts.
> 
> The Swift-evolution thread about this topic can be found here: [RFC] #Self 
> 
> Motivation
> 
> The distinction between covariant and non-covariant type references come into 
> play when
> conforming non-final classes to protocols. Fixing a protocol requirement to a 
> covarying type
> means that a method returning Self must be overriden by all subclasses in 
> order to return
> the correct, matching type.
> 
> This proposal builds on the covariant construct Self accepted in SE–0068 
> 
> to introduce an invariant type identifier. It enables protocol declarations 
> to consistently
> refer to a type that is fixed at compile time. This ensures that subclasses 
> can inherit
> protocol implementations without having to re-implement that code at each 
> level of
> inheritance.
> 
> Under this proposal, a new identifier keyword is fixed in use at the point of 
> protocol conformance
> to the static type of that construct. 
> 
> class A: MyProtocol
> The invariant StaticSelf identifier will always refer to A, unlike Self, 
> which is covarying and refers to
> the type of the actual instance. Since multiple inheritance for non-protocol 
> types is disallowed,
> this establishes this invariant type identifier with no possibility for 
> conflict.
> 
> Consider the following example, under the current system:
> 
> protocol StringCreatable {
> static func createWithString(s: String) -> Self
> }
> 
> extension NSURL: StringCreatable {
>  // cannot conform because NSURL is non-final
>  // error: method 'createWithString' in non-final class 'NSURL' must return 
> `Self` to conform to protocol 'A'
> }
> Introducing a static, invariant version of Self permits the desired 
> conformance:
> 
> protocol StringCreatable {
> static func createWithString(s: String) -> StaticSelf
> }
> 
> extension NSURL: StringCreatable {
>  // can now conform conform because NSURL is fixed and matches the static
>  // type of the conforming construct. Subclasses need not re-implement
>  // NOTE: the return type can be declared as StaticSelf *or* as NSURL
>  //   they are interchangeable
>  static func createWithString(s: String) -> StaticSelf { 
>  // ...
>  }
> }
> Additional Utility
> 
> The utility of StaticSelf is not limited to protocols. A secondary use 
> enables code to refer to the lexical context’s current type without 
> explicitly mentioning its name. This provides a useful shortcut when 
> referencing static type members with especially long names and when 
> re-purposing code between types.
> 
> class StructWithAVeryLongName {
> static func foo() -> String {
>   // ...
> }
> func bar() {
>   // ...
>   let s = StaticSelf.foo()
>   //
> }
> }
> Detailed Design
> 
> This proposal introduces StaticSelf, a new keyword that may be used in 
> protocols to refer to the invariant static type of a conforming 

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Vladimir.S via swift-evolution]

Hmm.. very interesting..

@Matthew, is the code below looks like the same as you wanted to achieve 
with `->StaticSelf` ?


protocol Makable {
associatedtype MadeType
func make(value: Int) -> MadeType
}

class A {

}

class B: A {
func make(value: Int) -> B {
return B()
}
}

class C : B {
override func make(value: Int) -> B {
return C()
}
}


extension B : Makable {
typealias MadeType = B
}

func makeWithZero(creator t: T) -> T.MadeType {
return t.make(0)
}

var instance : B = C()

print(instance.make(0)) // main.C
print(makeWithZero(creator: instance))  // main.C



On 14.05.2016 8:55, Nicola Salmoria via swift-evolution wrote:

Matthew Johnson via swift-evolution  writes:


I agree it’s a bit tricky.  But that’s better than not possible at all.

 You just need a typealias and a same type constraint to make this work as
expected / desired:



protocol Makable {

typealias RootMakable = StaticSelf
static func make(value: Int) -> StaticSelf
}

func makeWithZero(x: Int) -> T {
return T.make(value: 0) // works now
 }


Now that we have a typealias we can refer to the binding of StaticSelf and

constrain it as necessary for whatever purpose we have in mind.  In some
cases that will be a same type constraint so that our code works properly
with class clusters.  I don’t have concrete examples of other use cases but
can imagine use cases constraining the typealias to a protocol, for example.

You can do that today:

protocol Makable {
associatedtype MadeType
static func make(value: Int) -> MadeType
}

func makeWithZero(x: Int) -> T {
return T.make(value: 0)
}

You can't currently constrain MadeType to be the same as the conforming
type, but, does it matter? What kind of extra guarantees would that give,
since you need to add the extra constraint anyway in generic code?

Nicola
___
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] Consistent bridging for NSErrors at the language boundary

[Charles Srstka via swift-evolution]

> On May 14, 2016, at 1:45 AM, Jon Shier via swift-evolution 
>  wrote:
> 
> Charles:
>   Foundation error reporting is based on NSError, nothing else. In none 
> of my apps have I used my own NSError’s and in the few frameworks I use or 
> maintain, few use NSError, and then only to avoid having to declare a custom 
> error type, to make the API perhaps a bit more familiar to consumers.

All of the error-handling mechanisms in Cocoa are NSError-based. 
-[NSApplication presentError:], -[NSDocument presentError:], and the like all 
take NSErrors.

> All your concern about conversion to and from NSErrors is largely irrelevant 
> to anyone who isn’t using Swift from Objective-C on a regular basis. It’s 
> utterly irrelevant to the native Swift programmer. I’m not sure where your 
> issue about presenting non-NSError’s come from, since the mechanisms to 
> present an error would have to be custom written no matter the error type.

Anyone who writes Cocoa apps on OS X or iOS using Swift is most certainly using 
Swift from Objective-C on a regular basis, because all of the underlying 
frameworks are Objective-C. For example, suppose you have a document-based 
application:

class MyDocument: NSDocument {
enum Error: ErrorType {
case MadeAMistake
case RanOutOfCake
}

…

readFromData(data: NSData, ofType: String) {
…

if someFailureCondition {
throw Error.RanOutOfCake
}

...
}

...
}

The readFromData method above will be called by Objective-C, since the internal 
NSDocument mechanism will be the one calling it. Since it will have no idea how 
to represent that, the error dialog box that appears will simply say something 
unhelpful like “MyApp.MyDocument.Error error 1”. Now, there are two ways to 
solve this, both of which involve throwing an NSError rather than a custom 
error type:

Solution 1: Get rid of the ErrorType.

class MyDocument: NSDocument {
let ErrorDomain = “MyApp.MyDocument”
enum ErrorCode: Int {
case MadeAMistake = 1
case RanOutOfCake = 2
}

…

readFromData(data: NSData, ofType: String) {
…

if someFailureCondition {
let userInfo = [NSLocalizedFailureReasonErrorKey: 
NSLocalizedString(“Looks like we ran out of cake.”, comment: “Ran out of cake”)]
throw NSError(domain: ErrorDomain, code: 
ErrorCode.RanOutOfCake.rawValue, userInfo: userInfo)
}

...
}

...
}

This has a couple of problems. First, it forces us to use NSError. Second, it’s 
ugly. Imagine a method with many possible failure points, all filled with the 
userInfo building above.

The second solution is a little better:

class MyDocument: NSDocument {
enum Error: ErrorType {
let ErrorDomain = “MyApp.MyDocument”

case MadeAMistake
case RanOutOfCake

func toNSError() -> NSError {
let failureReason: String
let code: Int

switch self {
case .MadeAMistake:
failureReason = NSLocalizedString(“Looks like we made a 
mistake.”, comment: “Made a mistake”)
code = 1
case .RanOutOfCake:
failureReason = NSLocalizedString(“Looks like we ran out of 
cake.”, comment: “Ran out of cake”)
code = 2
}

let userInfo = [NSLocalizedFailureReasonErrorKey: failureReason]

return NSError(domain: self.ErrorDomain, code: code, userInfo: 
userInfo)
}
}

…

readFromData(data: NSData, ofType: String) {
…

if someFailureCondition {
throw Error.RanOutOfCake.toNSError()
}

...
}

...
}

The good news is that now the ugliness is removed from the actual program code 
and confined to the error type’s declaration. The bad news is that if we forget 
to put .toNSError() on an error we throw somewhere and that bubbles back to 
Cocoa, the user gets a meaningless error message. Furthermore, if we call 
through to some other error-throwing method, we have to catch and convert any 
errors it might throw:

readFromData(data: NSData, ofType: String) {
…

do {
try somethingThatThrows()
} catch {
if let myError = error as? Error {
throw myError.toNSError()
} else if let someOtherError = error as? SomeOtherErrorType {
// convert to NSError somehow
} else if let yetAnotherError = …
etc. etc. etc.
} else {
throw error
}
}

…

}

At this point it’s probably just to use NSError all the way through. :-/

With my proposal, all you’d do is this:

class MyDocument: NSDocument {
enum Error: ErrorType {
case MadeAMistake
case RanOutOfCake

var userInfo: [NSObject : AnyObject] {
let failureReason: String

switch self {
case .MadeAMistake:
   

Re: [swift-evolution] [Idea] "guard not let" optional binding

[Karl via swift-evolution]

You could do that with everything and never use the guard statement at all if 
you wanted.

But it's actually pretty useful. There have been times where I’ve been heavily 
editing code and forgotten to leave the scope after a guard condition failed. 
Just recently I was editing some async functions with a callback with a 
throwable argument, I called the callback with the error but forgot to return 
afterwards; guard caught it for me.

Lets say I had your code, but was editing it to make it asynchronous:

if let value = cachedValue { return value }

cachedValue = // … expensive calculation
return cachedValue!

could become (if I was tired, in the middle of some big code changes):

if let value = cachedValue { callback(value) } // Oops, forgot to return, 
redundant re-calculation (and unexpected second callback) follows

cachedValue = // … expensive calculation
callback(cachedValue!)

guard wouldn’t let that happen. I use it every time I intend to exit scope 
early; it’s a better semantic model of my intention, so the compiler will 
notice on the off-chance I do mess up. 


> On 14 May 2016, at 07:56, Patrick Smith  wrote:
> 
> I’d probably write that as:
> 
> if let value = cachedValue { return value }
> 
> cachedValue = // … expensive calculation
> 
> 
>> On 14 May 2016, at 3:52 PM, Karl via swift-evolution 
>>  wrote:
>> 
>> If we want to check that an optional has a value and bail if it doesn't, we 
>> have the helpful pattern:
>> 
>>   guard let x = x else { throw SomeError }
>> 
>> However, it is also fairly common that you want to check that an optional 
>> *is* nil, and still bail if it isn’t (maybe using the value that you now 
>> know exists), e.g:
>> 
>>   guard cachedValue == nil else { return cachedValue! }
>>   cachedValue = //… expensive calculation
>> 
>> It seems a little bit “unfair” that we have this lovely clean `let` syntax 
>> when checking for Optional.Some, but we to have to do this ugly manual check 
>> against nil and explicit unwrap when checking for Optional.None. There is 
>> literally no other way to satisfy the guard statement; our optional bindings 
>> only go one-way can’t be evaluated.
>> 
>> What about if we introduced a “not” modifier to optional bindings?
>> 
>>   guard not let cachedValue = _someExpensiveResult else { return cachedValue 
>> }
>> 
>> This obviously wouldn’t make sense for “if let…” switching, as the variables 
>> get bound in the ‘else’ block and the code wouldn’t be very readable. For 
>> the special case of a guard statement, though, which only has an ‘else’ 
>> block, it does make some sense.
>> 
>> If we had something like this, certainly in my code, I’d be able to 
>> eliminate almost all (maybe even all) remaining force-unwraps of optionals; 
>> that’s great! It’d be amazing if the language was expressive enough that you 
>> could go without ever having to force-unwrap an optional. And it just makes 
>> sense. 
>> 
>> Thoughts?
>> 
>> Karl
>> ___
>> 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] Consistent bridging for NSErrors at the language boundary

[Jon Shier via swift-evolution]

Charles:
Foundation error reporting is based on NSError, nothing else. In none 
of my apps have I used my own NSError’s and in the few frameworks I use or 
maintain, few use NSError, and then only to avoid having to declare a custom 
error type, to make the API perhaps a bit more familiar to consumers. All your 
concern about conversion to and from NSErrors is largely irrelevant to anyone 
who isn’t using Swift from Objective-C on a regular basis. It’s utterly 
irrelevant to the native Swift programmer. I’m not sure where your issue about 
presenting non-NSError’s come from, since the mechanisms to present an error 
would have to be custom written no matter the error type. The drawbacks I see 
with exposing NSError’s properties on every ErrorType is that those properties 
are only there as a hack to interoperate with NSError. Really they’d go away as 
Swift evolves it’s own default error representation, or language leaves it to 
developer to build their own. 
Essentially, I think that if you want to improve ErrorType, formalizing 
its relationship to NSError is the wrong way. NSErrors are not good error 
representations, especially in Swift, and we should move away from them as soon 
as possible.


Jon
 
> On May 14, 2016, at 1:46 AM, Charles Srstka  wrote:
> 
> On May 14, 2016, at 12:19 AM, Jon Shier via swift-evolution 
>  wrote:
>> 
>> Charles:
>>  I appreciate the attempt to minimize a current pain point and I agree 
>> on most of your analysis of the current NSError bridging but I think your 
>> proposal is fundamentally flawed. By forcing the core error type to have 
>> properties from NSError, you’re essentially finalizing what all error types 
>> in Swift should look like. Error domains, codes, and info dictionaries are 
>> not Swift, and forcing every error produced in Swift to have those 
>> properties is a regression from the freedom ErrorType has given us. No 
>> native Swift error type I’ve seen so far has chosen to replicate those 
>> properties, and for good reason: they are a relic of C which have no place 
>> in Swift. There are far better error designs out there. If you want to 
>> propose a strong type of error for Swift, go ahead, but it should be 
>> thoroughly inspired by Swift, not driven by a desire to ease bridging to 
>> NSError.
> 
> Nothing is forced at all, any more than they are currently. The thing to 
> remember is that ErrorProtocol *already* defines properties for error domains 
> and codes:
> 
> public protocol ErrorProtocol {
>  var _domain: String { get }
>  var _code: Int { get }
> }
> 
> Thus, the statement that no native Swift error type has these properties 
> could not be farther from the truth, as in fact, *every* Swift error type has 
> these two properties (and several prominent error types in the standard 
> library provide specific values for these properties as well; POSIXError and 
> NSCocoaError come to mind). The reason many Swift developers haven’t noticed 
> this fact is because the properties have default implementations, which means 
> that if you don’t have a specific need to override them, you never have to 
> deal with them. Adding a userInfo property, which also has a default 
> implementation (returning an empty dictionary), will therefore not take away 
> any of the freedom of ErrorType, or really cause any difference at all to a 
> developer who is not interested in providing userInfo values on his/her 
> errors.
> 
> What the proposal will do, on the other hand, is give a lot of that freedom 
> *back*. The fact of the matter is that the entire error-reporting mechanism 
> is currently based on NSError. If you have a method which can return an 
> error, and you want that error to be presentable to the user in a form more 
> expressive than “MyApp.MyErrorType error 2”, you currently have only two 
> choices: 1) create some home-grown mechanism to convert your errors to 
> NSErrors, and be sure to invoke that mechanism when throwing from any method 
> that could conceivably be called from Objective-C, or 2) just use NSErrors 
> all the way down, foregoing the use of native Swift errors at all. My 
> proposal would allow the free and unlimited use of Swift native errors 
> everywhere errors are a possibility with no drawbacks, since if an error 
> needed to be made into a human-readable form, this would only be a simple 
> matter of defining a userInfo property on the error type, even if much later 
> down the line, and would not necessitate adding an NSError conversion at 
> every throw-site in the program. Indeed, this proposal will actually *remove* 
> a lot of NSError-based thinking from the actual code, and localize all such 
> considerations to a relatively small area, to such extent as they are needed.
> 
> Charles
> 

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

[Patrick Pijnappel via swift-evolution]

Hmm good point. Defining a toplevel function or property could reserve that
name in toplevel scope, but you'd be in trouble when two protocols from
different modules require a toplevel function or property with the same
signature.

I'm not sure how operators deal with this because they should have the
same problem...

On Friday, 13 May 2016, Leonardo Pessoa via swift-evolution <
swift-evolution@swift.org> wrote:

> To me this makes more sense for operators than for other functions or
> properties. For the former you could create conflict with previously
> declared function (or properties with variables) and there is no
> restriction in Swift that says you cannot or should not create a top level
> function or property.
>
> In this sense, having an operator declared inside a class/struct/enum
> would already make them top level as you proposed, no need for another
> keyword. I would only add one requirement: that the first argument should
> always be of type Self (and have it checked by the compiler). It ensures
> the operator operates on that type and helps minimising conflicts with a
> previously declared operator.
>
> - Leonardo
>
> On 13 May 2016 at 04:12, Patrick Pijnappel via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>> For some protocols we'd like to require top-level (free) functions, e.g.
>> for many math functions such as abs() or sin(). We already do this
>> implicitly for operators.
>>
>> *Proposal*
>> Allow top-level function/property requirements in protocols, e.g.:
>>
>> public protocol AbsoluteValuable : SignedNumber { /// Returns the
>> absolute value of `x`. @warn_unused_result toplevel func abs(_ x: Self)
>> -> Self }
>>
>> We'd probably want to require this for operators. This also opens up
>> syntax if we ever get dynamically dispatched operators.
>>
>>
>> public protocol SignedNumber : Comparable, IntegerLiteralConvertible { ///
>> Returns the result of negating `x`. @warn_unused_result toplevel prefix
>> func - (x: Self) -> Self }
>>
>> Currently this is done using the combination of a static method and a
>> top-level generic function on that protocol. As I understand that approach
>> does have some benefits in terms of type-checker performance, though I'm
>> not sure whether that is likely to stay relevant in the future.
>>
>> *Advantages*
>>
>>- Cleaner than current approach (esp. floating point types have tons
>>of top-level functions)
>>- Makes operators less of a special case
>>- Opens up syntax for member operators
>>- Could also apply to top-level properties (esp. useful if we get
>>generic properties, for e.g. π<...>)
>>
>>
>> ___
>> 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] [Review] SE-0081: Move where clause to end of declaration

[Jon Shier via swift-evolution]

I notice now that the proposal does define how the change interacts with type 
declarations, in the grammar section. However, I still see that as an even 
worse change than in the function case.



Jon Shier


> On May 14, 2016, at 1:05 AM, Jon Shier  wrote:
> 
>> * What is your evaluation of the proposal?
> 
> -1
> 
> No one has been able to explain how this change improves readability, it just 
> seems like it’s supposed to be self evident. I would argue that it makes the 
> generic definitions less readable by separating declarations and their 
> relevant where clauses. At best this change just moves the already unreadable 
> mass of text elsewhere, where it’s still unreadable. Furthermore, it trades 
> this supposed readability of generic parameters for decreased readability of 
> the actual function signature, since that signature’s now buried between the 
> generic definitions and the where clauses. This is especially bad when 
> declaring a single generic type that can easily fit on a single line, such as:
> 
> func something(with something: T) -> 
> String 
> 
> turns into this, which is less readable to me, as it hides important 
> information between the generic information:
> 
> func something(with something: T) -> String where T == 
> T.DecodedType
> 
> Also, this proposal doesn’t explain how the definitions for generic types 
> would change. Using the proposed grammar would be even worse on types. From:
> 
> final class NetworkOperation: 
> Operation,… {
> 
> to:
> 
> final class NetworkOperation: Operation,… where T == 
> T.DecodedType {
> 
> The additional conformances types can have make this an especially bad use 
> case for this proposal. 
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> It can be a problem, but I don’t see how this proposal fixes it. Appropriate 
> code styling, whether manual or provided by an IDE, could provide much better 
> readability than this proposal ever could.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Changes proposed for “readability” need to be closely scrutinized, as one 
> programmer’s readable and another’s Perl. I don’t think this proposal meets 
> the high standard this list has tried to set for things to the language.
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> Java and C++’s generics, which are rather different. And despite what they 
> may have intended, I don’t think generics in either language are used as much 
> as in Swift.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Read the proposal, the thread thus far, and considered my response.
> 
> 
> 
> Jon
> 

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