Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
> 
> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
> clear benefits of using the `inout` version of reduce:
> 
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
> 
> Even if the compiler were to optimize the unnecessary copy of `return arr + 
> [el]` away, there are still a lot of other mutable methods that you might 
> want to use within the reduce closure. So I think the proposal is still very 
> valid even if the compiler optimizations would magically appear tomorrow.
> 
> To push this proposal forward a little bit, I'd like to come up with a good 
> name. It seems like we shouldn't overload `reduce`, but choose a different 
> name, so that we don't stress the typechecker. Any other suggestions?
> 
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  > wrote:
> -- 
> Chris Eidhof


Sorry for the derail!

reduce(mutating:_:) { } is still my favorite; You can take mutating to mean we 
will copy the value now but mutate it later.


Some alternatives:

reduce(forMutating:_:) { }

reduce(forInout:_:) { }

reduce(initial:_:) { }

reduce(copying:mutate:) { }

// just kidding...
reduce(copyForLaterMutating:_:) { }



It should definitely be some form of reduce. 

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

Re: [swift-evolution] Reduce with inout

[Chris Eidhof via swift-evolution]

Not as a direct reply to Russ, but just to reiterate: to me, there are two
clear benefits of using the `inout` version of reduce:

1. The performance (currently discussed at length)
2. Readability (because we can use mutating methods on `inout` arguments).

Even if the compiler were to optimize the unnecessary copy of `return arr +
[el]` away, there are still a lot of other mutable methods that you might
want to use within the reduce closure. So I think the proposal is still
very valid even if the compiler optimizations would magically appear
tomorrow.

To push this proposal forward a little bit, I'd like to come up with a good
name. It seems like we shouldn't overload `reduce`, but choose a different
name, so that we don't stress the typechecker. Any other suggestions?

On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:

>
> On Jan 20, 2017, at 11:27 PM, Charles Srstka 
> wrote:
>
> On Jan 21, 2017, at 12:37 AM, Russ Bishop  wrote:
>
>
> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *I don’t even know how long it actually takes to finish this test, because
> the last time I did this I eventually got sick of waiting and killed the
> process. So, I don’t know quite how many orders of magnitude slower it is,
> but it’s a lot.*
>
>
> That’s all the endorsement I need. +1 from me.
>
>
> I do wonder if there is any way to get this sort of optimization out of
> the compiler. I suppose it would be difficult because the compiler doesn’t
> know what the mutable vs immutable pairs are or if such a pair even exists
> (array doesn’t have appending()).
>
>
> The (somewhat naïve) assumption that some optimization of this sort might
> be going on is what led me to do the speed test in the first place.
> However, when you think about it, it’d be really quite hard to do. A reduce
> that builds an array consists of the closure that adds something to an
> array, and the reduce function itself. With the code to both of these, it’s
> not inconceivable that the compiler could figure out what you’re doing, but
> unfortunately the two components live in different modules / compilation
> units. The closure doesn’t know that its return value is just going to be
> replacing the passed-in value, and the reduce function doesn’t know that
> the closure isn’t going to store the original array somewhere, so neither
> can really know that it’s safe to modify the array in place.
>
> Charles
>
>
>
> I was thinking of an optimization like this:
>
> 1. The closure or function doesn’t capture anything (and thus by
> definition nothing can escape the closure)
> 2. ???
> 3. Therefore input returns true for isUniquelyReferenced and no copying of
> the underlying storage is required (Profit!)
>
>
> The problem is obviously in step 2. We don’t have any way to express the
> necessary contract other than inout, which requires a separate definition.
> If it worked like throws/rethrows where a non-mutating closure promoted to
> an inout closure then we could just change the definition of reduce (though
> you’d still have to return the value). The compiler would need to
> understand that ownership of the underlying array storage moves from the
> input parameter to the constructed array inside the closure (and ultimately
> the return value). That’s a bit of a tall order.
>
> That leads me to think about why inout is required (because
> isKnownUniquelyReferenced returns false otherwise). Why can’t the compiler
> determine that the intermediate array is unique? Take this program:
> func doSomething(_ x: MyStruct) -> MyStruct {
> var mutX = x
> let isUnique = isKnownUniquelyReferenced()
> print("isUnique = \(isUnique)") //prints false
> return mutX
> }
> doSomething(MyStruct())
>
>
> The fact that storage is uniquely owned is trivially provable to a human
> but not to the compiler. Why?
>
>
> These are just idle musings. My suspicion is you need ownership
> annotations (aka borrow checker) to make this tractable but I don’t have
> any proof of that.
>
> Russ
>



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

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

[Russ Bishop via swift-evolution]

> On Jan 22, 2017, at 4:53 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Sent from my iPad
> 
> On Jan 22, 2017, at 3:15 PM, Chris Lattner  > wrote:
> 
>> 
>>> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
 
 Yeah, maybe there's a more general language feature that could replace 
 'fallthrough' here. Instead
 of labelling cases, we could support a 'reswitch' statement that 
 redispatches the switch to the case
 matching the operand:
 
switch some_value {
case .REFINED:
if !validate(some_value) { return NULL }
reswitch .BASE
 
case .BASE:
handle_enum_value();
}
>>> 
>>> We should just call a spade a spade and spell that "goto" ;-)
>> 
>> Goto has traditionally been used for unstructured control flow, but this 
>> form is still fully structured.  You cannot produce irreducible loops, jump 
>> into scopes, over declarations, etc.
> 
> It would be useful to know the technical definition of "structured." The fact 
> is that there's a large category of sensible goto-like jumps that we probably 
> want to allow and I see no advantage to giving them all distinct names.  I 
> don't believe users will distinguish them.  We already have "break looplabel" 
> and, aside from the label being in the wrong place, it's effectively a goto.  
> It seems to me we should just have goto and either prohibit the troublesome 
> uses or give them reasonable semantics.
> 
> I could live with "break" as well as "goto", but it feels a bit like it's 
> pretending to be something it isn't, and there's the source compatibility 
> problem with the label position.
> 
> -Dave

I always assumed structured control flow means control only jumps to approved 
points, not arbitrary statements. Implicitly this is jumping out of a scope to 
a less-nested scope but never into a more-nested scope.

Swift takes this even further: you are limited to early exit of control flow. 
That’s a lot more restrictive than arbitrary goto.


