Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

No, I'm talking about the implicit discardability proposed by Brent, such as for all Optional<@discardable T>. He proposes that the @discardable syntax has a strong motivating advantage because it can be extended in a way to mark _types_ so that return values of those types are always implicitly @

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

On 19 October 2017 at 05:04, Xiaodi Wu wrote: > > d) Does a class that override a `@discardable` type inherit that > annotation? If not, they it's kind of a weird exception to the inheritance > thing, no? If so, then we'd need a @nondiscardable annotation to do > type-level overrides of @discarda

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

In your earlier emails you wrote "To make it concrete, say you write a function that just wraps map: func firstNames(ofPeople people: Sequence) -> Sequence { return people.map { $0.firstName } } I want that function to work on both ordered and unordered Sequences, and if you start with an orde

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

On Wed, Oct 18, 2017 at 9:29 PM, Brent Royal-Gordon wrote: > On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > This idea was discussed long ago and the present design was selected. > > > But this design was discussed in the proposal as a "future

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution > wrote: > > This idea was discussed long ago and the present design was selected. But this design was discussed in the proposal as a "future direction", because @discardableResult was chosen partially because it was easier to implem

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 19.10.2017 um 01:13 schrieb Adam Kemp : > > >> On Oct 18, 2017, at 3:38 PM, Thorsten Seitz > > wrote: >> >> Now this is not production code (hopefully) but it demonstrates the problem. > > A single StackOverflow post is not convincing evidence of a problem that

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Please re-read my earlier emails with concrete examples of problems this split would cause: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171016/040501.html https://lists.swift.org/pipermail/s

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:04 schrieb Adam Kemp : > > >> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution >> wrote: >> >> Therefore having `elementsEqual` as API for unordered collections is a >> source of bugs … > > You keep saying that, and yet after repeated requests to provid

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 3:38 PM, Thorsten Seitz wrote: > > Now this is not production code (hopefully) but it demonstrates the problem. A single StackOverflow post is not convincing evidence of a problem that leads to many real-world bugs. No one here would dispute that people can get confused.

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:36 schrieb Michael Ilseman : >> To get back to the topic at hand: I propose to differentiate between >> unordered and ordered collections because I think that this is an important >> distinction with tractable impact on algorithms (as shown above). The method >> `elementsE

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:31 schrieb Adam Kemp : > > >> On Oct 18, 2017, at 1:20 PM, David Sweeris > > wrote: >> >> How many bugs have been caused by floating point types violating the >> programmer's mental model of how numbers work? To me, their both in the same >> c

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:36 schrieb Michael Ilseman : > > > >> On Oct 18, 2017, at 12:24 PM, Thorsten Seitz > > wrote: >> >>> >>> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution >>> mailto:swift-evolution@swift.org>>: >>> >>> >>> On Oct 17,

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 12:24 PM, Thorsten Seitz wrote: > >> >> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> >> >>> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >>> mailto:swift-evolution@swift.org>> wro

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 1:20 PM, David Sweeris wrote: > > How many bugs have been caused by floating point types violating the > programmer's mental model of how numbers work? To me, their both in the same > category... both involve specific types that claim to adhere to a certain > behavior, a

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 1:04 PM, Adam Kemp via swift-evolution > wrote: > > >> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution >> wrote: >> >> Therefore having `elementsEqual` as API for unordered collections is a >> source of bugs … > > You keep saying that, and yet after

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution > wrote: > > Therefore having `elementsEqual` as API for unordered collections is a source > of bugs … You keep saying that, and yet after repeated requests to provide evidence you still have not backed up this claim. How man

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution > : > > > >> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> Because, in my analysis, the problem is that the method is incorrectly >>> named. The probl

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 5:28 AM, Ole Begemann via swift-evolution > wrote: > > It also seems to clash with Michael's idea > > that two substitutable sequences should return true for ==. This is a bug in Float

Re: [swift-evolution] Property Getter Return Statement

I am going to try to learn how to implement this and submit a proper proposal. > On 7 Oct 2017, at 15:07, James Valaitis wrote: > > Is it widely agreed that it is necessary to require a return statement on a > one line property getter? > > var session: AVCaptureSession { get { return layer.se

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

On Wed, Oct 18, 2017 at 08:11 Martin R wrote: > > > > On 18. Oct 2017, at 13:55, Xiaodi Wu wrote: > > > > On Wed, Oct 18, 2017 at 03:05 Martin R wrote: > > > > > > > On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > > > > > >> On

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Yup. On Wed, Oct 18, 2017 at 07:28 Ole Begemann wrote: > On Tue, Oct 17, 2017, at 20:46, Xiaodi Wu via swift-evolution wrote: > > On Tue, Oct 17, 2017 at 12:54 Jonathan Hull wrote: > > Why was elementsEqual created? Isn’t it meant to check equality of two > sequences in a generic context where

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On 18. Oct 2017, at 13:55, Xiaodi Wu wrote: > > On Wed, Oct 18, 2017 at 03:05 Martin R wrote: > > > > On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution > > wrote: > > > > > > > >> On Oct 17, 2017, at 1:36 PM, Benjamin G > >> wrote: > >> > >> > >> > >> On Tue, Oct 17, 2017

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

On Tue, Oct 17, 2017, at 20:46, Xiaodi Wu via swift-evolution wrote: > On Tue, Oct 17, 2017 at 12:54 Jonathan Hull wrote: > >> Why was elementsEqual created? Isn’t it meant to check equality of >> two sequences in a generic context where == isn’t available?> > No no no no no no no no. That’s pr

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

On Wed, Oct 18, 2017 at 03:05 Martin R wrote: > > > > On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > >> On Oct 17, 2017, at 1:36 PM, Benjamin G > wrote: > >> > >> > >> > >> On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman > wr

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution > wrote: > > > >> On Oct 17, 2017, at 1:36 PM, Benjamin G wrote: >> >> >> >> On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman wrote: >> >> >>> On Oct 17, 2017, at 12:54 PM, Benjamin G >>> wrote: >>> >>> Thanks for th