Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Erica Sadun via swift-evolution]

This is one of those where I keep hoping someone will pick it up and get the 
proposal out there.

-- E

> On Apr 29, 2016, at 8:57 AM, David Hart via swift-evolution 
>  wrote:
> 
> What’s up with this great idea? Can’t see a proposal on swift-evolution 
> anywhere.
> 
>> On 08 Apr 2016, at 08:15, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>>>  wrote:
>>> 
>>> If you've ever gotten to the point where you have a sufficiently generic 
>>> interface to a thing and you need to constrain it, possibly in an 
>>> extension, maybe for a generic free function or operator, you know what a 
>>> pain the syntax can be for these kinds of operations.  For example, the 
>>> Swift book implements this example to motivate where clauses
>>> 
>>> func anyCommonElements >> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>>> (lhs: T, _ rhs: U) -> Bool
>>> 
>>> This is noisy and uncomfortable to my eyes, and almost impossible to align 
>>> correctly.  Per a short discussion on Twitter with Joe Groff and Erica 
>>> Sadun, I'd like so see what the community feels about moving the where 
>>> clause out of the angle brackets.  So that example becomes
>>> 
>>> func anyCommonElements 
>>> where T.Generator.Element: Equatable, T.Generator.Element == 
>>> U.Generator.Element
>>> (lhs: T, _ rhs: U) -> Bool
>>> 
>>> Or, if you're feeling ambitious, even
>>> 
>>> func anyCommonElements 
>>> where T : SequenceType, U : SequenceType,
>>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>>> (lhs: T, _ rhs: U) -> Bool
>>> 
>>> Thoughts?
>> 
>> +1, long overdue.  Please keep basic constraints (ones expressible without a 
>> ‘where’ clause, like simple conformances) inline though.
>> 
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[David Hart via swift-evolution]

What’s up with this great idea? Can’t see a proposal on swift-evolution 
anywhere.

> On 08 Apr 2016, at 08:15, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>>  wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.  For example, the Swift book 
>> implements this example to motivate where clauses
>> 
>> func anyCommonElements > T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> This is noisy and uncomfortable to my eyes, and almost impossible to align 
>> correctly.  Per a short discussion on Twitter with Joe Groff and Erica 
>> Sadun, I'd like so see what the community feels about moving the where 
>> clause out of the angle brackets.  So that example becomes
>> 
>> func anyCommonElements 
>> where T.Generator.Element: Equatable, T.Generator.Element == 
>> U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Thoughts?
> 
> +1, long overdue.  Please keep basic constraints (ones expressible without a 
> ‘where’ clause, like simple conformances) inline though.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Maximilian Hünenberger via swift-evolution]

+1 I almost fully agree with all your points. However I disagree with your 
first point:

What do you mean by: "I think it's more natural to restrict generic type 
parameters to the immediate local scope"

To me it feels like an "associated type" so it should be almost equally exposed 
in comparison to "associatedtype" of a protocol

Kind regards
- Maximilian

> Am 07.04.2016 um 10:44 schrieb Pyry Jahkola via swift-evolution 
> :
> 
> Jordan,
> 
> Your comments brought up a few more closely related ideas that have been 
> bubbling under.
> 
> To everyone,
> 
> Sorry for going beyond topic here. The discussion of the further proposals 
> below should be taken into their own threads if there's interest. I'm just 
> trying to motivate what else moving out the `where` clause would make 
> possible.
> 
> 1. My counter-proposal against making generic parameters public
> 
>> Another factor here is that we've been planning for a while for generic 
>> parameters to types to be exposed as implicit member typealiases, since they 
>> already conflict with the namespace for member typealiases. Therefore it's 
>> important to name generic parameters to types well, but less important to do 
>> so for generic parameters for functions. (They're also much less likely to 
>> be ad hoc for types; there has to be something that describes the relation 
>> between the Self type and the parameter, while the function might not have 
>> anything more interesting than "operand".)
> 
> I disagree with that. I think it's more natural to restrict generic type 
> parameters to the immediate local scope of the class/struct/enum definition 
> or extension, and simply allow making the type public with `typealias`. For 
> example, this would make `Element` a public member of `Array`:
> 
> public enum Result {
> public typealias Value = T // This makes `Value` public for 
> extensions and everyone
> }
> 
> I would even allow publishing the otherwise local name by repeating it in 
> `typealias` like this:
> 
> public struct Array { // This `Element` is only available in 
> (the missing) where clause and the scope below.
> public typealias Element = Element // This line makes `Element` 
> available everywhere, see below.
> }
> 
> extension Array { // <- Regardless of the pattern (`T`) used here,
> var mid: Element? { // the type `Element = T` is available here
> return ...  // because it was made public elsewhere.
> }
> }
> extension Array> { // <- An example of pattern matching (see 
> further below).
> // Ditto, `Element = T?`
> }
> 
> typealias Ints = [Int]
> let x: Ints.Element = ... // Int
> 
> Next, I propose how to extend this syntax with pattern matching. The above 
> thinking is a natural progression from the use of pattern matching for 
> introducing generic type parameters in type `extension`s.
> 
> 
> 2. Proposal to enable pattern matching of generic types in generic parameters
> 
>> This is also a minor point against declaring generic parameters for 
>> extensions, since they would have to match up. We also do need a syntax some 
>> day to represent new parameters:
>> 
>> // For expository purposes only:
>> extension  Array where Element == Optional
>> 
>> But that deserves its own proposal. I just don't want us to paint ourselves 
>> into a corner.
> 
> I agree that we need that feature. But instead of your proposed syntax, I'd 
> take influence from the already existing pattern matching that we have at 
> value level, such that:
> 
> 1. any generic type expressions within the angle brackets `<...>` are taken 
> as patterns to match against  (e.g. `Array`, `Optional`, 
> `Dictionary`), and
> 2. all non-generic type identifiers in those expressions are taken as generic 
> parameters and not concrete types (`Element`, `Foo`, or `S`, respectively).
> 
> Your example would translate into the first of these two:
> 
> extension Array> { // extending [T?] doesn't even need any 
> `where` clause
> func unwrapAll() -> [T] { ... }
> }
> 
> extension Dictionary> { // This pattern match 
> requires the same `K` twice.
> subscript(x: K, y: K) -> V { ... }
> }
> 
> The generic parameters would shadow any existing names in the outer scope, 
> i.e. `extension Array` would mean the same as `extension 
> Array`. But it would be a good idea to add a warning (or linter 
> error) at least when stdlib types such as `Swift.String` are shadowed like 
> that. I think the benefits from pattern matching outweigh the possible 
> confusion, especially since you can't use any members of `String` if you 
> mistakenly wrote `extension Array { ... }` instead of `extension 
> Array where T == String`.
> 
> With this syntax, we could also allow extending Array, Dictionary, and 
> Optional in their more natural notation:
> 
> extension [T?] {
> func unwrapAll() -> [T] { /* ... */ }
> }
> 
> extension [K: [K: V]] {
>

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Matt Whiteside via swift-evolution]