Russ

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

Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 20, 2017, at 11:27 PM, Charles Srstka  wrote:
> 
>> On Jan 21, 2017, at 12:37 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>> 
>>> I don’t even know how long it actually takes to finish this test, because 
>>> the last time I did this I eventually got sick of waiting and killed the 
>>> process. So, I don’t know quite how many orders of magnitude slower it is, 
>>> but it’s a lot.
>> 
>> That’s all the endorsement I need. +1 from me.
>> 
>> 
>> I do wonder if there is any way to get this sort of optimization out of the 
>> compiler. I suppose it would be difficult because the compiler doesn’t know 
>> what the mutable vs immutable pairs are or if such a pair even exists (array 
>> doesn’t have appending()).
> 
> The (somewhat naïve) assumption that some optimization of this sort might be 
> going on is what led me to do the speed test in the first place. However, 
> when you think about it, it’d be really quite hard to do. A reduce that 
> builds an array consists of the closure that adds something to an array, and 
> the reduce function itself. With the code to both of these, it’s not 
> inconceivable that the compiler could figure out what you’re doing, but 
> unfortunately the two components live in different modules / compilation 
> units. The closure doesn’t know that its return value is just going to be 
> replacing the passed-in value, and the reduce function doesn’t know that the 
> closure isn’t going to store the original array somewhere, so neither can 
> really know that it’s safe to modify the array in place.
> 
> Charles



I was thinking of an optimization like this:

1. The closure or function doesn’t capture anything (and thus by definition 
nothing can escape the closure)
2. ???
3. Therefore input returns true for isUniquelyReferenced and no copying of the 
underlying storage is required (Profit!)


The problem is obviously in step 2. We don’t have any way to express the 
necessary contract other than inout, which requires a separate definition. If 
it worked like throws/rethrows where a non-mutating closure promoted to an 
inout closure then we could just change the definition of reduce (though you’d 
still have to return the value). The compiler would need to understand that 
ownership of the underlying array storage moves from the input parameter to the 
constructed array inside the closure (and ultimately the return value). That’s 
a bit of a tall order.

That leads me to think about why inout is required (because 
isKnownUniquelyReferenced returns false otherwise). Why can’t the compiler 
determine that the intermediate array is unique? Take this program:
func doSomething(_ x: MyStruct) -> MyStruct {
var mutX = x
let isUnique = isKnownUniquelyReferenced()
print("isUnique = \(isUnique)") //prints false
return mutX
}
doSomething(MyStruct())


The fact that storage is uniquely owned is trivially provable to a human but 
not to the compiler. Why? 


These are just idle musings. My suspicion is you need ownership annotations 
(aka borrow checker) to make this tractable but I don’t have any proof of that.

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

Re: [swift-evolution] Strings in Swift 4

[David Sweeris via swift-evolution]

> On Jan 22, 2017, at 15:40, Chris Lattner via swift-evolution 
>  wrote:
> 
> Right, the only sensible semantics for a one sided range with an open end 
> point is that it goes to the end of the collection.  I see a few different 
> potential colors to paint this bikeshed with, all of which would have the 
> semantics “c[i.. 
> 1) Provide "c[i...]":
> 2) Provide "c[i..<]":
> 3) Provide both "c[i..<]” and "c[i…]":

Agreed on the semantics. I don't suppose "c[i..<_]" is a possible 4th option, 
is it? Even if it is, I'm not sure it's better than 1-3; just tossing it out 
there.

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

Re: [swift-evolution] Strings in Swift 4

[Glenn Adams via swift-evolution]

 +1 for # 1 also.

Glenn


On Sun, Jan 22, 2017 at 9:07 PM James Hillhouse via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for #1
>
>
>
> Jim
>
>
>
>
>
> > On Jan 22, 2017, at 5:40 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >
>
> >
>
> >>> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >>>
>
> >>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >>>
>
> >>> on Fri Jan 20 2017, Joe Groff  wrote:
>
> >>>
>
>  Jordan points out that the generalized slicing syntax stomps on '...x'
>
>  and 'x...', which would be somewhat obvious candidates for variadic
>
>  splatting if that ever becomes a thing. Now, variadics are a much more
>
>  esoteric feature and slicing is much more important to day-to-day
>
>  programming, so this isn't the end of the world IMO, but it is
>
>  something we'd be giving up.
>
> >>>
>
> >>> Good point, Jordan.
>
> >>
>
> >> In my experiments with introducing one-sided operators in Swift 3, I
> was not able to find a case where you actually wanted to write `c[i...]`.
> Everything I tried needed to use `c[i..<]` instead. My conclusion was that
> there was no possible use for postfix `...`; after all, `c[i...]` means
> `c[i...c.endIndex]`, which means `c[i.. violates a precondition on `index(after:)`.
>
> >
>
> > Right, the only sensible semantics for a one sided range with an open
> end point is that it goes to the end of the collection.  I see a few
> different potential colors to paint this bikeshed with, all of which would
> have the semantics “c[i..
> >
>
> > 1) Provide "c[i...]":
>
> > 2) Provide "c[i..<]":
>
> > 3) Provide both "c[i..<]” and "c[i…]":
>
> >
>
> > Since all of these operations would have the same behavior, it comes
> down to subjective questions:
>
> >
>
> > a) Do we want redundancy?  IMO, no, which is why #3 is not very
> desirable.
>
> > b) Which is easier to explain to people?  As you say, "i..< is shorthand
> for i..
> > c) Which is subjectively nicer looking?  IMO, #1 is much nicer
> typographically.  The ..< formulation looks like symbol soup, particularly
> because most folks would not put a space before ].
>
> >
>
> > There is no obvious winner, but to me, I tend to prefer #1.  What do
> other folks think?
>
> >
>
> >> If that's the case, you can reserve postfix `...` for future variadics
> features, while using prefix `...` for these one-sided ranges.
>
> >
>
> > I’m personally not very worried about this, the feature doesn’t exist
> yet and there are lots of ways to spell it.  This is something that could
> and probably should deserve a more explicit/heavy syntax for clarity.
>
> >
>
> > -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] Strings in Swift 4

[James Hillhouse via swift-evolution]

+1 for #1

Jim


> On Jan 22, 2017, at 5:40 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Fri Jan 20 2017, Joe Groff  wrote:
>>> 
 Jordan points out that the generalized slicing syntax stomps on '...x'
 and 'x...', which would be somewhat obvious candidates for variadic
 splatting if that ever becomes a thing. Now, variadics are a much more
 esoteric feature and slicing is much more important to day-to-day
 programming, so this isn't the end of the world IMO, but it is
 something we'd be giving up.
>>> 
>>> Good point, Jordan.
>> 
>> In my experiments with introducing one-sided operators in Swift 3, I was not 
>> able to find a case where you actually wanted to write `c[i...]`. Everything 
>> I tried needed to use `c[i..<]` instead. My conclusion was that there was no 
>> possible use for postfix `...`; after all, `c[i...]` means 
>> `c[i...c.endIndex]`, which means `c[i..> violates a precondition on `index(after:)`.
> 
> Right, the only sensible semantics for a one sided range with an open end 
> point is that it goes to the end of the collection.  I see a few different 
> potential colors to paint this bikeshed with, all of which would have the 
> semantics “c[i.. 
> 1) Provide "c[i...]":
> 2) Provide "c[i..<]":
> 3) Provide both "c[i..<]” and "c[i…]":
> 
> Since all of these operations would have the same behavior, it comes down to 
> subjective questions:
> 
> a) Do we want redundancy?  IMO, no, which is why #3 is not very desirable.
> b) Which is easier to explain to people?  As you say, "i..< is shorthand for 
> i.. c) Which is subjectively nicer looking?  IMO, #1 is much nicer 
> typographically.  The ..< formulation looks like symbol soup, particularly 
> because most folks would not put a space before ].
> 
> There is no obvious winner, but to me, I tend to prefer #1.  What do other 
> folks think?
> 
>> If that's the case, you can reserve postfix `...` for future variadics 
>> features, while using prefix `...` for these one-sided ranges.
> 
> I’m personally not very worried about this, the feature doesn’t exist yet and 
> there are lots of ways to spell it.  This is something that could and 
> probably should deserve a more explicit/heavy syntax for clarity.
> 
> -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] Strings in Swift 4

