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

[plx via swift-evolution]

Late, but +1 *overall*.

For function signatures I am somewhat indifferent, honestly; I think having the 
option to move part of the `where` clause after the signature declaration is 
beneficial, but not hugely so.

The reasoning here is simple: currently functions look like `func 
$name<$genericParameters>($args) -> $result`, and even though it’s difficult to 
*read* a lengthy `$genericParameters` the `($args) -> $result` portion (e.g. 
signature) isn’t "broken up". It’s good that it’s not broken up, but it means 
for *functions* the proposal is making only a minor readability improvement (by 
moving the “signature" closer to the “name”).

But, I think we have a *significant* improvement here for *type* declarations — 
classes, structs, etc. — because they look like e.g. this for classes: `class 
$name<$genericParameters> : $base (, … $protocols )`. If one is writing classes 
that use a lot of generic parameters with a lot of relationships between their 
associated types, the key parts of the type declaration wound up “split up” b/c 
the `$name` is very far away from the `$base`.

It’s apparently a somewhat-uncommon use but it’s *a lot nicer* under this 
proposal than under current syntax.

I wouldn’t object if the proposal tried to be a bit less flexible and e.g. 
forced all `:`-style constraints into the initial `<>` segment and all `where 
X.Y == Z.Q`-style constraints into the subsequent `where` clause, but I also 
don’t feel that that would be an unqualified improvement.

> On May 10, 2016, at 1:51 PM, 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:
> 
>   * 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] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 16, 2016, at 8:16 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>>> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution 
>>> :
>>> 
>>> internal func _arrayOutOfPlaceReplace
>>> 
>>> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: 
>>> Int)
>>> where
>>> C.Iterator.Element == B.Element,
>>> B.Index == Int
>>> {
>>> 
>>> Now only the relatively unimportant details—that the buffer and collection 
>>> must have elements of the same type, and that the buffer must have integer 
>>> indices—are at the end, whereas the basic conformances required to make any 
>>> sense at all of the declaration are still inline.
>> 
>> You see, I’m of the complete opposite opinion - I don’t think those details 
>> are “relatively unimportant”; I think they’re absolutely critical.
>> 
>> If you try and call it when your C.Iterator.Element is not equal to 
>> B.Element, the function does not exist. You’re talking about some other 
>> function in that case, not this one.
>> 
>> Same goes if B.Index is not an Int. If that was an unimportant detail, they 
>> would have given ‘bounds’ the type Range and not specified any 
>> constraints at all. The function requires the index be an Int - maybe it’s 
>> doing some mathematical operations which wouldn’t make sense for a more 
>> complex index type, such as DictionaryIndex.
>> 
>> Basically that is it - the ‘where’ clause is a vital part of the function 
>> declaration; it defines the specification under which the function exists at 
>> all (along with the function name, arguments and return type). If you don’t 
>> match every single part of that specification, the type checker won’t match 
>> your call to this function - if you don’t meet the constraints, you’re not 
>> talking about this function; imagine you have several overloaded function 
>> declarations which differ only by ‘where’ condition:
>> 
>> func insert(contentsOf:T) where T:RandomAccessCollection, T.Element == 
>> Element
>> func insert(contentsOf:T) where T:Collection, T.Element == Element
>> func insert(contentsOf:T) where T:Sequence, T.Element == Element
>> … etc
>> 
>> the ‘where’ clause isn’t incidental here - it’s the only disambiguating 
>> feature between these declarations. I think it’s critical information and 
>> shouldn’t be stuffed at the end because you think it’s not important; it is 
>> important. If it hinders initial readability of the declaration so much, you 
>> can wrap it behind a typealias:
>> 
>> func insert>(contentsOf: T)
>> func insert>(contentsOf: T)
>> func insert>(contentsOf: T)
>> … etc
> 
> Either you have the constraints first and the parameter list last or the 
> other way around. Fact is that *both* decide whether it is the function you 
> need.
> So just their order cannot help with that.
> I would still argue that the proposed version is more readable: just look at 
> your example above where the first part up to the where is identical at one 
> glance, so that the disambiguating part stands out whereas your other example 
> looks much more unstructured because of the different lengths of the generic 
> type list which makes the congruence of the parameter lists difficult to see 
> because they do not align anymore.
> 
>> 
>> I think that’s much easier to follow, and attempts to reduces the length and 
>> verbosity of the where clauses (i.e. like the fact that Collection’s 
>> associated type referring to its element is called ‘Element’; ‘CollectionOf’ 
>> encodes an equivalent constraint in less characters). This proposal just 
>> feels kind of lazy - we’ll just tack them on the end so we can ignore them a 
>> bit more easily, even though they’re still going to be monstrously long and 
>> difficult-to-read.
> 
> The typealias idea can be combined with the where clause at the end:
> 
> func insert(contentsOf:T) where T:RandomAccessCollectionOf
> func insert(contentsOf:T) where T:CollectionOf
> func insert(contentsOf:T) where T:SequenceOf
> 
> Much easier to discern (at least IMO) because everything is aligned.
> 
>> 
>> Are there any other languages that do this? Or anything even similar? It 
>> seems to me that the context-switching is something that human beings in 
>> general are not going to find very legible; like if you insert too many 
>> commas in a sentence.
> 
> Yes, Ceylon places all constraints (it only knows inheritance constraints) at 
> the end:
> 
> shared Value sum({Value+} values) 
> given Value satisfies Summable { ... }
> shared Item>[] zip({Key*} keys, {Item*} items)
> given Key satisfies Object
> given Item satisfies Object { ... }
> 
> It does the same for type definitions:
> shared class Singleton(Element element)
> extends Object()
> satisfies [Element+]
> given Element satisfies Object { ... }
> 

This confirms my impression that WHERE does not fit as well at the end as if 
the 

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

[Thorsten Seitz via swift-evolution]

> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution 
> :
> 
>> internal func _arrayOutOfPlaceReplace
>> 
>> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
>> where
>> C.Iterator.Element == B.Element,
>> B.Index == Int
>> {
>> 
>> Now only the relatively unimportant details—that the buffer and collection 
>> must have elements of the same type, and that the buffer must have integer 
>> indices—are at the end, whereas the basic conformances required to make any 
>> sense at all of the declaration are still inline.
> 
> You see, I’m of the complete opposite opinion - I don’t think those details 
> are “relatively unimportant”; I think they’re absolutely critical.
> 
> If you try and call it when your C.Iterator.Element is not equal to 
> B.Element, the function does not exist. You’re talking about some other 
> function in that case, not this one.
> 
> Same goes if B.Index is not an Int. If that was an unimportant detail, they 
> would have given ‘bounds’ the type Range and not specified any 
> constraints at all. The function requires the index be an Int - maybe it’s 
> doing some mathematical operations which wouldn’t make sense for a more 
> complex index type, such as DictionaryIndex.
> 
> Basically that is it - the ‘where’ clause is a vital part of the function 
> declaration; it defines the specification under which the function exists at 
> all (along with the function name, arguments and return type). If you don’t 
> match every single part of that specification, the type checker won’t match 
> your call to this function - if you don’t meet the constraints, you’re not 
> talking about this function; imagine you have several overloaded function 
> declarations which differ only by ‘where’ condition:
> 
> func insert(contentsOf:T) where T:RandomAccessCollection, T.Element == 
> Element
> func insert(contentsOf:T) where T:Collection, T.Element == Element
> func insert(contentsOf:T) where T:Sequence, T.Element == Element
> … etc
> 
> the ‘where’ clause isn’t incidental here - it’s the only disambiguating 
> feature between these declarations. I think it’s critical information and 
> shouldn’t be stuffed at the end because you think it’s not important; it is 
> important. If it hinders initial readability of the declaration so much, you 
> can wrap it behind a typealias:
> 
> func insert>(contentsOf: T)
> func insert>(contentsOf: T)
> func insert>(contentsOf: T)
> … etc

Either you have the constraints first and the parameter list last or the other 
way around. Fact is that *both* decide whether it is the function you need.
So just their order cannot help with that.
I would still argue that the proposed version is more readable: just look at 
your example above where the first part up to the where is identical at one 
glance, so that the disambiguating part stands out whereas your other example 
looks much more unstructured because of the different lengths of the generic 
type list which makes the congruence of the parameter lists difficult to see 
because they do not align anymore.

> 
> I think that’s much easier to follow, and attempts to reduces the length and 
> verbosity of the where clauses (i.e. like the fact that Collection’s 
> associated type referring to its element is called ‘Element’; ‘CollectionOf’ 
> encodes an equivalent constraint in less characters). This proposal just 
> feels kind of lazy - we’ll just tack them on the end so we can ignore them a 
> bit more easily, even though they’re still going to be monstrously long and 
> difficult-to-read.

The typealias idea can be combined with the where clause at the end:

func insert(contentsOf:T) where T:RandomAccessCollectionOf
func insert(contentsOf:T) where T:CollectionOf
func insert(contentsOf:T) where T:SequenceOf

Much easier to discern (at least IMO) because everything is aligned.

> 
> Are there any other languages that do this? Or anything even similar? It 
> seems to me that the context-switching is something that human beings in 
> general are not going to find very legible; like if you insert too many 
> commas in a sentence.

Yes, Ceylon places all constraints (it only knows inheritance constraints) at 
the end:

shared Value sum({Value+} values) 
given Value satisfies Summable { ... }
shared Item>[] zip({Key*} keys, {Item*} items)
given Key satisfies Object
given Item satisfies Object { ... }

It does the same for type definitions:
shared class Singleton(Element element)
extends Object()
satisfies [Element+]
given Element satisfies Object { ... }

-Thorsten

> 
>> On 15 May 2016, at 16:05, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> There we are. I read the declaration of the function from beginning to end
>>> and gradually formed a rough understanding of it without needing to change
>>> my expectations halfway through. I still have doubts about 'insertCount',
>>> but I 

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

[Austin Zheng via swift-evolution]

+1. Non-type generic parameters can be handled if/when they are proposed after 
Swift 3. There have to be better ways to encourage proper organization of the 
elements of a method header than forcing a redundant and non-obvious 
conformance to 'Any'; if this is mandatory the proposal is fatally flawed and 
should be taken back to the drawing board.

Austin

> On May 16, 2016, at 2:36 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Having to declare conformance to `Any` is just noise and should *not* be 
> mandatory IMHO.
> 
> -Thorsten
> 
> 
>> Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution 
>> >:
>> 
>> 
>>> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> I'm actually tempted to suggest that a conformance should be *mandatory* 
>>> and you should have to specify `Any` if you don't have anything more 
>>> specific to say about the generic parameter:
>>> 
>>> func map(@noescape transform: (Element) throws -> T) rethrows 
>>> -> [T]
>> 
>> That's a good idea indeed if we ever intend to have other kinds of generic 
>> arguments (in particular, constant values like `length: Int`).
>> 
>> Even so, I wouldn't want to prohibit adding more protocol constraints in the 
>> where clause even if you can introduce all constaints of `T` at once as `T: 
>> protocol`.
>> 
>> — Pyry
>> 
>> ___
>> 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] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

Having to declare conformance to `Any` is just noise and should *not* be 
mandatory IMHO.

-Thorsten


> Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution 
> :
> 
> 
>> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>> I'm actually tempted to suggest that a conformance should be *mandatory* and 
>> you should have to specify `Any` if you don't have anything more specific to 
>> say about the generic parameter:
>> 
>>  func map(@noescape transform: (Element) throws -> T) rethrows 
>> -> [T]
> 
> That's a good idea indeed if we ever intend to have other kinds of generic 
> arguments (in particular, constant values like `length: Int`).
> 
> Even so, I wouldn't want to prohibit adding more protocol constraints in the 
> where clause even if you can introduce all constaints of `T` at once as `T: 
> protocol`.
> 
> — Pyry
> 
> ___
> 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

[Pyry Jahkola via swift-evolution]

> On 16 May 2016, Thorsten Seitz wrote:
> 
> Funny, for me reading a function is quite the other way around:
> I prefer to first look at the function name and parameter list to give me an 
> idea of what the function will do (the parameter names help a lot).
> Having instead first to memorize a list of types with all their constraints 
> just builds up the cognitive load without helping much, because their usage 
> is yet unknown.

This is also my biggest motivation for the proposal: keeping the function name 
and arguments close to each other.

> So, for me reading the signature would look like (with the proposal in place):
> 
>>> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
>>> Range, _ newValues: C, _ insertCount: Int)