> On Apr 6, 2016, at 17:13, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Another nice thing about this style is that, in principle, I think it could 
> be extended to specify requirements on non-type parameter values.

I had this thought too.  The possibilities that this syntax change suggests for 
compile time evaluation are very interesting, in my opinion.

-Matt

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Chris Lattner via swift-evolution]

> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?

+1, long overdue.  Please keep basic constraints (ones expressible without a 
‘where’ clause, like simple conformances) inline though.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Brandon Knope via swift-evolution]

Because I am a mailing list noob, my email wasn't CC'd to all. So here we go 
again:

Big +1 from me. 

I expected not to like this syntax but I believe it makes it far clearer. It 
always felt backwards to me to have to come up with all the constraints before 
the function signature. Maybe this is moot because you should already know what 
the function should look like before writing. But we are all human and things 
may change as we are writing it, resulting in a constant going back and forth 
from the signature to the constraints. 

It reads much more naturally (and I think it's easier to write) when the where 
clause is after the signature because you have to look *back* to the parameters 
in the function instead of looking forward. And when having to look forward, 
you have to parse a possibly long list of constraints before even finding the 
signature. Repeat this possibly for each constraint and there is some mental 
overload there. 

With the where at the end, you've already read the function signature and the 
signature is in a known easy to find place when looking back at it. 

So in summary:
- it reads more naturally
- more comfortable on the eyes
- easier to find the function signature when looking back after reading the 
constraints 

This all leads to less mental overload IMO

Brandon 

> On Apr 6, 2016, at 2:37 PM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution 
>  wrote:
>>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>>>  wrote:
>> 
>>> 
>>> If you've ever gotten to the point where you have a sufficiently generic 
>>> interface to a thing and you need to constrain it, possibly in an 
>>> extension, maybe for a generic free function or operator, you know what a 
>>> pain the syntax can be for these kinds of operations.
>> 
>> +1 already!
>> 
>>> Or, if you're feeling ambitious, even
>>> 
>>> func anyCommonElements 
>>> where T : SequenceType, U : SequenceType,
>>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>>> (lhs: T, _ rhs: U) -> Bool
>> 
>> 
>> I would actually move them as far as after everything else, and right before 
>> the definition body. For the above function that would mean:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
>> That would make the definition look closer to what the call site looks like.
>> 
>> The same would work for generic types  too:
>> 
>> public struct Dictionary
>> where Key : Hashable
>> {
>>...
>> }
> 
> I very much like this suggestion. 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

These are fantastic proposals! With these in place, there would be precious 
little to envy Haskell. 

For example, regarding “counter-proposal against making generic parameters 
public”, the current behaviour of Swift is essentially a bug, as reported by 
Noah Blake (https://bugs.swift.org/browse/SR-1065 
).

Then there is:

> (3) Using variadic patterns (shamefully borrowing the `...` notation from C++ 
> here to mean an arbitrary-length list of patterns to match or expressions to 
> expand):
> 
> extension (T...) : Equatable where T : Equatable... {}
> 
> func == (lhs: (T...), rhs: (T...)) -> Bool where T : Equatable... { 
> /* ... */ }


Not only that this would make certain Standard Library signatures less 
embarrassing, but would enable entirely new programming patterns. For example, 
the size of a fixed-length sequence could be type guaranteed like so:

let v = Vector<_2,_0,_1,_6>(repeatedValue: 42)
v.count // 2016

… wehere types like _2 and _6 may be caseless enums:

enum _2 : DecimalDigitType { }

milos

> On 7 Apr 2016, at 09:44, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Jordan,
> 
> Your comments brought up a few more closely related ideas that have been 
> bubbling under.
> 
> To everyone,
> 
> Sorry for going beyond topic here. The discussion of the further proposals 
> below should be taken into their own threads if there's interest. I'm just 
> trying to motivate what else moving out the `where` clause would make 
> possible.
> 
> 1. My counter-proposal against making generic parameters public
> 
>> Another factor here is that we've been planning for a while for generic 
>> parameters to types to be exposed as implicit member typealiases, since they 
>> already conflict with the namespace for member typealiases. Therefore it's 
>> important to name generic parameters to types well, but less important to do 
>> so for generic parameters for functions. (They're also much less likely to 
>> be ad hoc for types; there has to be something that describes the relation 
>> between the Self type and the parameter, while the function might not have 
>> anything more interesting than "operand".)
> 
> I disagree with that. I think it's more natural to restrict generic type 
> parameters to the immediate local scope of the class/struct/enum definition 
> or extension, and simply allow making the type public with `typealias`. For 
> example, this would make `Element` a public member of `Array`:
> 
> public enum Result {
> public typealias Value = T // This makes `Value` public for 
> extensions and everyone
> }
> 
> I would even allow publishing the otherwise local name by repeating it in 
> `typealias` like this:
> 
> public struct Array { // This `Element` is only available in 
> (the missing) where clause and the scope below.
> public typealias Element = Element // This line makes `Element` 
> available everywhere, see below.
> }
> 
> extension Array { // <- Regardless of the pattern (`T`) used here,
> var mid: Element? { // the type `Element = T` is available here
> return ...  // because it was made public elsewhere.
> }
> }
> extension Array> { // <- An example of pattern matching (see 
> further below).
> // Ditto, `Element = T?`
> }
> 
> typealias Ints = [Int]
> let x: Ints.Element = ... // Int
> 
> Next, I propose how to extend this syntax with pattern matching. The above 
> thinking is a natural progression from the use of pattern matching for 
> introducing generic type parameters in type `extension`s.
> 
> 
> 2. Proposal to enable pattern matching of generic types in generic parameters
> 
>> This is also a minor point against declaring generic parameters for 
>> extensions, since they would have to match up. We also do need a syntax some 
>> day to represent new parameters:
>> 
>> // For expository purposes only:
>> extension  Array where Element == Optional
>> 
>> But that deserves its own proposal. I just don't want us to paint ourselves 
>> into a corner.
> 
> I agree that we need that feature. But instead of your proposed syntax, I'd 
> take influence from the already existing pattern matching that we have at 
> value level, such that:
> 
> 1. any generic type expressions within the angle brackets `<...>` are taken 
> as patterns to match against  (e.g. `Array`, `Optional`, 
> `Dictionary`), and
> 2. all non-generic type identifiers in those expressions are taken as generic 
> parameters and not concrete types (`Element`, `Foo`, or `S`, respectively).
> 
> Your example would translate into the first of these two:
> 
> extension Array> { // extending [T?] doesn't even need any 
> `where` clause
> func unwrapAll() -> [T] { ... }
> }
> 
> extension Dictionary> { // This pattern match 
> requires the same `K` twice.
> subscript(x: K, y: K) -> V { ... }
> }
> 
> The generic parameters would shadow any e

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Haravikk via swift-evolution]