[James Froggatt via swift-evolution]

Could we add subscript labels to the list of options? While keeping the range 
syntax is appealing, I'm concerned it may cause confusion if the operators are 
used out of context.

The wording is up for debate, but something like this should be a fair 
alternative:
items[from: i]
items[upTo: i]

Sorry if this has been covered elsewhere (can't find the answer in this 
thread), but my first questions on discovering these operators (my source of 
confusion) would be what happens if I try the following:
let partialRange = 0..< //is this an infinite range?
let x = items[partialRange] //shouldn't this cause an out of bounds error?

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <0a458383-2415-4ed4-ad28-88393a671...@nondot.org> 


> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Fri Jan 20 2017, Joe Groff  wrote:
>> 
>>> Jordan points out that the generalized slicing syntax stomps on '...x'
>>> and 'x...', which would be somewhat obvious candidates for variadic
>>> splatting if that ever becomes a thing. Now, variadics are a much more
>>> esoteric feature and slicing is much more important to day-to-day
>>> programming, so this isn't the end of the world IMO, but it is
>>> something we'd be giving up.
>> 
>> Good point, Jordan.
> 
> In my experiments with introducing one-sided operators in Swift 3, I was not 
> able to find a case where you actually wanted to write `c[i...]`. Everything 
> I tried needed to use `c[i..<]` instead. My conclusion was that there was no 
> possible use for postfix `...`; after all, `c[i...]` means 
> `c[i...c.endIndex]`, which means `c[i.. violates a precondition on `index(after:)`.

Right, the only sensible semantics for a one sided range with an open end point 
is that it goes to the end of the collection.  I see a few different potential 
colors to paint this bikeshed with, all of which would have the semantics 
“c[i.. If that's the case, you can reserve postfix `...` for future variadics 
> features, while using prefix `...` for these one-sided ranges.

I’m personally not very worried about this, the feature doesn’t exist yet 
and there are lots of ways to spell it.  This is something that could and 
probably should deserve a more explicit/heavy syntax for clarity.

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

- End Message - 



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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 22, 2017, at 3:31 PM, Chris Lattner  wrote:
> 
> 
>> On Jan 20, 2017, at 2:23 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
 
 Still digesting, but I definitely support the goal of string processing 
 even better than Perl.  Some random thoughts:
 
 • I also like the suggestion of implicit conversion from substring slices 
 to strings based on a subtype relationship, since I keep running into that 
 issue when trying to use array slices.  
>>> 
>>> Interesting.  Could you offer some examples?
>> 
>> Nothing catastrophic.  Mainly just having to wrap all of my slices in 
>> Array() to actually use them, which obfuscates the purpose of my code. It 
>> also took me an embarrassingly long time to figure out that was what I had 
>> to do to make it work.  For the longest time, I couldn’t understand why 
>> anyone would use slices because I couldn’t actually use them with any API… 
>> and then someone mentioned wrapping it in Array() here on Evolution and I 
>> finally got it.  
> 
> I agree that it is important to make String[Slice] and Array[Slice] 
> consistent.  If there is an implicit conversion for one, it makes sense for 
> their to be an implicit conversion for the other.
> 
> That said, an implicit conversion here is something that we need to consider 
> very carefully.  Adding them would definitely increase programmer convenience 
> in some cases, but it comes with two potentially serious costs:
> 
> 1) The conversion from a slice to a container is a copying and O(n) memory 
> allocating operation.  Swift tends to prefer keeping these sorts of 
> operations explicit, in order to make it easier to reason about performance 
> of code.  For example, if you are forced to write:
> 
>let x = … something that returns a slice.
>foo(String(x))
>foo(String(x))
> 
> then you’re likely to notice the fact that you’re doing two expensive 
> operations, which are redundant.  If the conversion is implicit, you’d never 
> notice.  Also, the best solution may not be to create a single local 
> temporary, it might actually be to change “foo” to take a slice.

For completeness only, I should point out that we already have this situation 
with implicit conversion of Array to Array.

> 2) Implicit conversions like this are known to slow down the type checker, 
> sometimes substantially.  I know that there are improvements planned, but 
> this is exactly the sort of thing that increases the search space the 
> constraint solver needs to evaluate, and it is already exponential.  This 
> sort of issue is the root cause of the embarrassing “expression too complex” 
> errors.
> 
> -Chris
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 22, 2017, at 3:15 PM, Chris Lattner  wrote:
> 
> 
>>> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Yeah, maybe there's a more general language feature that could replace 
>>> 'fallthrough' here. Instead
>>> of labelling cases, we could support a 'reswitch' statement that 
>>> redispatches the switch to the case
>>> matching the operand:
>>> 
>>>switch some_value {
>>>case .REFINED:
>>>if !validate(some_value) { return NULL }
>>>reswitch .BASE
>>> 
>>>case .BASE:
>>>handle_enum_value();
>>>}
>> 
>> We should just call a spade a spade and spell that "goto" ;-)
> 
> Goto has traditionally been used for unstructured control flow, but this form 
> is still fully structured.  You cannot produce irreducible loops, jump into 
> scopes, over declarations, etc.

It would be useful to know the technical definition of "structured." The fact 
is that there's a large category of sensible goto-like jumps that we probably 
want to allow and I see no advantage to giving them all distinct names.  I 
don't believe users will distinguish them.  We already have "break looplabel" 
and, aside from the label being in the wrong place, it's effectively a goto.  
It seems to me we should just have goto and either prohibit the troublesome 
uses or give them reasonable semantics.

I could live with "break" as well as "goto", but it feels a bit like it's 
pretending to be something it isn't, and there's the source compatibility 
problem with the label position.

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

Re: [swift-evolution] Strings in Swift 4

[Nevin Brackett-Rozinsky via swift-evolution]

On Sun, Jan 22, 2017 at 6:40 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> on Fri Jan 20 2017, Joe Groff  wrote:
> >>
> >>> Jordan points out that the generalized slicing syntax stomps on '...x'
> >>> and 'x...', which would be somewhat obvious candidates for variadic
> >>> splatting if that ever becomes a thing. Now, variadics are a much more
> >>> esoteric feature and slicing is much more important to day-to-day
> >>> programming, so this isn't the end of the world IMO, but it is
> >>> something we'd be giving up.
> >>
> >> Good point, Jordan.
> >
> > In my experiments with introducing one-sided operators in Swift 3, I was
> not able to find a case where you actually wanted to write `c[i...]`.
> Everything I tried needed to use `c[i..<]` instead. My conclusion was that
> there was no possible use for postfix `...`; after all, `c[i...]` means
> `c[i...c.endIndex]`, which means `c[i.. violates a precondition on `index(after:)`.
>
> Right, the only sensible semantics for a one sided range with an open end
> point is that it goes to the end of the collection.  I see a few different
> potential colors to paint this bikeshed with, all of which would have the
> semantics “c[i..
> 1) Provide "c[i...]":
> 2) Provide "c[i..<]":
> 3) Provide both "c[i..<]” and "c[i…]":
>
> Since all of these operations would have the same behavior, it comes down
> to subjective questions:
>
> a) Do we want redundancy?  IMO, no, which is why #3 is not very desirable.
> b) Which is easier to explain to people?  As you say, "i..< is shorthand
> for i.. c) Which is subjectively nicer looking?  IMO, #1 is much nicer
> typographically.  The ..< formulation looks like symbol soup, particularly
> because most folks would not put a space before ].
>
> There is no obvious winner, but to me, I tend to prefer #1.  What do other
> folks think?
>

