Re: [swift-evolution] [Proposal] Random Unification

On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution wrote: > > IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array > (RandomAccessSequence?), they should just be for convenience and with a sane > default RNG*, and users that need more

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

–∞ 1. I strongly object to the proposed name. It doesn't make it more clear to me what the method does, and is misleading at best. Among other issues, "lexicographical" is defined as alphabet order, and (1) this method applies to objects that are not Strings, and (2) this method's behavior

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

+1 Agree with the reasoning and that this is the best solution. It reduces the risk of confusing the function for what it’s not. > On 13 Oct 2017, at 01:37, Kelvin Ma via swift-evolution > wrote: > > I’ve always hated the use of the word “lexicographically” in that

Re: [swift-evolution] commas optional

Hi Dave, I agree with you that this is an analogous technical problem to semicolon inference, and that Swift has a well developed solution for it which would probably work well enough. That said, this is a pure sugar proposal, one which can make future evolution more difficult. Getting this

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

I’ve always hated the use of the word “lexicographically” in that method 1) because lexicographically is hard to spell, and 2) because it’s weird to say that an unordered collection has a lexicographical order. But this change is probably for the best. On Thu, Oct 12, 2017 at 6:24 PM, Xiaodi Wu

Re: [swift-evolution] commas optional

On Thu, Oct 12, 2017 at 6:20 PM, Xiaodi Wu wrote: > On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution < > swift-evolution@swift.org> wrote: > >> I don't really expect this sort of syntactic sugar to be popular enough >> to make it through swift-evolution, and I

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

Rename Sequence.elementsEqual - Proposal: SE- - Authors: Xiaodi Wu - Review Manager: TBD - Status: *Awaiting review*

Re: [swift-evolution] commas optional

On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution < swift-evolution@swift.org> wrote: > I don't really expect this sort of syntactic sugar to be popular enough to > make it through swift-evolution, and I don't think it's worth the > distraction from more important priorities at this

Re: [swift-evolution] commas optional

> On 2017-10-12, at 12:03 PM, Xiaodi Wu wrote: > > Single elements can legally span multiple lines; this would be hugely source > breaking. What problem are you trying to solve? The same problem that is solved by the precedent of semicolons being optional (clutter). I

Re: [swift-evolution] commas optional

I don't really expect this sort of syntactic sugar to be popular enough to make it through swift-evolution, and I don't think it's worth the distraction from more important priorities at this time, but for what it's worth, I've enjoyed this feature in other languages that support it. It plays a

Re: [swift-evolution] commas optional

On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution > wrote: a semicolon is a purely syntactic delimiter, the comma on the other hand corresponds to physical elements in a collection. I think the two are more different than

Re: [swift-evolution] commas optional

a semicolon is a purely syntactic delimiter, the comma on the other hand corresponds to physical elements in a collection. I think the two are more different than you suggest. On Thu, Oct 12, 2017 at 1:50 PM, Dave Yost via swift-evolution < swift-evolution@swift.org> wrote: > > Speaking as a

Re: [swift-evolution] commas optional

Single elements can legally span multiple lines; this would be hugely source breaking. What problem are you trying to solve? On Thu, Oct 12, 2017 at 13:50 Dave Yost via swift-evolution < swift-evolution@swift.org> wrote: > > Speaking as a huge fan of optional semicolons... > > > This seems

[swift-evolution] commas optional

Speaking as a huge fan of optional semicolons... This seems clear: semicolon : sequence of statements :: comma : sequence of elements in an array literal and so it occurred to me that this should hold: A semicolon : the last statement on a line. :: A comma : the

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 12, 2017, at 6:13 AM, Jeremy Pereira > wrote: > > > >> On 11 Oct 2017, at 18:01, Kevin Nattinger wrote: >> >> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array >> (RandomAccessSequence?), they should just be for

Re: [swift-evolution] [Proposal] Random Unification

On Wed Oct 11 12:21:14 CDT 2017 Cory Benfield cbenfield at apple.com wrote: > I strongly recommend building the padded room. interesting view point. FTM, the arithmetic operations in swift are "safe and slow" by default, same principle... although they are not that slow (compared to how secure

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

Did not know you could do that. Still doesn’t change the fundamental problems with that syntax though. I think that we could enforce a precondition that overrunning the left hand slice is not allowed, but idk if subscript notation is worth all that trouble. On Thu, Oct 12, 2017 at 3:36 AM, Ole

Re: [swift-evolution] Property Getter Return Statement

Will this finally bring labels back everywhere (closures and stored functions too)? :D. On Thu, Oct 12, 2017 at 3:03 PM, Jeremy Pereira via swift-evolution < swift-evolution@swift.org> wrote: > > > > > > I’m minorly opposed, because it feels like a slippery slope. What about > function bodies?

Re: [swift-evolution] Property Getter Return Statement

> > I’m minorly opposed, because it feels like a slippery slope. What about > function bodies? etc > > func foo() -> Int { 3 } // should this be allowed? Yes, why not? What is fundamentally different about a function body compared to a getter body (or a closure body ;-)) that means, if we

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

On 12 October 2017 at 14:14, David James wrote: > True, and it was making the method signature too long. But at least I have > the option to do that. If we move the annotation to just before the return > type, then we have no choice. > you can still put it on the next

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

> On Oct 12, 2017, at 1:40 PM, Mike Kluev wrote: > > let me guess: you put it on a different line exactly because it is in it's > current ugly form :) True, and it was making the method signature too long. But at least I have the option to do that. If we move the

Re: [swift-evolution] [Proposal] Random Unification

> On 11 Oct 2017, at 18:21, Cory Benfield wrote: > > I strongly recommend building the padded room. > I strongly recommend that the padded room have a door in it. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Random Unification

> On 11 Oct 2017, at 18:01, Kevin Nattinger wrote: > > IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array > (RandomAccessSequence?), they should just be for convenience and with a sane > default RNG*, and users that need more should just use methods on the

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

On 12 October 2017 at 09:34, David James wrote: > IMO everyday app building would rarely need to use functions with > discardable results. This is more an issue with libraries or frameworks > that support a *fluent interface* (e.g. that return self) where an > operator

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution > wrote: > > On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky > > > wrote: > On Wednesday, October 11, 2017, Kelvin Ma via

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

IMO everyday app building would rarely need to use functions with discardable results. This is more an issue with libraries or frameworks that support a fluent interface (e.g. that return self) where an operator chain can be stopped at any point, unless it clearly doesn’t make sense, in which