I quite like this variation, so I’m a +1 for that.

However, I think this would be greatly helped if we could define protocol 
generics more like type generics like so:

protocol Foo { … }
func anyStringFoo(lhs:Foo) { … }

But yeah, for the more complicated cases, it makes a lot of sense to relocate 
the where clause away from the main signature. I’d maybe still allow 
declarations of type though like-so:

func anyCommonElements(lhs:T, _ rhs:U) 
-> Bool
where T.Generator.Element:Equatable, T.Generator.Element == 
U.Generator.Element

Perhaps allowing us the choice of doing it this way at least.

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> — 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

Jordan,

Your comments brought up a few more closely related ideas that have been 
bubbling under.

To everyone,

Sorry for going beyond topic here. The discussion of the further proposals 
below should be taken into their own threads if there's interest. I'm just 
trying to motivate what else moving out the `where` clause would make possible.

1. My counter-proposal against making generic parameters public

> Another factor here is that we've been planning for a while for generic 
> parameters to types to be exposed as implicit member typealiases, since they 
> already conflict with the namespace for member typealiases. Therefore it's 
> important to name generic parameters to types well, but less important to do 
> so for generic parameters for functions. (They're also much less likely to be 
> ad hoc for types; there has to be something that describes the relation 
> between the Self type and the parameter, while the function might not have 
> anything more interesting than "operand".)

I disagree with that. I think it's more natural to restrict generic type 
parameters to the immediate local scope of the class/struct/enum definition or 
extension, and simply allow making the type public with `typealias`. For 
example, this would make `Element` a public member of `Array`:

public enum Result {
public typealias Value = T // This makes `Value` public for extensions 
and everyone
}

I would even allow publishing the otherwise local name by repeating it in 
`typealias` like this:

public struct Array { // This `Element` is only available in (the 
missing) where clause and the scope below.
public typealias Element = Element // This line makes `Element` 
available everywhere, see below.
}

extension Array { // <- Regardless of the pattern (`T`) used here,
var mid: Element? { // the type `Element = T` is available here
return ...  // because it was made public elsewhere.
}
}
extension Array> { // <- An example of pattern matching (see 
further below).
// Ditto, `Element = T?`
}

typealias Ints = [Int]
let x: Ints.Element = ... // Int

Next, I propose how to extend this syntax with pattern matching. The above 
thinking is a natural progression from the use of pattern matching for 
introducing generic type parameters in type `extension`s.


2. Proposal to enable pattern matching of generic types in generic parameters

> This is also a minor point against declaring generic parameters for 
> extensions, since they would have to match up. We also do need a syntax some 
> day to represent new parameters:
> 
> // For expository purposes only:
> extension  Array where Element == Optional
> 
> But that deserves its own proposal. I just don't want us to paint ourselves 
> into a corner.

I agree that we need that feature. But instead of your proposed syntax, I'd 
take influence from the already existing pattern matching that we have at value 
level, such that:

1. any generic type expressions within the angle brackets `<...>` are taken as 
patterns to match against  (e.g. `Array`, `Optional`, 
`Dictionary`), and
2. all non-generic type identifiers in those expressions are taken as generic 
parameters and not concrete types (`Element`, `Foo`, or `S`, respectively).

Your example would translate into the first of these two:

extension Array> { // extending [T?] doesn't even need any 
`where` clause
func unwrapAll() -> [T] { ... }
}

extension Dictionary> { // This pattern match requires 
the same `K` twice.
subscript(x: K, y: K) -> V { ... }
}