I strongly prefer “c[i...]”

Nevin



>
> > If that's the case, you can reserve postfix `...` for future variadics
> features, while using prefix `...` for these one-sided ranges.
>
> I’m personally not very worried about this, the feature doesn’t exist yet
> and there are lots of ways to spell it.  This is something that could and
> probably should deserve a more explicit/heavy syntax for clarity.
>
> -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] Strings in Swift 4

[Chris Lattner via swift-evolution]

> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Fri Jan 20 2017, Joe Groff  wrote:
>> 
>>> Jordan points out that the generalized slicing syntax stomps on '...x'
>>> and 'x...', which would be somewhat obvious candidates for variadic
>>> splatting if that ever becomes a thing. Now, variadics are a much more
>>> esoteric feature and slicing is much more important to day-to-day
>>> programming, so this isn't the end of the world IMO, but it is
>>> something we'd be giving up.
>> 
>> Good point, Jordan.
> 
> In my experiments with introducing one-sided operators in Swift 3, I was not 
> able to find a case where you actually wanted to write `c[i...]`. Everything 
> I tried needed to use `c[i..<]` instead. My conclusion was that there was no 
> possible use for postfix `...`; after all, `c[i...]` means 
> `c[i...c.endIndex]`, which means `c[i.. violates a precondition on `index(after:)`.

Right, the only sensible semantics for a one sided range with an open end point 
is that it goes to the end of the collection.  I see a few different potential 
colors to paint this bikeshed with, all of which would have the semantics 
“c[i.. If that's the case, you can reserve postfix `...` for future variadics 
> features, while using prefix `...` for these one-sided ranges.

I’m personally not very worried about this, the feature doesn’t exist yet and 
there are lots of ways to spell it.  This is something that could and probably 
should deserve a more explicit/heavy syntax for clarity.

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

Re: [swift-evolution] Strings in Swift 4

[Chris Lattner via swift-evolution]

> On Jan 20, 2017, at 2:23 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
>>> 
>>> Still digesting, but I definitely support the goal of string processing 
>>> even better than Perl.  Some random thoughts:
>>> 
>>> • I also like the suggestion of implicit conversion from substring slices 
>>> to strings based on a subtype relationship, since I keep running into that 
>>> issue when trying to use array slices.  
>> 
>> Interesting.  Could you offer some examples?
> 
> Nothing catastrophic.  Mainly just having to wrap all of my slices in Array() 
> to actually use them, which obfuscates the purpose of my code. It also took 
> me an embarrassingly long time to figure out that was what I had to do to 
> make it work.  For the longest time, I couldn’t understand why anyone would 
> use slices because I couldn’t actually use them with any API… and then 
> someone mentioned wrapping it in Array() here on Evolution and I finally got 
> it.  

I agree that it is important to make String[Slice] and Array[Slice] consistent. 
 If there is an implicit conversion for one, it makes sense for their to be an 
implicit conversion for the other.

That said, an implicit conversion here is something that we need to consider 
very carefully.  Adding them would definitely increase programmer convenience 
in some cases, but it comes with two potentially serious costs:

1) The conversion from a slice to a container is a copying and O(n) memory 
allocating operation.  Swift tends to prefer keeping these sorts of operations 
explicit, in order to make it easier to reason about performance of code.  For 
example, if you are forced to write:

   let x = … something that returns a slice.
   foo(String(x))
   foo(String(x))

then you’re likely to notice the fact that you’re doing two expensive 
operations, which are redundant.  If the conversion is implicit, you’d never 
notice.  Also, the best solution may not be to create a single local temporary, 
it might actually be to change “foo” to take a slice.


2) Implicit conversions like this are known to slow down the type checker, 
sometimes substantially.  I know that there are improvements planned, but this 
is exactly the sort of thing that increases the search space the constraint 
solver needs to evaluate, and it is already exponential.  This sort of issue is 
the root cause of the embarrassing “expression too complex” errors.

-Chris

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Howard Lovatt via swift-evolution]

On Sat, 21 Jan 2017 at 10:35 am, Jean-Daniel  wrote:

>
>
> > Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> >
>
> > In Java there is a hierarchy of errors, the idea is that you catch at
> different severities. It isn't particularly well implemented in Java with a
> weird hierarchy and errors strangely classified and poor naming. Despite
> these glaring shortcoming it does actually work!
>
> >
>
> > In Swift this general concept of user defined error type which have a
> severity level  could be implemented, it might be:
>
> >
>
> >protocol ProgramFatalError {} // Not possible to catch - terminates
> program
>
> >protocol ThreadFatalError {} // Not possible to catch - terminates
> thread, but calls thread's deinit - deinit has access to the error
>
> >protocol Error {} // As is
>
>
>
> How does TheadFatalError is supposed to behave in a world dominated by
> queue ?

Server side code often spawns a thread per connection. The idea of
ThreadFatalError is that a thread is the 'unit of code' that you can
terminate but leave the rest of the program running. For a server
application the connection to the server is dropped when a ThreadFatalError
is thrown, the connection can then be restablished because the main part of
the program is still running and in particular can spawn new threads.

Since exactly what Swift will support in terms of concurrent programming is
to be debated it may not be a thread that is the 'unit of terminable code',
it could be an actor for example. The thread/actor may well be executed on
a queue as you suggest. In particular my ThreadFatalError is not a solid
proposal since it is not yet known how Swift will handle concurrency. The
main point I was making is that a hierarchy of programmer defined errors is
useful since some are recoverable, some only need to terminate part of the
program, and others need to terminate the whole program. The exact dicing
and execution model are less important than the concept of
programmer-defined-granulated errors.

For example it may be possible to have just two levels: Error that is
potentially user recoverable and ThreadFatalError that terminates the
'terminable unit of computing' and if the top 'unit of computing' receives
a ThreadFatalError it terminates the whole program and hence
ProgramFatalError is not required.

As an aside: thread per connection and hence ThreadFatalError was an
example given at the start of this discussion thread [pun intended].
-- 
-- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 22, 2017, at 11:25 AM, Karim Nassar  wrote:
> 
>> From: Dave Abrahams 
>> To: Brent Royal-Gordon 
>> 
>>> While it's great that `compared(to:case:etc.)` is parallel to 
>>> `compared(to:)`, you don't actually want to *use* anything like 
>>> `compared(to:)` if you can help it. Think about the clarity at the use site:
>>> 
>>>   if foo.compared(to: bar, case: .insensitive, locale: .current) == .before 
>>> { … }
>> 
>> Right.  We intend to keep the usual comparison operators.
>> 
>> Poor readability of "foo <=> bar == .before" is another reason we think that 
>> giving up on "<=>" is no great loss.
>> 
>>> The operands and sense of the comparison are kind of lost in all this 
>>> garbage. You really want to see `foo < bar` in this code somewhere, but you 
>>> don't.
>> 
>> Yeah, we thought about trying to build a DSL for that, but failed.  I think 
>> the best possible option would be something like:
>> 
>>  foo.comparison(case: .insensitive, locale: .current) < bar
>> 
>> The biggest problem is that you can build things like
>> 
>>fu = foo.comparison(case: .insensitive, locale: .current)
>>br = bar.comparison(case: .sensitive)
>>fu < br // what does this mean?
>> 
>> We could even prevent such nonsense from compiling, but the cost in library 
>> API surface area is quite large.
>> 
>>> I'm struggling a little with the naming and syntax, but as a general 
>>> approach, I think we want people to use something more like this:
>>> 
>>>   if StringOptions(case: .insensitive, locale: .current).compare(foo < bar) 
>>> { … }
>> 
>> Yeah, we can't do that without making 
>> 
>>  let a = foo < bar
>> 
>> ambiguous
> 
> 
> So, cue crazy idea #1, but what about something like this?
> 
> struct StringComparison {
> 
>   let leftHand: String
>   let rightHand: String
>   let comparison: SortOrder
> 
>   var insensitive: Bool {
>   ...
>   }
>   // … etc
> }
> 
> func <(lhs: String, rhs: String) -> StringComparison { // similar for ==, >, 
> etc.
>   return StringComparison(leftHand: lhs, rightHand: rhs, comparison: 
> .before)
> }
> 
> Then:
> 
>   if (a < b).insensitive {
>   ...
>   }
> 
> This would fix the ambiguity of:
> 
>   let a = foo < bar // ‘a' is StringComparison
>   if a.insensitive {
> 
>   }
> 
> IMHO, the big problem with this is that the most obvious default case really 
> should fall-through to a boolean value for the comparison struct:
> 
>   if a < b { // case-sensitive, non-localized compare
>   ...
>   }
> 
> ...but I can’t figure out how to make that work without the old BooleanType 
> protocol, maybe someone smarter than I could…

Yeah... IMO this is the language telling us "don't do that."  for my part, I'm 
not really in the market for ideas about how to do this that cut against the 
grain of the language.  I'd settle for a slightly less expressive API if it 
means avoiding surprising corner case behaviors.  And there's so much more to 
discuss here than how to clean up this syntax. If someone comes up with an 
expressive notation that's free of issues, we can always implement it as an 
add-on later.

-Dave

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Daniel Duan via swift-evolution]

> On Jan 22, 2017, at 11:26 AM, Matthew Johnson  wrote:
> 
> 
>> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> Sure.  One of the first gadgets I wrote was a way of destructuring an array 
>> into a familiar cons-list kind of enum 
>> (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9 
>> ) which 
>> you use something like this with other non-trivial enums 
>> (https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161
>>  
>> ).
>> 
>> It's not strictly a problem for me to lose this feature, but it is gonna be 
>> a bit weird if we lose recursive match but also allow it for just plain old 
>> tuple patterns.
> 
> We’re not discussing taking away recursive match are we?  IIUC the discussion 
> is limited to taking away matching all associated values as a single tuple, 
> rather than matching each value individually.

Correct.

>> 
>> ~Robert Widmann
>> 
>> 2017/01/22 3:02、Daniel Duan > 
>> のメッセージ:
>> 
>>> FWIW, in all public Github repos with 5k+ stars whose language gets 
>>> recognized as “Swift”, 576 enum cases has associated values and among them 
>>> 55 has 2 values or more. After some very casual grepping I didn’t find a 
>>> lot of usage of this particular pattern.
>>> 
>>> Care to share some examples, Robert?
>>> 
>>> - Daniel Duan
>>> 
 On Jan 21, 2017, at 11:00 PM, Robert Widmann > wrote:
 
 I find myself doing this a lot, but maybe my problems are just more 
 Algebra-shaped than most.  That said, I appreciate this cleanup and lean 
 +1 (because you mentioned a way to partly keep this behavior).
 
 ~Robert Widmann
 
 2017/01/19 18:14、Joe Groff via swift-evolution > のメッセージ:
 
> 
>> On Jan 19, 2017, at 2:58 PM, Daniel Duan > > wrote:
>> 
>> 
>>> On Jan 19, 2017, at 2:29 PM, Joe Groff >> > wrote:
>>> 
 
 On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
 This looks totally reasonable to me. A couple of comments:
 
 1) Because this proposal is breaking the link between the associated 
 value of an enum case and tuple types, I think it should spell out the 
 rules that switch statements will use when matching an enum value 
 against a a case with an associated value. Some kind of rules fell out 
 of them being treated as tuple types, but they might not be what we 
 want.
>>> 
>>> I was about to bring up the same. Right now, an enum pattern works like 
>>> . , where the  then 
>>> recursively matches the payload tuple. In this model, it seems like 
>>> we'd want to treat it more like .(, , 
>>> ...). Similar to how we lost "tuple splatting" to forward a bunch of 
>>> arguments, we'd have to decide whether we lose the ability to match all 
>>> parts of the payload into a tuple.
>> 
>> I’m leaning towards “no” for simplicity of the language (and 
>> implementation). That means this would be source-breaking .  Will 
>> update the proposal and see how the rest of the feedback goes.
> 
> It'd be a good idea to try to find examples of people doing this out in 
> the wild too, to see how widespread it is as well as how onerous the 
> workarounds for losing the feature would be.
> 
> -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] [draft] Compound Names For Enum Cases

[Matthew Johnson via swift-evolution]

> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Sure.  One of the first gadgets I wrote was a way of destructuring an array 
> into a familiar cons-list kind of enum 
> (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9 
> ) which 
> you use something like this with other non-trivial enums 
> (https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161
>  
> ).
> 
> It's not strictly a problem for me to lose this feature, but it is gonna be a 
> bit weird if we lose recursive match but also allow it for just plain old 
> tuple patterns.

We’re not discussing taking away recursive match are we?  IIUC the discussion 
is limited to taking away matching all associated values as a single tuple, 
rather than matching each value individually.

> 
> ~Robert Widmann
> 
> 2017/01/22 3:02、Daniel Duan > のメッセージ:
> 
>> FWIW, in all public Github repos with 5k+ stars whose language gets 
>> recognized as “Swift”, 576 enum cases has associated values and among them 
>> 55 has 2 values or more. After some very casual grepping I didn’t find a lot 
>> of usage of this particular pattern.
>> 
>> Care to share some examples, Robert?
>> 
>> - Daniel Duan
>> 
>>> On Jan 21, 2017, at 11:00 PM, Robert Widmann >> > wrote:
>>> 
>>> I find myself doing this a lot, but maybe my problems are just more 
>>> Algebra-shaped than most.  That said, I appreciate this cleanup and lean +1 
>>> (because you mentioned a way to partly keep this behavior).
>>> 
>>> ~Robert Widmann
>>> 
>>> 2017/01/19 18:14、Joe Groff via swift-evolution >> > のメッセージ:
>>> 
 
> On Jan 19, 2017, at 2:58 PM, Daniel Duan  > wrote:
> 
> 
>> On Jan 19, 2017, at 2:29 PM, Joe Groff > > wrote:
>> 
>>> 
>>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> This looks totally reasonable to me. A couple of comments:
>>> 
>>> 1) Because this proposal is breaking the link between the associated 
>>> value of an enum case and tuple types, I think it should spell out the 
>>> rules that switch statements will use when matching an enum value 
>>> against a a case with an associated value. Some kind of rules fell out 
>>> of them being treated as tuple types, but they might not be what we 
>>> want.
>> 
>> I was about to bring up the same. Right now, an enum pattern works like 
>> . , where the  then 
>> recursively matches the payload tuple. In this model, it seems like we'd 
>> want to treat it more like .(, , ...). 
>> Similar to how we lost "tuple splatting" to forward a bunch of 
>> arguments, we'd have to decide whether we lose the ability to match all 
>> parts of the payload into a tuple.
> 
> I’m leaning towards “no” for simplicity of the language (and 
> implementation). That means this would be source-breaking .  Will update 
> the proposal and see how the rest of the feedback goes.
 
 It'd be a good idea to try to find examples of people doing this out in 
 the wild too, to see how widespread it is as well as how onerous the 
 workarounds for losing the feature would be.
 
 -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] [draft] Compound Names For Enum Cases

[Daniel Duan via swift-evolution]

This would be a real loss . Another nice thing we would be losing is tuple 
field labels *after* matching:

if case let .bar(a) = Foo.bar(x: Int, y: Int) {
  doThings(with: a.x, a.y)
}

Keeping them means we have the create a special (reverse)splatting rule for 
pattern matching. I can see a few arguments against this:

1. It's a cost in complexity that pays for some niche convenience (or not? 
Real-world usage research needed)
2. It can be added later without introducing source-breakage (but keeping it 
means less source-breakage after this proposal, again, depends on usage in the 
wild).
3. Depends on whether splatting comes up in the future, we may want to relate 
the syntax here and there.
4. As Tony mentioned, auto-deriving equitable could lead to eventual glory.

I was convinced to keep the feature after reading your example but now I'm not 
sure again. G.

> On Jan 22, 2017, at 7:42 AM, T.J. Usiyan  wrote:
> 
> Implementing equality would be made tedious again if we lose this.
> 
> ```
> enum Jams : Equatable {
> 
> case dmsr(Bool)
> case kiss(Bool, Bool)
> case pheromone(Int, Bool, Int)
> 
> 
> public static func ==(lhs:Jams, rhs:Jams) -> Bool {
> switch (lhs, rhs) {
> case let (.dmsr(left), .dmsr(right)):
> return left == right
> case let (.kiss(left), .kiss(right)):
> return left == right
> case let (.pheromone(left), .pheromone(right)):
> return left == right
> case (.dmsr, _), (.kiss, _), (.pheromone, _):
> return false
> }
> }
> }
> ```
> 
> 
> 
>> On Sun, Jan 22, 2017 at 4:51 AM, Robert Widmann via swift-evolution 
>>  wrote:
>> Sure.  One of the first gadgets I wrote was a way of destructuring an array 
>> into a familiar cons-list kind of enum 
>> (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9) which 
>> you use something like this with other non-trivial enums 
>> (https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161).
>> 
>> It's not strictly a problem for me to lose this feature, but it is gonna be 
>> a bit weird if we lose recursive match but also allow it for just plain old 
>> tuple patterns.
>> 
>> ~Robert Widmann
>> 
>> 2017/01/22 3:02、Daniel Duan  のメッセージ:
>> 
>>> FWIW, in all public Github repos with 5k+ stars whose language gets 
>>> recognized as “Swift”, 576 enum cases has associated values and among them 
>>> 55 has 2 values or more. After some very casual grepping I didn’t find a 
>>> lot of usage of this particular pattern.
>>> 
>>> Care to share some examples, Robert?
>>> 
>>> - Daniel Duan
>>> 
 On Jan 21, 2017, at 11:00 PM, Robert Widmann  
 wrote:
 
 I find myself doing this a lot, but maybe my problems are just more 
 Algebra-shaped than most.  That said, I appreciate this cleanup and lean 
 +1 (because you mentioned a way to partly keep this behavior).
 
 ~Robert Widmann
 
 2017/01/19 18:14、Joe Groff via swift-evolution  
 のメッセージ:
 
> 
>> On Jan 19, 2017, at 2:58 PM, Daniel Duan  wrote:
>> 
>> 
 On Jan 19, 2017, at 2:29 PM, Joe Groff  wrote:
 
 
 On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 This looks totally reasonable to me. A couple of comments:
 
 1) Because this proposal is breaking the link between the associated 
 value of an enum case and tuple types, I think it should spell out the 
 rules that switch statements will use when matching an enum value 
 against a a case with an associated value. Some kind of rules fell out 
 of them being treated as tuple types, but they might not be what we 
 want.
>>> 
>>> I was about to bring up the same. Right now, an enum pattern works like 
>>> . , where the  then 
>>> recursively matches the payload tuple. In this model, it seems like 
>>> we'd want to treat it more like .(, , 
>>> ...). Similar to how we lost "tuple splatting" to forward a bunch of 
>>> arguments, we'd have to decide whether we lose the ability to match all 
>>> parts of the payload into a tuple.
>> 
>> I’m leaning towards “no” for simplicity of the language (and 
>> implementation). That means this would be source-breaking .  Will 
>> update the proposal and see how the rest of the feedback goes.
> 
> It'd be a good idea to try to find examples of people doing this out in 
> the wild too, to see how widespread it is as well as how onerous the 
> workarounds for losing the feature would be.
> 
> -Joe
> 
> ___
> swift-evolution mailing list
> 

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

[Karl Wagner 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?
N/A

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick read (it’s a short proposal), participated in previous discussion.

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Tony Allevato via swift-evolution]

Which is another reason we should be auto-deriving Equatable.

Couldn't variation generics help here? If someone wanted to capture the
whole argument list as a single tuple, we could require that they do it as
a parameter pack? It's essentially the inverse of the tuple splat already
mentioned in that section of the generics manifesto.
On Sun, Jan 22, 2017 at 7:42 AM T.J. Usiyan via swift-evolution <
swift-evolution@swift.org> wrote:

> Implementing equality would be made tedious again if we lose this.
>
> ```
> enum Jams : Equatable {
>
> case dmsr(Bool)
> case kiss(Bool, Bool)
> case pheromone(Int, Bool, Int)
>
>
> public static func ==(lhs:Jams, rhs:Jams) -> Bool {
> switch (lhs, rhs) {
> case let (.dmsr(left), .dmsr(right)):
> return left == right
> case let (.kiss(left), .kiss(right)):
> return left == right
> case let (.pheromone(left), .pheromone(right)):
> return left == right
> case (.dmsr, _), (.kiss, _), (.pheromone, _):
> return false
> }
> }
> }
> ```
>
>
>
> On Sun, Jan 22, 2017 at 4:51 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sure.  One of the first gadgets I wrote was a way of destructuring an
> array into a familiar cons-list kind of enum (
> https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9) which
> you use something like this with other non-trivial enums (
> https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161
> ).
>
> It's not strictly a problem for me to lose this feature, but it is gonna
> be a bit weird if we lose recursive match but also allow it for just plain
> old tuple patterns.
>
> ~Robert Widmann
>
> 2017/01/22 3:02、Daniel Duan  のメッセージ:
>
> FWIW, in all public Github repos with 5k+ stars whose language gets
> recognized as “Swift”, 576 enum cases has associated values and among them
> 55 has 2 values or more. After some very casual grepping I didn’t find a
> lot of usage of this particular pattern.
>
> Care to share some examples, Robert?
>
> - Daniel Duan
>
> On Jan 21, 2017, at 11:00 PM, Robert Widmann 
> wrote:
>
> I find myself doing this *a lot*, but maybe my problems are just more
> Algebra-shaped than most.  That said, I appreciate this cleanup and lean +1
> (because you mentioned a way to partly keep this behavior).
>
> ~Robert Widmann
>
> 2017/01/19 18:14、Joe Groff via swift-evolution 
> のメッセージ:
>
>
> On Jan 19, 2017, at 2:58 PM, Daniel Duan  wrote:
>
>
>
> On Jan 19, 2017, at 2:29 PM, Joe Groff  wrote:
>
>
>
> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> This looks totally reasonable to me. A couple of comments:
>
>
> 1) Because this proposal is breaking the link between the associated value
> of an enum case and tuple types, I think it should spell out the rules that
> switch statements will use when matching an enum value against a a case
> with an associated value. Some kind of rules fell out of them being treated
> as tuple types, but they might not be what we want.
>
>
> I was about to bring up the same. Right now, an enum pattern works like
> . , where the  then recursively
> matches the payload tuple. In this model, it seems like we'd want to treat
> it more like .(, , ...). Similar to how we
> lost "tuple splatting" to forward a bunch of arguments, we'd have to decide
> whether we lose the ability to match all parts of the payload into a tuple.
>
>
> I’m leaning towards “no” for simplicity of the language (and
> implementation). That means this would be source-breaking .  Will update
> the proposal and see how the rest of the feedback goes.
>
>
> It'd be a good idea to try to find examples of people doing this out in
> the wild too, to see how widespread it is as well as how onerous the
> workarounds for losing the feature would be.
>
> -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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[T.J. Usiyan via swift-evolution]

Implementing equality would be made tedious again if we lose this.

```
enum Jams : Equatable {

case dmsr(Bool)
case kiss(Bool, Bool)
case pheromone(Int, Bool, Int)


public static func ==(lhs:Jams, rhs:Jams) -> Bool {
switch (lhs, rhs) {
case let (.dmsr(left), .dmsr(right)):
return left == right
case let (.kiss(left), .kiss(right)):
return left == right
case let (.pheromone(left), .pheromone(right)):
return left == right
case (.dmsr, _), (.kiss, _), (.pheromone, _):
return false
}
}
}
```



On Sun, Jan 22, 2017 at 4:51 AM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> Sure.  One of the first gadgets I wrote was a way of destructuring an
> array into a familiar cons-list kind of enum (https://github.com/typelift/
> Basis/blob/master/Basis/Array.swift#L9) which you use something like this
> with other non-trivial enums (https://github.com/typelift/Valence/blob/
> cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161).
>
> It's not strictly a problem for me to lose this feature, but it is gonna
> be a bit weird if we lose recursive match but also allow it for just plain
> old tuple patterns.
>
> ~Robert Widmann
>
> 2017/01/22 3:02、Daniel Duan  のメッセージ:
>
> FWIW, in all public Github repos with 5k+ stars whose language gets
> recognized as “Swift”, 576 enum cases has associated values and among them
> 55 has 2 values or more. After some very casual grepping I didn’t find a
> lot of usage of this particular pattern.
>
> Care to share some examples, Robert?
>
> - Daniel Duan
>
> On Jan 21, 2017, at 11:00 PM, Robert Widmann 
> wrote:
>
> I find myself doing this *a lot*, but maybe my problems are just more
> Algebra-shaped than most.  That said, I appreciate this cleanup and lean +1
> (because you mentioned a way to partly keep this behavior).
>
> ~Robert Widmann
>
> 2017/01/19 18:14、Joe Groff via swift-evolution 
> のメッセージ:
>
>
> On Jan 19, 2017, at 2:58 PM, Daniel Duan  wrote:
>
>
>
> On Jan 19, 2017, at 2:29 PM, Joe Groff  wrote:
>
>
>
> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> This looks totally reasonable to me. A couple of comments:
>
>
> 1) Because this proposal is breaking the link between the associated value
> of an enum case and tuple types, I think it should spell out the rules that
> switch statements will use when matching an enum value against a a case
> with an associated value. Some kind of rules fell out of them being treated
> as tuple types, but they might not be what we want.
>
>
> I was about to bring up the same. Right now, an enum pattern works like
> . , where the  then recursively
> matches the payload tuple. In this model, it seems like we'd want to treat
> it more like .(, , ...). Similar to how we
> lost "tuple splatting" to forward a bunch of arguments, we'd have to decide
> whether we lose the ability to match all parts of the payload into a tuple.
>
>
> I’m leaning towards “no” for simplicity of the language (and
> implementation). That means this would be source-breaking .  Will update
> the proposal and see how the rest of the feedback goes.
>
>
> It'd be a good idea to try to find examples of people doing this out in
> the wild too, to see how widespread it is as well as how onerous the
> workarounds for losing the feature would be.
>
> -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] [draft] Compound Names For Enum Cases

[Robert Widmann via swift-evolution]

Sure.  One of the first gadgets I wrote was a way of destructuring an array 
into a familiar cons-list kind of enum 
(https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9) which you 
use something like this with other non-trivial enums 
(https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161).

It's not strictly a problem for me to lose this feature, but it is gonna be a 
bit weird if we lose recursive match but also allow it for just plain old tuple 
patterns.

~Robert Widmann

2017/01/22 3:02、Daniel Duan  のメッセージ:

> FWIW, in all public Github repos with 5k+ stars whose language gets 
> recognized as “Swift”, 576 enum cases has associated values and among them 55 
> has 2 values or more. After some very casual grepping I didn’t find a lot of 
> usage of this particular pattern.
> 
> Care to share some examples, Robert?
> 
> - Daniel Duan
> 
>> On Jan 21, 2017, at 11:00 PM, Robert Widmann  
>> wrote:
>> 
>> I find myself doing this a lot, but maybe my problems are just more 
>> Algebra-shaped than most.  That said, I appreciate this cleanup and lean +1 
>> (because you mentioned a way to partly keep this behavior).
>> 
>> ~Robert Widmann
>> 
>> 2017/01/19 18:14、Joe Groff via swift-evolution  
>> のメッセージ:
>> 
>>> 
 On Jan 19, 2017, at 2:58 PM, Daniel Duan  wrote:
 
 
>>> On Jan 19, 2017, at 2:29 PM, Joe Groff  wrote:
>> 
>> 
>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> This looks totally reasonable to me. A couple of comments:
>> 
>> 1) Because this proposal is breaking the link between the associated 
>> value of an enum case and tuple types, I think it should spell out the 
>> rules that switch statements will use when matching an enum value 
>> against a a case with an associated value. Some kind of rules fell out 
>> of them being treated as tuple types, but they might not be what we want.
> 
> I was about to bring up the same. Right now, an enum pattern works like 
> . , where the  then recursively 
> matches the payload tuple. In this model, it seems like we'd want to 
> treat it more like .(, , ...). Similar to 
> how we lost "tuple splatting" to forward a bunch of arguments, we'd have 
> to decide whether we lose the ability to match all parts of the payload 
> into a tuple.
 
 I’m leaning towards “no” for simplicity of the language (and 
 implementation). That means this would be source-breaking .  Will update 
 the proposal and see how the rest of the feedback goes.
>>> 
>>> It'd be a good idea to try to find examples of people doing this out in the 
>>> wild too, to see how widespread it is as well as how onerous the 
>>> workarounds for losing the feature would be.
>>> 
>>> -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] [draft] Compound Names For Enum Cases

[Daniel Duan via swift-evolution]

FWIW, in all public Github repos with 5k+ stars whose language gets recognized 
as “Swift”, 576 enum cases has associated values and among them 55 has 2 values 
or more. After some very casual grepping I didn’t find a lot of usage of this 
particular pattern.

Care to share some examples, Robert?

- Daniel Duan

> On Jan 21, 2017, at 11:00 PM, Robert Widmann  wrote:
> 
> I find myself doing this a lot, but maybe my problems are just more 
> Algebra-shaped than most.  That said, I appreciate this cleanup and lean +1 
> (because you mentioned a way to partly keep this behavior).
> 
> ~Robert Widmann
> 
> 2017/01/19 18:14、Joe Groff via swift-evolution  > のメッセージ:
> 
>> 
>>> On Jan 19, 2017, at 2:58 PM, Daniel Duan >> > wrote:
>>> 
>>> 
 On Jan 19, 2017, at 2:29 PM, Joe Groff > wrote:
 
> 
> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> This looks totally reasonable to me. A couple of comments:
> 
> 1) Because this proposal is breaking the link between the associated 
> value of an enum case and tuple types, I think it should spell out the 
> rules that switch statements will use when matching an enum value against 
> a a case with an associated value. Some kind of rules fell out of them 
> being treated as tuple types, but they might not be what we want.
 
 I was about to bring up the same. Right now, an enum pattern works like 
 . , where the  then recursively 
 matches the payload tuple. In this model, it seems like we'd want to treat 
 it more like .(, , ...). Similar to how we 
 lost "tuple splatting" to forward a bunch of arguments, we'd have to 
 decide whether we lose the ability to match all parts of the payload into 
 a tuple.
>>> 
>>> I’m leaning towards “no” for simplicity of the language (and 
>>> implementation). That means this would be source-breaking .  Will update 
>>> the proposal and see how the rest of the feedback goes.
>> 
>> It'd be a good idea to try to find examples of people doing this out in the 
>> wild too, to see how widespread it is as well as how onerous the workarounds 
>> for losing the feature would be.
>> 
>> -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