^ Agreed! That's essentially what I'm trying to find too when skimming through 
code.

An alternative approach with the same desired outcome would be moving the 
parameter list before the function name, either `func<...> someFunction(...)`, 
or even before the `func` keyword. But since we already use `where`, it seems 
more natural to me for Swift to place the constraints list to the end.

— Pyry

___
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

[Thorsten Seitz via swift-evolution]

Funny, for me reading a function is quite the other way around:
I prefer to first look at the function name and parameter list to give me an 
idea of what the function will do (the parameter names help a lot).
Having instead first to memorize a list of types with all their constraints 
just builds up the cognitive load without helping much, because their usage is 
yet unknown.

So, for me reading the signature would look like (with the proposal in place):

>> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
>> Range, _ newValues: C, _ insertCount: Int)

Ah, this function does some replacement within a source which is mutated. The 
replacement seems to affect a range within the source and there are some new 
values given together with their count.
Now I have already a feeling what the method does and can look at the types to 
get more details.

If I would have to read the types first I would not have been able to extract 
as much information from them to guess what the function does, so trying to 
interpret them would just have been a waste of time and I would have to look 
them up again after reading the parameter list anyway.

-Thorsten



> Am 15.05.2016 um 12:38 schrieb Nicola Salmoria via swift-evolution 
> :
> 
> David Hart via swift-evolution  writes:
> 
>> 
>> 
>> Hi Karl,
>> 
>> As author of this proposal, the one about constraints on associated types,
> and the one on type-aliases in protocols (all from the Generics Manifesto -
> original authorship to Douglas Gregor) I’d like to provide additional
> reasoning behind my wish to push this proposal through, as a whole.
>> 
>> First of all, there is a personal preference. I’ve used C# for many many
> years, which has its where clause at the end of the declaration (like this
> proposal), and I’ve used Swift since its unveiling. The experience with
> using both styles for several years makes me favour this proposal’s syntax
> because I find it much easier to read and format for readability.
>> 
>> Constraints on associated type will provide more expressivity but I doubt
> it will greatly reduce protocol constraint clauses in a majority of cases.
> And yes, type-aliases in protocols will shorten clauses, but I still think
> they will more readable with the where clause at the end.
>> 
>> For example, here is a method I took (as-is) from the Standard Library
> which has a few constraints, and which I further simplified if we imagine
> that Sequence has an Element typealias for Iterator.Element:
>> 
>> 
>> internal func _arrayOutOfPlaceReplace<
>>   B : _ArrayBufferProtocol, C : Collection
>>   where  C.Element == B.Element,
>>   B.Index == Int
>>> (  _ source: inout B, _ bounds: Range, _ newValues:
>> C, _ insertCount: Int) {
>> 
>> See how the Standard Library authors formatted it for readability and how
> as a consequence arguments which use the generic types are further apart
> from the declaration of those generic types. But with this proposal, the
> declaration might be formatted to:
>> 
>> internal func _arrayOutOfPlaceReplace(_ source: inout B,
>>  _ bounds: Range, _ newValues: C, _ insertCount: Int)
>>   where
>> B : _ArrayBufferProtocol,
>>   C : Collection,
>>   C.Iterator.Element == B.Element,
>>   B.Index == Int
>> {
>> 
>> Do you need believe this is now more readable?
>> 
>> David.
> 
> Thanks for the real world example!
> 
> I think that the second arguably *looks* better. But is it more *readable*?
> Not for me.
> 
> Let me try to do a brain dump while I mentally parse the declaration.
> 
>> internal func _arrayOutOfPlaceReplace(
> 
> Mmm, here we have a function that has something to do with arrays, generic
> on two types. Maybe it will take an Array and output an Array?
> 
>> _ source: inout B,
> 
> Ah, the first argument is a B that will be changed. Maybe the function deals
> with Array and will replace occurrences of 'source' with something else?
> 
>> _ bounds: Range,
> 
> Ok, this surely must be the range of the Array to operate on.
> 
>> _ newValues: C,
> 
> Oh, this parameter is called 'newValues', so C can't be a single value. It
> must be a Collection, surely.
> 
>> _ insertCount: Int)
> 
> ... I can't figure out what this could be.
> 
>> where
>> B : _ArrayBufferProtocol,
> 
> Oh, B was some kind of buffer. OK so the function probably takes this
> buffer, and replaces 'range' with 'newValues'
> 
>> C : Collection,
>> C.Iterator.Element == B.Element,
> 
> Good, this confirms what I thought.
> 
>> B.Index == Int
> 
> Looks like an implementation detail, I guess that's why 'range' is a
> Range and 'insertCount' is an Int. Presumably the function needs to do
> some operations that the generic Index doesn't guarantee.
> 
> So that's the end of it. I have a vague idea of what the function might do,
> and had to revise my expectations a few times while reading its declaration.
> 
> 
> Let's try again with the original declaration.
> 
>> internal func 

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

[Thorsten Seitz via swift-evolution]

> Am 14.05.2016 um 20:19 schrieb 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.

But this scatters the function definition itself, i.e. the name of the function 
and its parameter list and return type over multiple lines.
And splitting the <> over multiple lines is really ugly. The leading > even 
looks like an operator (is it func >(value: S) being defined?).

I think 

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

is much more readable.

Or what about using some more suggestive names for the generic paramters, so 
that the core of the function definition can be kept even shorter without 
loosing readability:

func someMethod(value: Seq) -> AnySequence
where
Seq: SequenceType,
Seq.Generator.Element == Elem {
…
}

Here, I don’t see the need to keep all constraints up front because the generic 
parameters already suggest their nature. The where clause just fills in the 
technical constraints.

This would not be possible with the current syntax at all.

-Thorsten


> 
> 
>> 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

___
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

[Thorsten Seitz via swift-evolution]

> Am 14.05.2016 um 17:52 schrieb 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.

IMO the readability is improved because the where clause can be easily placed 
in a new line. Generic function definitions with where clauses typically are 
too long for being crammed into one line without having the readability suffer. 
The proposal allows a much more readable splitting of the definition into 
several lines. This completely alleviates the problem of separating generic 
type information or sandwiching the return type, because the where clause in 
the next line will be near the generic type parameter list again.
Taking Jon Shier’s example: 
The following definition is already too long IMO. The current syntax does not 
allow nice splitting of the line and readability suffers from the long gap 
between the function name and its parameter list:
func something(with something: T) -> 
String

instead of writing a long line with sandwiching problems like that:
func something(with something: T) -> String where T == 
T.DecodedType

I would write:
func something(with something: T) -> String 
where T == T.DecodedType


To recap: I think that readability improves with the proposal for the following 
reasons:
- The gap between the function name and its parameter list is reduced
- Definitions with where clauses typically are already too long to readably fit 
into one line, so they should be split over more than one line. The current 
syntax does not offer a natural position for a line break (breaking before the 
where even further increases the gap between the function name and its 
parameter list and it looks ugly because of the angle brackets being on 
separate lines.

-Thorsten

> 
> 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 

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

[L. Mihalkovic via swift-evolution]

On May 16, 2016, at 12:45 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Being able to let the developer decide how to place relevant type 
>> information with the freedom of being able to keep some/all/none type 
>> information local and some/none/all extra information moved to the end of 
>> the declaration.
> 
> To be clear, I do think it makes sense to move *all* `where` clauses to the 
> end of the parameter list, not allow them both within the angle brackets and 
> at the end of the definition. And I'm not convinced it makes sense to support 
> moving all conformance information to the `where` clause, either. A generic 
> parameter list like `` is vacuous; when you're dealing with something 
> like this:
> 
>public func transcode
> UnicodeCodec>
>(_ input: Input, from inputEncoding: InputEncoding.Type, to 
> outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool, 
> sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void) 
> -> Bool
>where InputEncoding.CodeUnit == Input.Element
> 
> The detail in the `where` clause really is of secondary importance, 
> especially compared to how much syntax it takes to specify, while this:
> 
>public func transcode
>(_ input: Input, from 
> inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type, 
> stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape 
> (OutputEncoding.CodeUnit) -> Void) -> Bool
>where Input: IteratorProtocol, InputEncoding: UnicodeCodec, 
> OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element
> 
> Leaves far too much unspecified until the end.

Purely a matter of opinion... I'm fine with it.

> 
> I'm actually tempted to suggest that a conformance should be *mandatory* and 
> you should have to specify `Any` if you don't have anything more specific to 
> say about the generic parameter:
> 
>func map(@noescape transform: (Element) throws -> T) rethrows -> 
> [T]
> 
> That would penalize the "leave everything until the end" style without 
> actually introducing any arbitrary rules forbidding it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

[Pyry Jahkola via swift-evolution]

> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> I'm actually tempted to suggest that a conformance should be *mandatory* and 
> you should have to specify `Any` if you don't have anything more specific to 
> say about the generic parameter:
> 
>   func map(@noescape transform: (Element) throws -> T) rethrows 
> -> [T]

That's a good idea indeed if we ever intend to have other kinds of generic 
arguments (in particular, constant values like `length: Int`).

Even so, I wouldn't want to prohibit adding more protocol constraints in the 
where clause even if you can introduce all constaints of `T` at once as `T: 
protocol`.

— Pyry

___
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

[Patrick Smith via swift-evolution]

I tend to agree with Jon Shier, Karl Wagner, Nicola Salmoria, and Tony 
Allevato. I think moving `where` to the end hinders comprehension. The extra 
constraint abilities that Nicola brought up look interesting.


> On 15 May 2016, at 1:52 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 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

___
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

[Brent Royal-Gordon via swift-evolution]

> Being able to let the developer decide how to place relevant type information 
> with the freedom of being able to keep some/all/none type information local 
> and some/none/all extra information moved to the end of the declaration.

To be clear, I do think it makes sense to move *all* `where` clauses to the end 
of the parameter list, not allow them both within the angle brackets and at the 
end of the definition. And I'm not convinced it makes sense to support moving 
all conformance information to the `where` clause, either. A generic parameter 
list like `` is vacuous; when you're dealing with something like this:

public func transcode

(_ input: Input, from inputEncoding: InputEncoding.Type, to 
outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool, 
sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void) 
-> Bool
where InputEncoding.CodeUnit == Input.Element

The detail in the `where` clause really is of secondary importance, especially 
compared to how much syntax it takes to specify, while this:

public func transcode
(_ input: Input, from 
inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type, 
stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape 
(OutputEncoding.CodeUnit) -> Void) -> Bool
where Input: IteratorProtocol, InputEncoding: UnicodeCodec, 
OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element

Leaves far too much unspecified until the end.

I'm actually tempted to suggest that a conformance should be *mandatory* and 
you should have to specify `Any` if you don't have anything more specific to 
say about the generic parameter:

func map(@noescape transform: (Element) throws -> T) rethrows 
-> [T]

That would penalize the "leave everything until the end" style without actually 
introducing any arbitrary rules forbidding it.

-- 
Brent Royal-Gordon
Architechies

___
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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution 
 wrote:

>> There we are. I read the declaration of the function from beginning to end
>> and gradually formed a rough understanding of it without needing to change
>> my expectations halfway through. I still have doubts about 'insertCount',
>> but I was at least able to formulate an hypothesis about its use.
>> 
>> YMMV, but as far as I'm concerned, the original declaration was much easier
>> to understand.
> 
> I actually agree with you for this case, but not *all* type information *has* 
> to be moved to the end. Try this on for size, which is actually still the 
> most natural way to write this declaration in SE-0081:
> 
> internal func _arrayOutOfPlaceReplace
> 
> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
>  where
>  C.Iterator.Element == B.Element,
>  B.Index == Int
> {
> 
> Now only the relatively unimportant details—that the buffer and collection 
> must have elements of the same type, and that the buffer must have integer 
> indices—are at the end, whereas the basic conformances required to make any 
> sense at all of the declaration are still inline.
> 
> This proposal *permits* you to hollow out the generic parameter list to the 
> point of vacuousness, but that doesn't mean it's the right thing to do. It 
> might make sense to ban a direct `X: Foo` requirement unless there was 
> already an `X: Bar` in the generic parameter list. Or we might simply need to 
> paraphrase the Perl manual page: "There are several ways to write a generic 
> requirement, so consider picking the most readable one."

I think you hit the nail on the head. Being able to let the developer decide 
how to place relevant type information with the freedom of being able to keep 
some/all/none type information local and some/none/all extra information moved 
to the end of the declaration. Don't we allow the same kind of freedom with 
protocols and extensions in a way?


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

[Brent Royal-Gordon via swift-evolution]

> There we are. I read the declaration of the function from beginning to end
> and gradually formed a rough understanding of it without needing to change
> my expectations halfway through. I still have doubts about 'insertCount',
> but I was at least able to formulate an hypothesis about its use.
> 
> YMMV, but as far as I'm concerned, the original declaration was much easier
> to understand.

I actually agree with you for this case, but not *all* type information *has* 
to be moved to the end. Try this on for size, which is actually still the most 
natural way to write this declaration in SE-0081:

internal func _arrayOutOfPlaceReplace
 
 (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
  where
  C.Iterator.Element == B.Element,
  B.Index == Int
{

Now only the relatively unimportant details—that the buffer and collection must 
have elements of the same type, and that the buffer must have integer 
indices—are at the end, whereas the basic conformances required to make any 
sense at all of the declaration are still inline.

This proposal *permits* you to hollow out the generic parameter list to the 
point of vacuousness, but that doesn't mean it's the right thing to do. It 
might make sense to ban a direct `X: Foo` requirement unless there was already 
an `X: Bar` in the generic parameter list. Or we might simply need to 
paraphrase the Perl manual page: "There are several ways to write a generic 
requirement, so consider picking the most readable one."

-- 
Brent Royal-Gordon
Architechies

___
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

[Nicola Salmoria via swift-evolution]

David Hart via swift-evolution  writes:

> 
> 
> Hi Karl,
> 
> As author of this proposal, the one about constraints on associated types,
and the one on type-aliases in protocols (all from the Generics Manifesto -
original authorship to Douglas Gregor) I’d like to provide additional
reasoning behind my wish to push this proposal through, as a whole.
> 
> First of all, there is a personal preference. I’ve used C# for many many
years, which has its where clause at the end of the declaration (like this
proposal), and I’ve used Swift since its unveiling. The experience with
using both styles for several years makes me favour this proposal’s syntax
because I find it much easier to read and format for readability.
> 
> Constraints on associated type will provide more expressivity but I doubt
it will greatly reduce protocol constraint clauses in a majority of cases.
And yes, type-aliases in protocols will shorten clauses, but I still think
they will more readable with the where clause at the end.
> 
> For example, here is a method I took (as-is) from the Standard Library
which has a few constraints, and which I further simplified if we imagine
that Sequence has an Element typealias for Iterator.Element:
> 
> 
> internal func _arrayOutOfPlaceReplace<
>  B : _ArrayBufferProtocol, C : Collection
>  where  C.Element == B.Element,
>  B.Index == Int
> >(  _ source: inout B, _ bounds: Range, _ newValues:
> C, _ insertCount: Int) {
> 
> See how the Standard Library authors formatted it for readability and how
as a consequence arguments which use the generic types are further apart
from the declaration of those generic types. But with this proposal, the
declaration might be formatted to:
> 
> internal func _arrayOutOfPlaceReplace(_ source: inout B,
> _ bounds: Range, _ newValues: C, _ insertCount: Int)
>  where
>  B : _ArrayBufferProtocol,
>  C : Collection,
>  C.Iterator.Element == B.Element,
>  B.Index == Int
> {
> 
> Do you need believe this is now more readable?
> 
> David.

Thanks for the real world example!

I think that the second arguably *looks* better. But is it more *readable*?
Not for me.

Let me try to do a brain dump while I mentally parse the declaration.

> internal func _arrayOutOfPlaceReplace(

Mmm, here we have a function that has something to do with arrays, generic
on two types. Maybe it will take an Array and output an Array?

> _ source: inout B,

Ah, the first argument is a B that will be changed. Maybe the function deals
with Array and will replace occurrences of 'source' with something else?

> _ bounds: Range,

Ok, this surely must be the range of the Array to operate on.

> _ newValues: C,

Oh, this parameter is called 'newValues', so C can't be a single value. It
must be a Collection, surely.

> _ insertCount: Int)

... I can't figure out what this could be.

>  where
>  B : _ArrayBufferProtocol,

Oh, B was some kind of buffer. OK so the function probably takes this
buffer, and replaces 'range' with 'newValues'

>  C : Collection,
>  C.Iterator.Element == B.Element,

Good, this confirms what I thought.

>  B.Index == Int

Looks like an implementation detail, I guess that's why 'range' is a
Range and 'insertCount' is an Int. Presumably the function needs to do
some operations that the generic Index doesn't guarantee.

So that's the end of it. I have a vague idea of what the function might do,
and had to revise my expectations a few times while reading its declaration.


Let's try again with the original declaration.

> internal func _arrayOutOfPlaceReplace<
>  B : _ArrayBufferProtocol, C : Collection

OK, here we have a function that deals with Arrays, generic on some buffer
thing and on a Collection. B is presumably what it needs to operate on, and
C will be the thing to replace with.

>  where  C.Element == B.Element,

Indeed thic confirms that B and C must be compatible.

>  B.Index == Int

Looks like an implementation detail, presumably we need to indicate the
position in the array where to do the replace.

> >(  _ source: inout B,

OK so this is a mutating function, and B is a buffer that will be modified.

> _ bounds: Range,

This is probably the range of the buffer that needs to be replaced, indeed
we had B.Index == Int.

> _ newValues: C,

And this collection contains what we need to insert in the buffer.

> _ insertCount: Int) {

Not sure what this might be, maybe the function will copy only the first
'insertCount' elements of C.

There we are. I read the declaration of the function from beginning to end
and gradually formed a rough understanding of it without needing to change
my expectations halfway through. I still have doubts about 'insertCount',
but I was at least able to formulate an hypothesis about its use.

YMMV, but as far as I'm concerned, the original declaration was much easier
to understand.

Now if we had generic typealiases, we could do something like

typealias CollectionOf = protocol where Collection.Element == T

and if my intuition 

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

[L. Mihalkovic via swift-evolution]

> On May 15, 2016, at 9:17 AM, David Hart  wrote:
> 
> Hi Karl,
> 
> As author of this proposal, the one about constraints on associated types, 
> and the one on type-aliases in protocols (all from the Generics Manifesto - 
> original authorship to Douglas Gregor) I’d like to provide additional 
> reasoning behind my wish to push this proposal through, as a whole.
> 
> First of all, there is a personal preference. I’ve used C# for many many 
> years, which has its where clause at the end of the declaration (like this 
> proposal), and I’ve used Swift since its unveiling. The experience with using 
> both styles for several years makes me favour this proposal’s syntax because 
> I find it much easier to read and format for readability.
> 
> Constraints on associated type will provide more expressivity but I doubt it 
> will greatly reduce protocol constraint clauses in a majority of cases. And 
> yes, type-aliases in protocols will shorten clauses, but I still think they 
> will more readable with the where clause at the end.
> 
> For example, here is a method I took (as-is) from the Standard Library which 
> has a few constraints, and which I further simplified if we imagine that 
> Sequence has an Element typealias for Iterator.Element:
> 
> 
> internal func _arrayOutOfPlaceReplace<
>   B : _ArrayBufferProtocol, C : Collection
>   where
>   C.Element == B.Element,
>   B.Index == Int
> >(
>   _ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int
> ) {
> 
> See how the Standard Library authors formatted it for readability and how as 
> a consequence arguments which use the generic types are further apart from 
> the declaration of those generic types. But with this proposal, the 
> declaration might be formatted to:
> 
> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
> Range, _ newValues: C, _ insertCount: Int) where
>   B : _ArrayBufferProtocol,
>   C : Collection,
>   C.Iterator.Element == B.Element,
>   B.Index == Int
> {

Reading this example reinforces my initial sense that while WHERE works well 
when the information is inlined, I would have preferred WITH in the case where 
the information is at the end. go figure...


> 
> Do you need believe this is now more readable?
> 
> David.
> 
>> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution 
>>  wrote:
>> 
>> 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 > C.Element==String>, 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.
> 
___
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

[David Hart via swift-evolution]

Hi Karl,

As author of this proposal, the one about constraints on associated types, and 
the one on type-aliases in protocols (all from the Generics Manifesto - 
original authorship to Douglas Gregor) I’d like to provide additional reasoning 
behind my wish to push this proposal through, as a whole.

First of all, there is a personal preference. I’ve used C# for many many years, 
which has its where clause at the end of the declaration (like this proposal), 
and I’ve used Swift since its unveiling. The experience with using both styles 
for several years makes me favour this proposal’s syntax because I find it much 
easier to read and format for readability.

Constraints on associated type will provide more expressivity but I doubt it 
will greatly reduce protocol constraint clauses in a majority of cases. And 
yes, type-aliases in protocols will shorten clauses, but I still think they 
will more readable with the where clause at the end.

For example, here is a method I took (as-is) from the Standard Library which 
has a few constraints, and which I further simplified if we imagine that 
Sequence has an Element typealias for Iterator.Element:


internal func _arrayOutOfPlaceReplace<
  B : _ArrayBufferProtocol, C : Collection
  where
  C.Element == B.Element,
  B.Index == Int
>(
  _ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int
) {

See how the Standard Library authors formatted it for readability and how as a 
consequence arguments which use the generic types are further apart from the 
declaration of those generic types. But with this proposal, the declaration 
might be formatted to:

internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
Range, _ newValues: C, _ insertCount: Int) where
  B : _ArrayBufferProtocol,
  C : Collection,
  C.Iterator.Element == B.Element,
  B.Index == Int
{

Do you need believe this is now more readable?

David.

> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution 
>  wrote:
> 
> 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  C.Element==String>, 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.

___
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 

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] [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] [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] [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] [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] [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-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] [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

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

[Jon Shier via swift-evolution]

> * 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

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

[Brent Royal-Gordon via swift-evolution]

> I’m a +1, however personally I’d prefer this to be optional my constraints 
> aren’t that complex, for example:
> 
>   func someMethod(value:T) { … }
> 
> Personally I prefer to keep such simple cases as they are, but would happily 
> use the new ability to move more complex ones (e.g- dealing with 
> Generator.Element and multiple constraints) to the end as proposed.

The example you give isn't actually a legal constraint. (The legal version 
would be much longer—you'd need to conform `T` to `Sequence` or `Collection` 
and test `T.Iterator.Element`, or their Swift 2 equivalents.) Can you provide a 
more realistic example where you think moving the `where` clause to the end of 
the declaration is overkill? I've generally found that most where clauses are 
mind-numbingly long.

-- 
Brent Royal-Gordon
Architechies

___
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 10 May 2016, at 19:51, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

I’m a +1, however personally I’d prefer this to be optional my constraints 
aren’t that complex, for example:

func someMethod(value:T) { … }

Personally I prefer to keep such simple cases as they are, but would happily 
use the new ability to move more complex ones (e.g- dealing with 
Generator.Element and multiple constraints) to the end as proposed.

So I’m +1, but I don’t think it should be one or the other, I’d prefer to have 
both options, with a recommendation that trailing constraints be used in 
complex cases for clarity.

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

Generic constraints are one of the most powerful, and daunting, features of 
Swift, so anything that makes them a bit neater and keeps function signatures 
tidy is an improvement. Of course there’s a lot more that can be done to 
simplify generic constraints further, but given the simple elegance of this 
improvement it easily justifies inclusion.

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

I’d say yes, since the feature itself is unchanged and already part of Swift, 
it’s just the location that is being moved.

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

Quick read through, which is plenty since the proposal is fairly 
straightforward, I’ve also been following the discussion for a while.___
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

[Thorsten Seitz via swift-evolution]

> Am 10.05.2016 um 20:51 schrieb Chris Lattner via swift-evolution 
> :
> 
> 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
> 
> 
>   * What is your evaluation of the proposal?

+1

It increases readability of generics by a far margin.
I appreciate that the proposal allows to pull out the inheritance/conformance 
constraints into the where clause, too, very much!


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

Yes, as more complex generics are a powerful feature of Swift and the increased 
readability helps designing and using them very much.


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

Absolutely.


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

Ceylon uses a similar syntax to declare the constraints of generic parameters:
shared interface DirectedGraph satisfies IncidenceGraph
  given V satisfies Object
  given E satisfies DirectedEdge { … }
I always found this very readable but with Swift’s ability to declare 
constraints between associated types of generic parameters this is even more 
important.


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

Read the proposal carefully and followed the discussion.

-Thorsten

___
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

[Joe Groff via swift-evolution]

> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
>> 
>>> 
>>> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
>>> :
>>> 
>>> 
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it 
> won’t be hard to put something before it, and it seems unlikely to me 
> that we would want to add anything after it without some other delimiter. 
> So I’m not too concerned.
 
 Yeah, that’s my feeling as well.
>>> 
>>> One conceivable use of `where` that this would shut the door on: infix 
>>> `where` for generalized existentials, e.g. `Protocol where AssociatedType 
>>> == Int` could be the Protocol existential with Self.AssociatedType 
>>> constrained to Int.
>> 
>> Why do you think that?
> 
> This proposal moves `where` after the return type, which would be ambiguous 
> with any infix use of `where` in the type grammar.

To be clear, I'm not saying we *should* add infix `where` to the type grammar, 
only pointing out that this would prevent its use in the future.

-Joe
___
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

[Krzysztof Siejkowski via swift-evolution]

* What is your evaluation of the proposal?
+1

More readable.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes. Current form of defining requirements makes deciphering the signatures 
with high number of requirements a logical riddle.



* Does this proposal fit well with the feel and direction of Swift?
I do think so. It’ll further encourage the use of generics, which I see as one 
of the cornerstones of Swift.



* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Not that I can think of, but now I’d like to see similar change in Scala :)



* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I’ve read proposal and corresponding discussion.



All the best,

Krzysztof___
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

[Thorsten Seitz via swift-evolution]

> Am 11.05.2016 um 19:23 schrieb Joe Groff :
> 
> 
>>> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
>>> 
>>> 
>>> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
>>> :
>>> 
>>> 
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it 
> won’t be hard to put something before it, and it seems unlikely to me 
> that we would want to add anything after it without some other delimiter. 
> So I’m not too concerned.
 
 Yeah, that’s my feeling as well.
>>> 
>>> One conceivable use of `where` that this would shut the door on: infix 
>>> `where` for generalized existentials, e.g. `Protocol where AssociatedType 
>>> == Int` could be the Protocol existential with Self.AssociatedType 
>>> constrained to Int.
>> 
>> Why do you think that?
> 
> This proposal moves `where` after the return type, which would be ambiguous 
> with any infix use of `where` in the type grammar.

Ah, I see. But wouldn't this already be a problem with the current syntax as 
well, because the `where` might come after a constraining type which might be 
an existential?

As an alternative to `where` we could use `with` for existentials.

-Thorsten 
___
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

[Austin Zheng via swift-evolution]

Another idea: what about a comma separating the return type from the where
clause?

func myFunc(arg1: A, arg2: B) -> Bool, where A :
CustomStringConvertible { ... }

Best,
Austin

On Wed, May 11, 2016 at 1:56 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> How about a more radical change that eliminates this entire concern and
> keeps the whole generics declarations in one place:
>
> Move the entire generic declaration with its brackets somewhere other than
> between function name and its parameters.
>
> I know this breaks the “norm”, but what do you think?
>
>
> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
>
>
> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution <
> swift-evolution@swift.org>:
>
>
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think actual keyword “where” provides enough of a delimiter that it
> won’t be hard to put something before it, and it seems unlikely to me that
> we would want to add anything after it without some other delimiter. So I’m
> not too concerned.
>
>
> Yeah, that’s my feeling as well.
>
>
> One conceivable use of `where` that this would shut the door on: infix
> `where` for generalized existentials, e.g. `Protocol where AssociatedType
> == Int` could be the Protocol existential with Self.AssociatedType
> constrained to Int.
>
>
> Why do you think that?
>
>
> This proposal moves `where` after the return type, which would be
> ambiguous with any infix use of `where` in the type grammar.
>
> -Joe
> ___
> 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] [Review] SE-0081: Move where clause to end of declaration

[Hooman Mehr via swift-evolution]

How about a more radical change that eliminates this entire concern and keeps 
the whole generics declarations in one place: 

Move the entire generic declaration with its brackets somewhere other than 
between function name and its parameters.

I know this breaks the “norm”, but what do you think?

> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
>> 
>>> 
>>> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
>>> :
>>> 
>>> 
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it 
> won’t be hard to put something before it, and it seems unlikely to me 
> that we would want to add anything after it without some other delimiter. 
> So I’m not too concerned.
 
 Yeah, that’s my feeling as well.
>>> 
>>> One conceivable use of `where` that this would shut the door on: infix 
>>> `where` for generalized existentials, e.g. `Protocol where AssociatedType 
>>> == Int` could be the Protocol existential with Self.AssociatedType 
>>> constrained to Int.
>> 
>> Why do you think that?
> 
> This proposal moves `where` after the return type, which would be ambiguous 
> with any infix use of `where` in the type grammar.
> 
> -Joe
> ___
> 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

[Joe Groff via swift-evolution]

> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
> 
>> 
>> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
>> :
>> 
>> 
 On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 
 On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
  wrote:
 
 I think actual keyword “where” provides enough of a delimiter that it 
 won’t be hard to put something before it, and it seems unlikely to me that 
 we would want to add anything after it without some other delimiter. So 
 I’m not too concerned.
>>> 
>>> Yeah, that’s my feeling as well.
>> 
>> One conceivable use of `where` that this would shut the door on: infix 
>> `where` for generalized existentials, e.g. `Protocol where AssociatedType == 
>> Int` could be the Protocol existential with Self.AssociatedType constrained 
>> to Int.
> 
> Why do you think that?

This proposal moves `where` after the return type, which would be ambiguous 
with any infix use of `where` in the type grammar.

-Joe
___
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

[Thorsten Seitz via swift-evolution]

> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
> :
> 
> 
>>> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> I think actual keyword “where” provides enough of a delimiter that it won’t 
>>> be hard to put something before it, and it seems unlikely to me that we 
>>> would want to add anything after it without some other delimiter. So I’m 
>>> not too concerned.
>> 
>> Yeah, that’s my feeling as well.
> 
> One conceivable use of `where` that this would shut the door on: infix 
> `where` for generalized existentials, e.g. `Protocol where AssociatedType == 
> Int` could be the Protocol existential with Self.AssociatedType constrained 
> to Int.

Why do you think that?

-Thorsten 
___
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

[Matt Whiteside via swift-evolution]

+1, I like this one a lot.

-Matt

> On May 10, 2016, at 21:25, David Waite via swift-evolution 
>  wrote:
> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>> 
>>  * What is your evaluation of the proposal?
> +1, I like the syntax and think it can clean up some parser ambiguities.
> 
> 
> Today, there are several formats using angle brackets:
> - a parameter declaration as an ordered dictionary of names to type or 
> type-decensent restrictions (or Any if not specified)
> - an argument declaration as an ordered list of concrete types
> - an unordered list of required protocol conformances
> 
> Eliminating the where clause sometimes available in parameter declarations 
> simplifies understanding the generic syntaxes.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> Yes
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, although I don’t know how it evaluates against possible future syntax 
> for the generics manifesto feature lists
> 
>>  * 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?
> Followed discussion
> 
> -DW
> ___
> 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

[David Waite via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
> 
>   * What is your evaluation of the proposal?
+1, I like the syntax and think it can clean up some parser ambiguities.


Today, there are several formats using angle brackets:
- a parameter declaration as an ordered dictionary of names to type or 
type-decensent restrictions (or Any if not specified)
- an argument declaration as an ordered list of concrete types
- an unordered list of required protocol conformances

Eliminating the where clause sometimes available in parameter declarations 
simplifies understanding the generic syntaxes.

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

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

Yes, although I don’t know how it evaluates against possible future syntax for 
the generics manifesto feature lists

>   * 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?
Followed discussion

-DW
___
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

[Joe Groff via swift-evolution]

> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> I think actual keyword “where” provides enough of a delimiter that it won’t 
>> be hard to put something before it, and it seems unlikely to me that we 
>> would want to add anything after it without some other delimiter. So I’m not 
>> too concerned.
> 
> Yeah, that’s my feeling as well.

One conceivable use of `where` that this would shut the door on: infix `where` 
for generalized existentials, e.g. `Protocol where AssociatedType == Int` could 
be the Protocol existential with Self.AssociatedType constrained to Int.

-Joe
___
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

[Muse M via swift-evolution]

** What is your evaluation of the proposal?*
A novelty idea

** Is the problem being addressed significant enough to warrant a change to
Swift?*
Some programmers love compact code and make Swift no difference to other
languages, change is indeed easier and almost no barrier for all level of
readers.

** Does this proposal fit well with the feel and direction of Swift?*
It makes presentation slide and teaching readability and avoid information
overload when dealing large scale projects.

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


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


On Wed, May 11, 2016 at 7:19 AM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think actual keyword “where” provides enough of a delimiter that it
> won’t be hard to put something before it, and it seems unlikely to me that
> we would want to add anything *after* it without some *other* delimiter.
> So I’m not too concerned.
>
>
> Yeah, that’s my feeling as well.
>
> - Doug
>
>
> Jordan
>
> On May 10, 2016, at 14:29, Hooman Mehr via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Although handy for now, I am a bit concerned about moving `where` clause
> to the end of declaration. This reserves and occupies this wide open space
> at the end of declarations. I think we might find a better use for this
> space later as the language evolves. Any thoughts?
>
> On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> 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:
>
> * 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
>
>
> ___
> 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] [Review] SE-0081: Move where clause to end of declaration

[Douglas Gregor via swift-evolution]

> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it won’t 
> be hard to put something before it, and it seems unlikely to me that we would 
> want to add anything after it without some other delimiter. So I’m not too 
> concerned.

Yeah, that’s my feeling as well.

- Doug

> 
> Jordan
> 
>> On May 10, 2016, at 14:29, Hooman Mehr via swift-evolution 
>> > wrote:
>> 
>> Although handy for now, I am a bit concerned about moving `where` clause to 
>> the end of declaration. This reserves and occupies this wide open space at 
>> the end of declarations. I think we might find a better use for this space 
>> later as the language evolves. Any thoughts?
>> 
>>> On May 10, 2016, at 11:51 AM, 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:
>>> 
>>> * 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 
>> 
> ___
> 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

[Jordan Rose via swift-evolution]

I think actual keyword “where” provides enough of a delimiter that it won’t be 
hard to put something before it, and it seems unlikely to me that we would want 
to add anything after it without some other delimiter. So I’m not too concerned.

Jordan

> On May 10, 2016, at 14:29, Hooman Mehr via swift-evolution 
>  wrote:
> 
> Although handy for now, I am a bit concerned about moving `where` clause to 
> the end of declaration. This reserves and occupies this wide open space at 
> the end of declarations. I think we might find a better use for this space 
> later as the language evolves. Any thoughts?
> 
>> On May 10, 2016, at 11:51 AM, 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:
>> 
>>  * 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 
> 
___
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

[Hooman Mehr via swift-evolution]

Although handy for now, I am a bit concerned about moving `where` clause to the 
end of declaration. This reserves and occupies this wide open space at the end 
of declarations. I think we might find a better use for this space later as the 
language evolves. Any thoughts?
 
> On May 10, 2016, at 11:51 AM, 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:
> 
>   * 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] [Review] SE-0081: Move where clause to end of declaration

[Brandon Knope via swift-evolution]

What is your evaluation of the proposal?
A big +1

Is the problem being addressed significant enough to warrant a change to Swift?
Yes. This makes it much more natural to read methods and functions with 
generics. This also makes it more predictable to find where the method 
signature is without having to weed through a bunch of generic constraints.

Does this proposal fit well with the feel and direction of Swift?
Most definitely. Feels more natural and consistent with other uses of `where`

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

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve followed the evo thread since the beginning___
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

[Trent Nadeau via swift-evolution]

   - What is your evaluation of the proposal?
   - All the +1s. This is more consistent with `where` clauses elsewhere in
  the language and is much more readable.
   - Is the problem being addressed significant enough to warrant a change
   to Swift?
   - Yes.
   - Does this proposal fit well with the feel and direction of Swift?
   - Yes. Consistent and readability have been very important with Swift so
  far.
   - If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
   - Rust is similar.
   - 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 discussions.


On Tue, May 10, 2016 at 2:51 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> 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:
>
> * 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
>



-- 
Trent Nadeau
___
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

[Erica Sadun via swift-evolution]

Yes please.

It is significant enough to warrant a change to Swift. 
http://ericasadun.com/2016/04/06/folding-generic-argument-lists/ 

It fits with the feel and direction of Swift. It makes Swift easier to format, 
read, and maintain. I particularly like that the type arguments are declared 
and used first, then constrained later. It feels like a more natural placement.
I have incited discussion on this, followed it from the start, and have been an 
excited cheerleader along the way.

-- E

> On May 10, 2016, at 12:51 PM, 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:
> 
>   * 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] [Review] SE-0081: Move where clause to end of declaration

[T.J. Usiyan via swift-evolution]

   * What is your evaluation of the proposal?
+1
* Is the problem being addressed significant enough to warrant a
change to Swift?
yes
* Does this proposal fit well with the feel and direction of Swift?
yes
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
It is on par with constraint declarations/relations in other languages
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
quick reading but I have been following the discussions that this came out
of.

On Tue, May 10, 2016 at 2:42 PM, Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> 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:
> >
> >   * What is your evaluation of the proposal?
> +1 much much readable
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
> yes
> >   * Does this proposal fit well with the feel and direction of Swift?
> yes
> >   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> n/a
> >   * 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 email chain
> >
> > 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
>
___
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

[Jose Cheyo Jimenez via swift-evolution]

> On May 10, 2016, at 11:51 AM, 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:
> 
>   * What is your evaluation of the proposal?
+1 much much readable
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
yes
>   * Does this proposal fit well with the feel and direction of Swift?
yes
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
n/a
>   * 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 email chain
> 
> 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