The generic parameters would shadow any existing names in the outer scope, i.e. 
`extension Array` would mean the same as `extension Array`. 
But it would be a good idea to add a warning (or linter error) at least when 
stdlib types such as `Swift.String` are shadowed like that. I think the 
benefits from pattern matching outweigh the possible confusion, especially 
since you can't use any members of `String` if you mistakenly wrote `extension 
Array { ... }` instead of `extension Array where T == String`.

With this syntax, we could also allow extending Array, Dictionary, and Optional 
in their more natural notation:

extension [T?] {
func unwrapAll() -> [T] { /* ... */ }
}

extension [K: [K: V]] {
subscript(x: K, y: K) -> V { /* ... */ }
}

Here are a few more (somewhat realistically needed) examples with further 
`where` clauses:

extension [T] where T : Hashable { /* ... */ }
extension T? where T : Comparable { /* ... */ }
extension [K: V] where V : Equatable { /* ... */ }
extension [T] where T == String { /* ... */ }

I think pattern matching is a very expressive, intuitive, and readable 
technique that works quite well for this purpose, better than what we currently 
have.


3. Future directions

Brent already pointed out that the `where` constraint syntax could be used for 
dependent types (i.e. type-l

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Brent Royal-Gordon via swift-evolution]

> I know you're not proposing that feature right now, but want to understand 
> how you expect it to work.  It looks to me like this starts to enter design 
> by contract territory.  Would the predicate behave as if it was part of a 
> precondition?

I suppose I imagine it as equivalent to a precondition() placed at the call 
site, rather than inside the function. If the compiler can prove that the 
precondition will be violated, it can refuse to compile the call. But I haven't 
thought deeply about it, so I don't really know for sure.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Trent Nadeau via swift-evolution]

Another +1 to `where` at the end.

On Wed, Apr 6, 2016 at 10:33 PM, Matt Whiteside via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 to moving the `where` clause after the function signature.
>
> -Matt
>
> > On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> If you've ever gotten to the point where you have a sufficiently
> generic interface to a thing and you need to constrain it, possibly in an
> extension, maybe for a generic free function or operator, you know what a
> pain the syntax can be for these kinds of operations.  For example, the
> Swift book implements this example to motivate where clauses
> >>
> >> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element>
> (lhs: T, _ rhs: U) -> Bool
> >>
> >> This is noisy and uncomfortable to my eyes, and almost impossible to
> align correctly.  Per a short discussion on Twitter with Joe Groff and
> Erica Sadun, I'd like so see what the community feels about moving the
> where clause out of the angle brackets.  So that example becomes
> >>
> >> func anyCommonElements 
> >> where T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element
> >> (lhs: T, _ rhs: U) -> Bool
> >>
> >> Or, if you're feeling ambitious, even
> >>
> >> func anyCommonElements 
> >> where T : SequenceType, U : SequenceType,
> >> T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element
> >> (lhs: T, _ rhs: U) -> Bool
> >>
> >> Thoughts?
> >
> > I think this is a good idea, though I would put the `where` clause after
> the function signature:
> >
> > func foo(x: T, y: U) -> Result
> >where T.Foo == U.Bar /*, etc. */
> > {
> > }
> >
> > As others noted, it's also appealing to do this for type declarations
> too:
> >
> > struct Foo
> >where T.Foo == U.Bar
> > {
> > }
> >
> > and that gives a consistent feeling with extensions and protocol
> declarations.
> >
> > -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
>



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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Matt Whiteside via swift-evolution]

+1 to moving the `where` clause after the function signature.

-Matt

> On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>>  wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.  For example, the Swift book 
>> implements this example to motivate where clauses
>> 
>> func anyCommonElements > T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> This is noisy and uncomfortable to my eyes, and almost impossible to align 
>> correctly.  Per a short discussion on Twitter with Joe Groff and Erica 
>> Sadun, I'd like so see what the community feels about moving the where 
>> clause out of the angle brackets.  So that example becomes
>> 
>> func anyCommonElements 
>> where T.Generator.Element: Equatable, T.Generator.Element == 
>> U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Thoughts?
> 
> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
> 
> As others noted, it's also appealing to do this for type declarations too:
> 
> struct Foo
>where T.Foo == U.Bar
> {
> }
> 
> and that gives a consistent feeling with extensions and protocol declarations.
> 
> -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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Howard Lovatt via swift-evolution]

I like the idea, I find the beginning of a declaration too cluttered and it
obscures the main purpose. Like Brent I am wary of the design by contract
(DBC) bit, `lhs <= rhs`. DBC is probably for a separate discussion, but
moving the where clause would probably help.

  -- Howard.

On 7 April 2016 at 10:36, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >> I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
> >>
> >> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> >>where T : SequenceType,
> >>  U : SequenceType,
> >>  T.Generator.Element: Equatable,
> >>  T.Generator.Element == U.Generator.Element
> >> {
> >>...
> >> }
> >>
> >> That would make the definition look closer to what the call site looks
> like.
> >>
> >> The same would work for generic types  too:
> >>
> >> public struct Dictionary
> >>where Key : Hashable
> >> {
> >>   ...
> >> }
> >
> > Another nice thing about this style is that, in principle, I think it
> could be extended to specify requirements on non-type parameter values.
> >
> >func ..< (lhs: Element, rhs: Element) ->
> Range
> >where Element: Comparable, lhs <= rhs {
> >…
> >}
> >
> > I'm not saying we must or even should include that feature, merely that
> it gives us a nice syntactic slot to use if we choose to do so later.
>
> I know you're not proposing that feature right now, but want to understand
> how you expect it to work.  It looks to me like this starts to enter design
> by contract territory.  Would the predicate behave as if it was part of a
> precondition?
>
> > --
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> I would actually move them as far as after everything else, and right before 
>> the definition body. For the above function that would mean:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>>where T : SequenceType,
>>  U : SequenceType,
>>  T.Generator.Element: Equatable,
>>  T.Generator.Element == U.Generator.Element
>> {
>>...
>> }
>> 
>> That would make the definition look closer to what the call site looks like.
>> 
>> The same would work for generic types  too:
>> 
>> public struct Dictionary
>>where Key : Hashable
>> {
>>   ...
>> }
> 
> Another nice thing about this style is that, in principle, I think it could 
> be extended to specify requirements on non-type parameter values.
> 
>func ..< (lhs: Element, rhs: Element) -> 
> Range
>where Element: Comparable, lhs <= rhs {
>…
>}
> 
> I'm not saying we must or even should include that feature, merely that it 
> gives us a nice syntactic slot to use if we choose to do so later.

I know you're not proposing that feature right now, but want to understand how 
you expect it to work.  It looks to me like this starts to enter design by 
contract territory.  Would the predicate behave as if it was part of a 
precondition?

> -- 
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Ross O'Brien via swift-evolution]

I'm hoping this extends to type values.

struct StructWithClosure
{
   let closure : (lhs: Element, rhs:Element) -> Range where
Element : Incrementable, Comparable
}

or for that matter, protocol values:

struct StructWithIntCollectionType
{
let collection : C where C : CollectionType, C.Element == Int
}


On Thu, Apr 7, 2016 at 1:13 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
> >
> > func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> > where T : SequenceType,
> >   U : SequenceType,
> >   T.Generator.Element: Equatable,
> >   T.Generator.Element == U.Generator.Element
> > {
> > ...
> > }
> >
> > That would make the definition look closer to what the call site looks
> like.
> >
> > The same would work for generic types  too:
> >
> > public struct Dictionary
> > where Key : Hashable
> > {
> >...
> > }
>
> Another nice thing about this style is that, in principle, I think it
> could be extended to specify requirements on non-type parameter values.
>
> func ..< (lhs: Element, rhs: Element) ->
> Range
> where Element: Comparable, lhs <= rhs {
> …
> }
>
> I'm not saying we must or even should include that feature, merely that it
> gives us a nice syntactic slot to use if we choose to do so later.
>
> --
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Brent Royal-Gordon via swift-evolution]

> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }

Another nice thing about this style is that, in principle, I think it could be 
extended to specify requirements on non-type parameter values.

func ..< (lhs: Element, rhs: Element) -> 
Range
where Element: Comparable, lhs <= rhs {
…
}

I'm not saying we must or even should include that feature, merely that it 
gives us a nice syntactic slot to use if we choose to do so later.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Ross O'Brien via swift-evolution]

It's probably appropriate. Given that, in this example, Bar implicitly
unifies its generic constraint T with Foo's associatedtype T (or,
typealiases T with T), you need to be at least a little careful how you
name your generic constraints.

protocol Foo
{
associatedtype T
}

struct Bar : Foo
{
}

On Thu, Apr 7, 2016 at 12:52 AM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think this is a good idea, though I would put the `where` clause after
> the function signature:
>
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
>
>
> A bit of a meta-argument:
>
> It is very common to use single-capital letter generic parameters, and the
> API style does not give guidance around the naming of generic parameters.
>
> However in my humble-but-opinionated view, they are effectively
> scope-bound, dynamic type aliases. Declaring func "foo" is like
> declaring “var i”, but its forgiven since coming up with a good, concise
> name for such a type alias can be hard.
>
> The standard library seems inconsistent about this as well:
>
> func == (_: (A, B), rhs: (A, B))
>
> vs.
>
> func == (_: [Key : Value], rhs: [Key :
> Value])
>
> The argument I bring up is that naming of the generic parameters may wind
> up affecting whether the code is clearer having type constraints and the
> where clause within the brackets or trailing the function. It is important
> to take this into account and compare both apples to apples and oranges to
> oranges when evaluating syntax.
>
> (or, change the API guide and standard library to discourage either apples
> or oranges)
>
> -DW
>
>
> I'll keep this short. IMO:
>
> * Dictionaries have semantics, so Key/Value makes sense.
> * Truly "generic" equatable values do not, so A and B are simple stand-ins.
> * Always prefer named tokens when there are actual semantics (Element,
> Wrapped, etc).
>
> This may or may not be appropriate for inclusion in the API guidelines.
>
> -- E
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Jordan Rose via swift-evolution]

> On Apr 6, 2016, at 16:52, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I think this is a good idea, though I would put the `where` clause after 
>>> the function signature:
>>> 
>>> func foo(x: T, y: U) -> Result
>>>where T.Foo == U.Bar /*, etc. */
>>> {
>>> }
>> 
>> A bit of a meta-argument:
>> 
>> It is very common to use single-capital letter generic parameters, and the 
>> API style does not give guidance around the naming of generic parameters.
>> 
>> However in my humble-but-opinionated view, they are effectively scope-bound, 
>> dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
>> its forgiven since coming up with a good, concise name for such a type alias 
>> can be hard.
>> 
>> The standard library seems inconsistent about this as well:
>> 
>> func == (_: (A, B), rhs: (A, B))
>> 
>> vs.
>> 
>> func == (_: [Key : Value], rhs: [Key : 
>> Value])
>> 
>> The argument I bring up is that naming of the generic parameters may wind up 
>> affecting whether the code is clearer having type constraints and the where 
>> clause within the brackets or trailing the function. It is important to take 
>> this into account and compare both apples to apples and oranges to oranges 
>> when evaluating syntax.
>> 
>> (or, change the API guide and standard library to discourage either apples 
>> or oranges)
>> 
>> -DW
> 
> I'll keep this short. IMO:
> 
> * Dictionaries have semantics, so Key/Value makes sense.
> * Truly "generic" equatable values do not, so A and B are simple stand-ins.
> * Always prefer named tokens when there are actual semantics (Element, 
> Wrapped, etc). 
> 
> This may or may not be appropriate for inclusion in the API guidelines.

Another factor here is that we've been planning for a while for generic 
parameters to types to be exposed as implicit member typealiases, since they 
already conflict with the namespace for member typealiases. Therefore it's 
important to name generic parameters to types well, but less important to do so 
for generic parameters for functions. (They're also much less likely to be ad 
hoc for types; there has to be something that describes the relation between 
the Self type and the parameter, while the function might not have anything 
more interesting than "operand".)

This is also a minor point against declaring generic parameters for extensions, 
since they would have to match up. We also do need a syntax some day to 
represent new parameters:

// For expository purposes only:
extension  Array where Element == Optional

But that deserves its own proposal. I just don't want us to paint ourselves 
into a corner.

Jordan

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I think this is a good idea, though I would put the `where` clause after the 
>> function signature:
>> 
>> func foo(x: T, y: U) -> Result
>>where T.Foo == U.Bar /*, etc. */
>> {
>> }
> 
> A bit of a meta-argument:
> 
> It is very common to use single-capital letter generic parameters, and the 
> API style does not give guidance around the naming of generic parameters.
> 
> However in my humble-but-opinionated view, they are effectively scope-bound, 
> dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
> its forgiven since coming up with a good, concise name for such a type alias 
> can be hard.
> 
> The standard library seems inconsistent about this as well:
> 
> func == (_: (A, B), rhs: (A, B))
> 
> vs.
> 
> func == (_: [Key : Value], rhs: [Key : 
> Value])
> 
> The argument I bring up is that naming of the generic parameters may wind up 
> affecting whether the code is clearer having type constraints and the where 
> clause within the brackets or trailing the function. It is important to take 
> this into account and compare both apples to apples and oranges to oranges 
> when evaluating syntax.
> 
> (or, change the API guide and standard library to discourage either apples or 
> oranges)
> 
> -DW

I'll keep this short. IMO:

* Dictionaries have semantics, so Key/Value makes sense.
* Truly "generic" equatable values do not, so A and B are simple stand-ins.
* Always prefer named tokens when there are actual semantics (Element, Wrapped, 
etc). 

This may or may not be appropriate for inclusion in the API guidelines.

-- E


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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[David Waite via swift-evolution]

> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }

A bit of a meta-argument:

It is very common to use single-capital letter generic parameters, and the API 
style does not give guidance around the naming of generic parameters.

However in my humble-but-opinionated view, they are effectively scope-bound, 
dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
its forgiven since coming up with a good, concise name for such a type alias 
can be hard.

The standard library seems inconsistent about this as well:

func == (_: (A, B), rhs: (A, B))

vs.

func == (_: [Key : Value], rhs: [Key : 
Value])

The argument I bring up is that naming of the generic parameters may wind up 
affecting whether the code is clearer having type constraints and the where 
clause within the brackets or trailing the function. It is important to take 
this into account and compare both apples to apples and oranges to oranges when 
evaluating syntax.

(or, change the API guide and standard library to discourage either apples or 
oranges)

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Dany St-Amant via swift-evolution]

> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution 
>  a écrit :
> 
> 
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
>> 
>> Joe,
>> 
>> Just from your experience on this topic, is there any reason not to also 
>> move the primary constraints into the trailing `where` clause?
>> 
>> So instead of what you wrote, we'd have it this way:
>> 
>>func foo(x: T, y: U) -> Result
>>   where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
>>{
>>}
>> 
>> …as well as:
>> 
>>struct Foo
>>   where T: Foo, U: Bar, T.Foo == U.Bar
>>{
>>}
>> 
>> Like I said earlier in this thread, I think this would also make the 
>> `extension` syntax more uniform with types (by turning generic parameters 
>> into strictly locally visible things):
>> 
>>extension Foo where U == Baz { // (Could've used X and Y here as 
>> well.)
>>// Now it's clear where the names T and U come from.
>>var bazzes: [U] { return ... }
>>}
> 
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.
> 

I'm with Joe here on not banning it. Having the key constraint up front seems 
make it easier to grasp the goal of the generic function with a quick glance.

Flexibility around the constraint already exist, as one can currently write:

func foo(x: C) -> C.Element

But probably few do so (maybe just because it's longer to type)

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 1:21 PM, Pyry Jahkola  wrote:
> 
>> Joe Groff wrote:
>> 
>> It's a judgment call. It's my feeling that in many cases, a generic 
>> parameter is constrained by at least one important protocol or base class 
>> that's worth calling out up front, so it's reasonable to allow things like 
>> 'func foo(x: C) -> C.Element' without banishing the 
>> 'Collection' constraint too far from the front of the declaration.
> 
> Fair enough. I think it would be clearer if all the constraints appeared in 
> one standard place (in the `where` clause).

That's definitely a reasonable position worth discussing.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Erica Sadun via swift-evolution]

On Apr 6, 2016, at 2:03 PM, Joe Groff via swift-evolution 
 wrote:
> 
>> 
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
>> 
>> Joe,
>> 
>> Just from your experience on this topic, is there any reason not to also 
>> move the primary constraints into the trailing `where` clause?
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.

>From a reading point of view, it's always better to declare tokens before 
>using them. This groups them with the parameters (and the parameters in turn 
>may use the tokens), so the scope-specific vocabulary is all laid out in front.

-- E

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Shawn Erickson via swift-evolution]

I think the where clause should be moved to the end as you outlined an any
constraints beyond simple statements of conformance to a protocol or
superclass should only be allowed in the where clause. If someone desires
to state simple conformance/superclass for a generic parameter they should
be allowed to do so in either location.

On Wed, Apr 6, 2016 at 1:21 PM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

> Joe Groff wrote:
>
>
> It's a judgment call. It's my feeling that in many cases, a generic
> parameter is constrained by at least one important protocol or base class
> that's worth calling out up front, so it's reasonable to allow things like
> 'func foo(x: C) -> C.Element' without banishing the
> 'Collection' constraint too far from the front of the declaration.
>
>
> Fair enough. I think it would be clearer if all the constraints appeared
> in one standard place (in the `where` clause).
>
> — 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

> Joe Groff wrote:
> 
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.

Fair enough. I think it would be clearer if all the constraints appeared in one 
standard place (in the `where` clause).

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
> 
> Joe,
> 
> Just from your experience on this topic, is there any reason not to also move 
> the primary constraints into the trailing `where` clause?
> 
> So instead of what you wrote, we'd have it this way:
> 
> func foo(x: T, y: U) -> Result
>where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
> {
> }
> 
> …as well as:
> 
> struct Foo
>where T: Foo, U: Bar, T.Foo == U.Bar
> {
> }
> 
> Like I said earlier in this thread, I think this would also make the 
> `extension` syntax more uniform with types (by turning generic parameters 
> into strictly locally visible things):
> 
> extension Foo where U == Baz { // (Could've used X and Y here as 
> well.)
> // Now it's clear where the names T and U come from.
> var bazzes: [U] { return ... }
> }

It's a judgment call. It's my feeling that in many cases, a generic parameter 
is constrained by at least one important protocol or base class that's worth 
calling out up front, so it's reasonable to allow things like 'func foo(x: C) -> C.Element' without banishing the 'Collection' constraint 
too far from the front of the declaration.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

> For example, this Standard Library function:
> 
> public func + <
> C : RangeReplaceableCollectionType,
> S : SequenceType
> where S.Generator.Element == C.Generator.Element
> > (lhs: C, rhs: S) -> C
> 
> would become:
> 
> public func + (lhs: C, rhs: S) -> C where <
> C : RangeReplaceableCollectionType
> C : SequenceType
> S.Generator.Element == C.Generator.Element
> >
> 

As for structs, this Standard Library struct:

public struct FlattenBidirectionalCollection  
: CollectionType { … }

… could become:

public struct FlattenBidirectionalCollection : CollectionType 
where <
 Base : CollectionType
 Base.Generator.Element : CollectionType
 Base.Index : BidirectionalIndexType
 Base.Generator.Element.Index : BidirectionalIndexType
> { … }

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

Joe,

Just from your experience on this topic, is there any reason not to also move 
the primary constraints into the trailing `where` clause?

So instead of what you wrote, we'd have it this way:

func foo(x: T, y: U) -> Result
   where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
{
}

…as well as:

struct Foo
   where T: Foo, U: Bar, T.Foo == U.Bar
{
}

Like I said earlier in this thread, I think this would also make the 
`extension` syntax more uniform with types (by turning generic parameters into 
strictly locally visible things):

extension Foo where U == Baz { // (Could've used X and Y here as 
well.)
// Now it's clear where the names T and U come from.
var bazzes: [U] { return ... }
}

— Pyry

> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
> 
> As others noted, it's also appealing to do this for type declarations too:
> 
> struct Foo
>where T.Foo == U.Bar
> {
> }
> 
> and that gives a consistent feeling with extensions and protocol declarations.


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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[plx via swift-evolution]

I don’t see much value in moving them out of the angle brackets but preserving 
the position; consider:

  // status-quo:
  func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool
  
  // as-per proposal:
  func anyCommonElements 
where 
T.Generator.Element: Equatable, 
T.Generator.Element == U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

…not very different! Or, if you want it with fewer lines:

  // status-quo:
  func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool
  
  // as-per proposal:
  func anyCommonElements 
where T.Generator.Element: Equatable, T.Generator.Element == 
U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

…still not very different!

Moving the `where` to come after “everything else" seems like an improvement 
for functions:

  func anyCommonElements (lhs: T, _ rhs: U) 
-> Bool
where 
T.Generator.Element: Equatable, 
T.Generator.Element == U.Generator.Element { 
  // body here...
}

…and presumably-also for type declarations:

  class SomeClass : BaseClass, SomeProtocol, AnotherProtocol
where
A.Something == SomethingElse,
B.Input == C.Output {

  }

..,but would take some getting-used-to.

Losing the ability to write `:` constraints inline in the brackets seems a 
non-starter, but perhaps constraints within the brackets could be limited to 
`:` constraints?

> On Apr 6, 2016, at 1:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?
> 
> ~Robert Widmann
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?

I think this is a good idea, though I would put the `where` clause after the 
function signature:

func foo(x: T, y: U) -> Result
where T.Foo == U.Bar /*, etc. */
{
}

 As others noted, it's also appealing to do this for type declarations too:

struct Foo
where T.Foo == U.Bar
{
}

and that gives a consistent feeling with extensions and protocol declarations.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Developer via swift-evolution]

Even better.  +1.

~Robert Widmann

2016/04/06 14:35、Pyry Jahkola via swift-evolution  
のメッセージ:

>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>>  wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> ― 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 19:48, Sean Heber  wrote:
> 
> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}
> 

But if the brackets are kept, we may be able to do away with commas? For 
example, this Standard Library function:

public func + <
C : RangeReplaceableCollectionType,
S : SequenceType
where S.Generator.Element == C.Generator.Element
> (lhs: C, rhs: S) -> C

would become:

public func + (lhs: C, rhs: S) -> C where <
C : RangeReplaceableCollectionType
C : SequenceType
S.Generator.Element == C.Generator.Element
>
 
Brackets may also be needed for the api view of the library.

milos

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Sean Heber via swift-evolution]

I would think it’d just be unconstrained generic parameters - same as this is 
now:

func f(lhs: A, _ rhs: B) {}

However I can see how it’d certainly be potentially too confusing. It might be 
worthwhile to retain the brackets, but require type restrictions to be moved to 
the trailing “where” so that it keeps the <> part as short as possible, so this 
would be an error:

func f(lhs: A, _ rhs: B) -> Bool {}

And would have to be written:

func f(lhs: A, _ rhs: B) -> Bool where A: SequenceType, B: Equatable {}

Maybe? That’s a bit longer, though. Maybe it’s not worth changing that aspect 
of it. I like moving “where” to the end, though.

l8r
Sean


> On Apr 6, 2016, at 1:53 PM, Timothy Wood  wrote:
> 
> 
>> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> This almost seems like it could work so that it didn't even need the 
>> bracketed parts to be able to figure out the types:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>>   T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {}
>> 
> 
> ... though if there are no type constraints, this would be ambiguous:
> 
>   // If there are no know types T and R in scope, is this an error or are 
> T and R assumed to be unconstrained generic parameters?
>   func f(arg: T) -> R
> 
> -tim
> 

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Juan Ignacio Laube via swift-evolution]

+1. I like the idea of seeing the function signature first, then the 
constraints.


> On Apr 6, 2016, at 3:47 PM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> milos
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

With `where` at the end, the Standard Library function:

public func != <
A : Equatable, 
B : Equatable, 
C : Equatable, 
D : Equatable, 
E : Equatable, 
F : Equatable
> (lhs: (A, B, C, D, E, F), rhs: (A, B, C, D, E, F)) -> Bool

becomes:

public func != (lhs: (A, B, C, D, E, F), rhs: (A, B, C, D, E, F)) -> 
Bool where <
A : Equatable,
B : Equatable,
C : Equatable,
D : Equatable,
E : Equatable,
F : Equatable
>
milos

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> — 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Taras Zakharko via swift-evolution]

A big +1 to this notation. 


> On 06 Apr 2016, at 20:47, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> milos
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}

I'd still keep the generic arguments listed there in the brackets if only for 
the following reasons:

1. The new names get introduced (in `<...>`) before their first use. So if you 
happened to name one of them `String`, it would be clear that you didn't mean 
`Swift.String`.

2. It's been sometimes wished that you could explicitly specify which 
specialisation you want to use, e.g. when passing a function into a handler 
(e.g. `let operation = anyCommonElements<[Int], [Int]>(_:_:)`).

3. How would you otherwise mention a generic type if there were no constraints 
for it? I think the suggested form:

extension Array {
// no constraints needed (not for T above, not for U below)
func map(transform: T -> U) -> Array { ... }
}

reads better than this:

extension Array {
// Wait what, where did U come from?
func map(transform: T -> U) -> Array { ... }
}

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 12:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> Thoughts?

+1.

-- E

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Timothy Wood via swift-evolution]

> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution 
>  wrote:
> 
> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}
> 

... though if there are no type constraints, this would be ambiguous:

// If there are no know types T and R in scope, is this an error or are 
T and R assumed to be unconstrained generic parameters?
func f(arg: T) -> R

-tim

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Sean Heber via swift-evolution]

This almost seems like it could work so that it didn't even need the bracketed 
parts to be able to figure out the types:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
T : SequenceType,
U : SequenceType,
T.Generator.Element: Equatable,
T.Generator.Element == U.Generator.Element
{}

.. which would address my concerns about distance from names to params, too!

l8r
Sean



> On Apr 6, 2016, at 1:47 PM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>>  wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> milos
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 

This is an excellent idea: +1!

If `where` is left on a previous line, it would also appear more in line with 
`throws`:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
T : SequenceType,
U : SequenceType,
T.Generator.Element: Equatable,
T.Generator.Element == U.Generator.Element
{
...
}


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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }

And I'm not sure if people feel the same as me, but I haven't been happy with 
the current way generic arguments (such as Key and Value above) magically 
appear in type extensions but are inaccessible from anywhere else and can't be 
made public (`public typealias Key = Key` is an error).

The above syntax would make it possible to use whatever identifiers locally so 
that it's clear what they are:

extension Dictionary
// (unclear if `where K : Hashable` should be repeated here, though)
{
...
}

extension Array
where T : Comparable
{
...
}

extension Array
where T == String
{
...
}

etc.

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Sean Heber via swift-evolution]

*grabs paintbrush*

Something that has always bothered me about the generic syntax for functions is 
how far the function’s name is from its parameters. There are probably reasons 
why the following might not work, but it could address my desire to keep the 
name of the thing close to the names of the inputs:

func 
where T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
anyCommonElements(lhs: T, _ rhs: U) -> Bool {
}

I haven't given this tons of thought, but this seemed like a good a thread as 
any to mention my concern about the distance of the name from the parameters. :)

l8r
Sean



> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool



> On Apr 6, 2016, at 1:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?
> 
> ~Robert Widmann
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Shawn Erickson via swift-evolution]

On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

> On 06 Apr 2016, at 21:30, Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an
> extension, maybe for a generic free function or operator, you know what a
> pain the syntax can be for these kinds of operations.
>
>
> +1 already!
>
> Or, if you're feeling ambitious, even
>
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
>
>
> I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
>
> func anyCommonElements*(lhs: T, _ rhs: U) -> Bool*
> *where T : SequenceType,*
>
> *  U : SequenceType,  T.Generator.Element: Equatable,*
>
> *  T.Generator.Element == U.Generator.Element*
> {
> ...
> }
>
> That would make the definition look closer to what the call site looks
> like.
>
> The same would work for generic types  too:
>
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
>

I very much like this suggestion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.

+1 already!

> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool

I would actually move them as far as after everything else, and right before 
the definition body. For the above function that would mean:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool
where T : SequenceType,
  U : SequenceType,
  T.Generator.Element: Equatable,
  T.Generator.Element == U.Generator.Element
{
...
}

That would make the definition look closer to what the call site looks like.

The same would work for generic types  too:

public struct Dictionary
where Key : Hashable
{
   ...
}

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

[swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Developer via swift-evolution]

If you've ever gotten to the point where you have a sufficiently generic 
interface to a thing and you need to constrain it, possibly in an extension, 
maybe for a generic free function or operator, you know what a pain the syntax 
can be for these kinds of operations.  For example, the Swift book implements 
this example to motivate where clauses

func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool

This is noisy and uncomfortable to my eyes, and almost impossible to align 
correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
I'd like so see what the community feels about moving the where clause out of 
the angle brackets.  So that example becomes

func anyCommonElements 
where T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

Or, if you're feeling ambitious, even

func anyCommonElements 
where T : SequenceType, U : SequenceType,
T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

Thoughts?

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