[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> > func isEqual(to other: Self) ->Bool > > func isLess(than other: Self) ->Bool > > func isLessThanOrEqual(to other: Self) ->Bool > > I'm still not sure why these are methods instead of operators. I think this is an *excellent* choice, and I hope it is the first step to completely removing

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun. Have we considered this, then: a.union(b)

Re: [swift-evolution] multi-line string literals.

It’s +1 from me also. Swift’s Lexer is less than 2000 lines in it’s entirety whereas Perl’s tokeniser is more than 11,000 lines so I don’t think this is a direction we want to head in. Besides, I don’t feel there is a need for more than one type of string as Swift's \() interpolation syntax is

Re: [swift-evolution] [Proposal] Safer half-open range operator

Many thanks, Vladimir, I wasn't familiar with this yet. :-) - Luis On Sun, Apr 24, 2016 at 7:10 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > We already have this feature(to append labels for substiption), so I > believe it is possible to implement this proposal: > >

Re: [swift-evolution] Mutability for Foundation types in Swift

> We took this feedback seriously, and I would like to share with you the start > of an important journey for some of the most commonly used APIs on all of our > platforms: adopting value semantics for key Foundation types. This proposal is way cool, and I think you've selected a great starting

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

Is there a reason that NaN can’t just compare in a more useful way, e.g- always return true for the less than operator unless the other value is also NaN, thus ensuring it always comes first in ascending order? Or is there too much of a performance cost to make it a special case? That said

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 4/23/16 21:53, Brent Royal-Gordon via swift-evolution wrote: >> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible { >> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible { > > Any reason why FloatLiteralConvertible isn't on FloatingPoint? While I'm

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Yes +1 I think how the compiler can’t work with two methods with the same name, where one has a result, and other mutating, needs to be fixed to enable nice APIs. Patrick On Sun, Apr 24, 2016 at 2:33 AM -0700, "James Froggatt via swift-evolution" wrote:

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The whole naming issue seems to be caused by the .union(_:) function. The > Swift Guidelines say that mutating functions should use a verb, and > non-mutating forms should use a noun, but in this case, the word union itself > is a verb and a noun. > > Have we considered this, then: > >

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The idea of distinguishing all mutating/non-mutating functions with only the > assignment operator did occur to me as I wrote that. > Using such a rule would allow automatic generation of mutating methods from > non-mutating ones, since the naming would no longer need changing. > However, this

Re: [swift-evolution] Guaranteed closure execution

> Le 23 avr. 2016 à 18:33, Timothy Wood a écrit : > > > >> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution >> > [...] >> >> Since @once actually implies @noescape (as described earlier in the thread), >> it can be shortened to: > [...]

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> Regarding how this affects sorting methods though, some people (myself > included) like the simplicity of being able to do the following: > > myArray.sort(>) // If array is of Comparable elements, just throw in > the operator That is extremely convenient. With my proposed extensions,

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> On 24 Apr 2016, at 17:41, Xiaodi Wu wrote: > > Regarding how this affects sorting methods though, some people (myself > included) like the simplicity of being able to do the following: > > myArray.sort(>) // If array is of Comparable elements, just throw in > the

Re: [swift-evolution] Properties with parameters

> Tim Vermeulen via swift-evolutionwrites: > > > Properties are great. They allow us to write the more naturally looking > > > > myButton.hidden = true > > > > instead of > > > > myButton.setHidden(true) > > > > However, they don't take any parameters. That’s why we still

[swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I wrote the proposal which was discussed to introduce generic constraints for associated types. I’d like to get some feedback on it and get it ready before submitting it: More Powerful Constraints for Associated Types Proposal: SE-

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > > The idea of distinguishing all mutating/non-mutating functions with only > the assignment operator did occur to me as I wrote that. > > Using such a rule would allow automatic generation of

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 5:28 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > Is there a reason that NaN can’t just compare in a more useful way, e.g- > always return true for the less than operator unless the other value is > also NaN, thus ensuring it always comes first in

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

The idea of distinguishing all mutating/non-mutating functions with only the assignment operator did occur to me as I wrote that. Using such a rule would allow automatic generation of mutating methods from non-mutating ones, since the naming would no longer need changing. However, this would

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Apr 23, 2016, at 6:28 PM, Brent Royal-Gordon via swift-evolution wrote: > Simple and straightforward, but not actually accurate. In a strict total > order, all elements are ordered, but that's not true of the current > Comparable. For instance, floating-point NaNs

Re: [swift-evolution] Localization support for string interpolation

> On Apr 24, 2016, at 2:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution >> wrote: >> >> Hi there! >> >> TL;DR: Here’s my idea for a better localized strings

Re: [swift-evolution] Carriage Return in Collection Array Literal Initializer

There was a discussion some time ago about making the comma of the last entry optional, because adding entries meant changing more than one line of code and this annoyed users of version control systems. This is an elegant approach to that problem. I don't know if it's a practical approach for the

Re: [swift-evolution] multi-line string literals.

On Apr 22, 2016, at 12:54 PM, Patrick Gili via swift-evolution wrote: > If we use a quoting structure similar to Perl6, then we future proof the > grammar to accommodate regular expression literals (and multi-line regular > expression literals) later. It also gives

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> On Apr 24, 2016, at 2:51 PM, Brent Royal-Gordon wrote: > >> However, I don’t understand how that would help for floating point NaN >> behavior. Wouldn’t you have to add a fourth member to the enum >> (“unordered’) that all clients would have to handle? An approach like

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Sun, Apr 24, 2016 at 4:28 PM, Chris Lattner wrote: > > > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > > Sent from my iPhone > > > >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: >

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution >> wrote: >> >> >> >> Sent from my iPhone >> >>> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu

Re: [swift-evolution] multi-line string literals.

This isn’t the best argument but they can be very slow to compile :( > On 24 Apr 2016, at 22:52, Ted F.A. van Gaalen wrote: > > let purpleRain =// in remembrance to one of my favorite artists. > “What’s wrong with concatenating string constants with “ + >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

> > https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md I'm not totally clear what's being proposed here. Is this valid? class Foo { static func bar() { … } func baz(other: Foo) { Self.bar()

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: >> >> Not an expert on Obj-C compatibility in Swift by any means, but this >> reads

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

On Apr 21, 2016, at 3:12 PM, Chris Willmore via swift-evolution wrote: > I evaluated the effects of this proposal on five projects written in Swift > against Foundation and other well-audited OS X and iOS Objective-C APIs. The > only changes that had to be made were

Re: [swift-evolution] Guaranteed closure execution

> On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution > wrote: > > Hello Andrew, > > I'm rather embarrassed: the initial design of this proposal was based on a > modifier of @noescape: > > func f(@noescape(once) closure: () -> ()) { … } > > But

Re: [swift-evolution] Rewrite imported C function signatures

Thanks for the explanation, which makes me think that it should be suitable, as you comment, to promote API notes to a “first class” transition technology. As a first approach towards that goal, would it be ok to expand the notion of “bridging headers” to also include API notes? In that case,

Re: [swift-evolution] [Idea] Repurpose Void

> Some people, including me, argue that Void should be removed altogether, > because: > 1) () is more consistent with curried functions: (Int) -> () -> Double > 2) () follows functional programming traditions > > Now, why don't we repurpose Void to follow functional programming traditions > as

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

I think there are some good points here. As a riff, though, I'd argue that Obj-C optional should *not* be renamed to elective or something else. Renaming, so far, has been for the purpose of providing first-class Swifty idioms for existing things. It makes moving between Swift-native code and

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

On Apr 20, 2016, at 10:18 PM, David Owens II wrote: >>> Obviously, given a name to the parameter brings clarity and can be self >>> documenting, but if we want the above to work while making names just as >>> vital as the type signature, then we need to declare `Functor` as

Re: [swift-evolution] multi-line string literals.

let purpleRain =// in remembrance to one of my favorite artists. “What’s wrong with concatenating string constants with “ + “plus-signs, like in this example? \n\n“+ “I am quite happy with doing it this way. ” + “No problem, kind

Re: [swift-evolution] multi-line string literals.

> On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution > wrote: >> I’m trying to avoid more advanced features such as the handling of indenting >> which >> for me complicates something that if kept simple can be documented very >> easily. > > I don't

Re: [swift-evolution] Localization support for string interpolation

> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution > wrote: > > Hi there! > > TL;DR: Here’s my idea for a better localized strings handling in Swift. > It includes both, support for string interpolation support for > NSLocalizedString, and a new string

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> However, I don’t understand how that would help for floating point NaN > behavior. Wouldn’t you have to add a fourth member to the enum (“unordered’) > that all clients would have to handle? An approach like that could make > sense. The point is precisely that there *isn't* an `unordered`

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 4:51 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > However, I don’t understand how that would help for floating point NaN > behavior. Wouldn’t you have to add a fourth member to the enum > (“unordered’) that all clients would have to

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 22, 2016, at 4:05 PM, Vladimir.S wrote: > > After some discussions, I support this proposal and think this will make > Swift more consistent and clear about where is parameters and where is result > type. Especially this important in code like: > Int -> String ->

Re: [swift-evolution] Mutability for Foundation types in Swift

The proposal looks great. ## Introduction Broken link: -- ++ ### New Value

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

+1 I've been missing this myself -Thorsten > Am 25.04.2016 um 04:15 schrieb Rod Brown via swift-evolution > : > > I'm definitely a supporter of this change. It addresses things I've hit > multiple times. > >> On 25 Apr 2016, at 6:34 AM, David Hart via

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

>.. To me, it feel like extra syntax where the -> is already making it very clear that we're dealing with a function... Can't agree with you. I don't think it's "very clear" where the function and where is result type here: Int -> String -> Void -> Float in compare to this: (Int) ->

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

(Sorry to be hijacking a different subthread, but I only just subscribed again to the mailing list) I understand why the proposal has its benefits. Yet, if we look at the SE-0009 rationale, we could apply much of that as an argument against this proposal, e.g. "anything that is widely repeated