Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

> I have a small remark though, wouldn’t it be better to let transform be of > type (Key, Value) throws -> T instead of (Value) throws -> T? You can just > ignore the key (with _) if you don’t need it, but I think it might come in > handy in some cases. The problem is, that closes the door to

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Sorry, I misspoke. I just meant define it like this: public enum IntegerSign : Int { case Negative = -1 case Zero = 0 case Positive = 1 public var signum: T { return T(self.rawValue.toIntMax()) } } Although, come to think of it, I’m not sure if that’s an exact drop-in

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

> Earlier e-mail example: >> let foo = >> "positive" where ( bar > 0 ) ?? >> "negative" where ( bar < 0 ) ?? >> "zero" > > let foo = bar > 0 ? "positive" : > bar < 0 ? "negative" : > "zero" See, this just makes me want to remix ternary...

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md ] Hi, Tony. Thanks for working on this. I have to say I’m incredibly

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

In UIKit/Cocoa, there's CGFloat that does pretty much what you're asking (and it's pain working with it in Swift, since it's Double on 64-bit computers, while Swift defaults to Float, so you need casting all the time)... And I think the default behavior of Swift should be similar. I wouldn't

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Sure, that's a good idea, though I'd personally use the signum var, since using rawValue seems like a bit of an abuse of the fact the enum is defined this way and doesn't help readability of the code: enum IntegerSign: RawRepresentable { case Negative case Zero case Positive

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

The proposal also suggests: extension _ObjectiveCBridgeable { init?(bridging object: AnyObject) } Which would yield: let foo: AnyObject = NSString(string: "String") let bar = String(bridging: foo) // “String" let foo2: AnyObject = NSArray(array: []) let bar2 = String(bridging: foo) // nil

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

Right... per "[swift-evolution] [Idea] Find alternatives to `switch self`" it was only "impossible" in my head. Thanks Dany This proposal is unnecessary. On Mon, May 23, 2016 at 8:53 PM, char...@charlesism.com < charlesism@gmail.com> wrote: > I'm not actually familiar with the term "tri

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 18:07, plx via swift-evolution > wrote: > > How hard would it be to e.g. simply allow something like this: > > func ==(lhs: T, rhs: T) -> Bool { >return lhs T.== rhs > } > > …instead of the `T.==(lhs,rhs)` syntax? Yeah, I've been

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

Good grief. I think you're right. Some how, a long time ago, I got it into my head that the order in which each part of the ternary got evaluated would cause problems for this kind of thing. I've had a huge blindspot and I've been railing on the list for something I don't need for weeks. Wow, I

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Can we make it RawRepresentable? That way signum can just return self.rawValue Sent from my iPhone > On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution > wrote: > > The clean way would be to make it an enum with var signum that would return > -1, 0, 1: >

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md ] Some comments on Nicola’s points (my own comments to come separately):

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On May 23, 2016, at 9:55 PM, Xiaodi Wu wrote: > > On Mon, May 23, 2016 at 9:40 PM, David Sweeris > wrote: > > Have we (meaning the list in general, not you & me in particular) had this > conversation before? This feels

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

Let’s see… let name = plist[“name”].bridge() as String Not the worst, but definitely better than any of the alternatives below. Unfortunately, I think that “if” is out of the question, at least for Swift 3. Jordan > On May 23, 2016, at 20:21, Jed Lewison wrote: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

If we could have extensions on AnyObject, a simple .bridge() would do the trick, right? (Assuming bridge was generic.) I think something along those lines was mentioned in the proposal. Sent from my iPhone > On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution >

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 23, 2016, at 13:10, Антон Жилин via swift-evolution > wrote: > > @CoreTeam Please, don't forget to merge pull request with fixes and > alternatives from review period. > > @AnyoneElse Today is (formally) the last day of review. It may be your last >

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On Mon, May 23, 2016 at 9:40 PM, David Sweeris wrote: > On May 23, 2016, at 8:18 PM, Xiaodi Wu wrote: > > > > Int is the same size as Int64 on a 64-bit machine but the same size as > Int32 on a 32-bit machine. By contrast, modern 32-bit architectures

Re: [swift-evolution] Enhanced existential types proposal discussion

> One initial bit of feedback - I believe if you have existential types, I > believe you can define Sequence Element directly, rather than with a type > alias. e.g. > > protocol Sequence { > associatedtype Element > associatedtype Iterator: any IteratorProtocol.Element==Element> >

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On May 23, 2016, at 8:18 PM, Xiaodi Wu wrote: > > Int is the same size as Int64 on a 64-bit machine but the same size as Int32 > on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that > handle 64-bit and even 80-bit floating point types. Therefore, it

Re: [swift-evolution] Make access control private by default.

> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution > wrote: > > I was just about to mention this too. I think it's interesting that > one can write a simple application in Swift without having to worry > (much) about visibility of elements. Please

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I’ll fix that. I also forgot to change Impact on existing code section. I’ll do that when Austin had time to look at it. This proposal will break protocol A: class {} if we get protocol A: Any {} as replacement. --  Adrian Zubarev Sent with Airmail Am 23. Mai 2016 bei 02:52:31, Matthew

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

> Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution > a écrit : > > I wrote some code tonight to experiment with this kind of thing. I apologize > if it's off-topic for the thread, but it might be useful to others who want > to experiment. > > > >

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution wrote: > Dunno about other IDEs, but Xcode's syntax highlighting can change the size, > typeface (bold, italic, etc), and even the font. You can make instance > variables show up as 24pt comic sans,

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Int is the same size as Int64 on a 64-bit machine but the same size as Int32 on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that handle 64-bit and even 80-bit floating point types. Therefore, it does not make sense for Float to be Float32 on a 32-bit machine, as would be

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

Why reinvent the wheel, when the old trusty (but a bit cryptic according to some) tri-op can do the trick… > Le 23 mai 2016 à 04:29, Charles Constant via swift-evolution > a écrit : > > Here's a few examples of what this change would allow. > > I just plucked the

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

I'd prefer they mirror the integer type naming "conventions", that is have an explicit "Float32" and "Float64" type, with "Float" being a typealias for Float64. Sent from my iPhone > On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution > wrote: > > Hi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

I am way late, but I share Brent’s concerns. I don’t think this addresses the very common case of “getting a String out of a heterogeneous dictionary”. let name = plist[“name”] as! String becomes one of these: let name = plist[“name”] as! NSString as String let name = String(plist[“name”] as!

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

That is correct, the proposed change only applies to the concrete slice types that are provided by the standard library. Max > On May 23, 2016, at 5:13 PM, Jordan Rose wrote: > > [Proposal: >

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md ] Hey, Max. For clarification, this isn’t adding anything to the requirements for slice types, correct? That is,

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Hi everyone, Is there any draft/proposal related to this suggestion? Best, — A > On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution > wrote: > > Hi all, > > I'm curious how other members of the Swift community feel about the clarity > of the "Double"

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

> On May 23, 2016, at 12:12 PM, Charlie Monroe via swift-evolution > wrote: > >> If the URL path property was defined not to return ‘String?' but to return >> ‘Any’ (which can of course hold an Optional just like it can hold any other >> type) what would the

Re: [swift-evolution] Winding down the Swift 3 release

On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution wrote: > The collection model, API guidelines and standard library are actually > irrelevant to the ABI. The standard library API and the Swift ABI are > distinct orthogonal concepts. I’m not sure what

[swift-evolution] [Amendment] SE-0022: Referencing the Objective-C selector of a method

Hi everyone. Accepted proposal SE-0022, "Referencing the Objective-C selector of a method", has been amended with the following changes: https://github.com/apple/swift-evolution/commit/1dfd6cd4fc2e9874d5db8aef6a5f41d6556b2ca2 Alex Hoppen, who undertook the work to implement the related

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

On Mon, May 23, 2016, at 03:15 PM, Max Moiseev wrote: > Hi Kevin, > > Thanks for reviewing this proposal. > > It is my poor choice of words to be blamed for the confusion. There is > definitely no reason for the new property to only be available for the > MutableRandomAccessSlice type.

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

Hi Kevin, Thanks for reviewing this proposal. It is my poor choice of words to be blamed for the confusion. There is definitely no reason for the new property to only be available for the MutableRandomAccessSlice type. Moreover, since all the slice types are generated with GYB now, it would

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

On Thu, May 19, 2016, at 04:43 PM, Dave Abrahams via swift-evolution wrote: > * What is your evaluation of the proposal? The motivation sounds reasonable, as does the solution. But it seems odd to expose a property `base` on MutableRandomAccessSlice without exposing it on any other slice

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 23.05.2016 21:41, Charles Srstka via swift-evolution wrote: Plus, I might end up having to use a different source editor sometimes, particularly when I’m doing a large refactor and Xcode is stuck in its “SourceKitService crash every time two characters are typed” thing. I’d really rather have

Re: [swift-evolution] Make access control private by default.

> Le 23 mai 2016 à 23:21, Knut Lorenzen via swift-evolution > a écrit : > > >> On 19 May 2016, at 19:18, John McCall wrote: >> >> That is not at all true. The dynamic OOP languages do not, as a rule, have >> any access control at all. Java

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Bikeshedding: Is it grammatically possible (or even desirable) to skip the “any” token and just have something like this: var view: init(view: ) {} if let mergedValue = button as? {} let a:

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Fixed a few things: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md Tell me if I left out any topic or detail. --  Adrian Zubarev Sent with Airmail Am 23. Mai 2016 bei 12:08:45, Adrian Zubarev

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On May 23, 2016, at 1:21 PM, Thorsten Seitz wrote: > > >>> Am 23.05.2016 um 19:17 schrieb Matthew Johnson : >>> >>> >>> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution >>> wrote:

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

@CoreTeam Please, don't forget to merge pull request with fixes and alternatives from review period. @AnyoneElse Today is (formally) the last day of review. It may be your last chance! Apple repo link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md My

Re: [swift-evolution] Static Dispatch Pitfalls

On Mon, May 23, 2016 at 12:13 PM, Matthew Johnson wrote: > > On May 23, 2016, at 10:50 AM, Xiaodi Wu wrote: > > On Mon, May 23, 2016 at 6:58 AM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On May 22, 2016, at

Re: [swift-evolution] [Pitch] 'Double modulo' operator

I've had to write a "true mod" function enough times across different projects (usually for circular buffer indexing or angular arithmetic) that it would absolutely support its inclusion in stdlib (for both integer and floating point types). The `%` operator historically has been implemented as

Re: [swift-evolution] [Pitch] 'Double modulo' operator

That kind of breaks backwards compatibility. Also currently in swift, the % operator is called the remainder operator, not the modulo operator, so technically the current implementation is correct. In Haskell for example, there are two functions, rem (as in remainder) and mod (as in modulo). I

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

> Le 22 mai 2016 à 03:07, Adam Nemecek via swift-evolution > a écrit : > > Howdy, > I think that the SignedNumberType should implement a method called sign that > will return -1 for negative numbers, 0 for 0 and 1 for positive numbers. This > is similar to the

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

> If the URL path property was defined not to return ‘String?' but to return > ‘Any’ (which can of course hold an Optional just like it can hold any other > type) what would the proposed compiler behavior be? No warning. Since you cast Optional to Any, no warning can even be issued since that

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 22 2016, Matthew Johnson wrote: > Are you sure that is Sean’s entire point? I take more away from it than that. > Look at slide 13 here: > https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf > > “The

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As another colorblind developer, this kind of is an issue. While I *can* discern colors, the only one that sticks out strongly is blue. If you’ve got reds, greens, browns, or oranges, my experience will be on a continuum from “I think that’s red?” in the best case, “I can figure this out if I

Re: [swift-evolution] Enhanced existential types proposal discussion

Yes, this is probably better founded. Right now Swift doesn't have a blessed nothing type, the closest you can get is enum Nothing { }, and that type doesn't participate in subtyping relationships (it's not really a Bottom type like Scala's). Proposing such an expansion to the type system is

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 23.05.2016 um 18:08 schrieb Austin Zheng : > >> >> I think that *all* methods should be available - at least in principle - >> with associated types >> - replaced by their upper bounds (i.e. Any if no constraints have been given >> either by the protocol

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On May 23, 2016, at 12:26 PM, Robert Widmann wrote: > > The fun part about Nothing (⊥) is that it does have one constructor: crashing. Ok, but where does the part about calling bottom 'Nothing' in Swift come from? This is the first I've heard

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 23.05.2016 um 19:17 schrieb Matthew Johnson : > >> >> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >> >> >> Am 23.05.2016 um 00:18 schrieb Austin Zheng via

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I’m still unclear what the answers to my questions below would be. I’ll restate them below. >>> 1. If I was printing a protocol type that Optional supports, such as Any, >>> would I get a warning? Since this may have been misunderstood, let me phrase it a different way. If the URL path

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 23, 2016, at 11:19 AM, Patrick Smith wrote: > > I just want to highlight the Photoshop history example. I agree you’d want as > much state and memory shared between steps in the history. > > However, I see nothing wrong with having pointers to pixel buffer, and

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 23, 2016, at 9:22 AM, Dave Abrahams wrote: > > > on Sun May 22 2016, Matthew Johnson > wrote: > >>> On May 22, 2016, at 3:42 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Sun May

Re: [swift-evolution] [Pitch] 'Double modulo' operator

Would you want to make this a function? Or an operator but a different one? On Mon, May 23, 2016 at 7:30 AM, Stephen Canon wrote: > I’m not really sold on the `%%` spelling, but I think the operation itself > is worth exposing. This is the remainder of a “flooring” division

Re: [swift-evolution] Proposal: Automatic initializer generation

> On May 23, 2016, at 7:24 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 23, 2016, at 10:52 AM, Kevin Nattinger via swift-evolution >> wrote: >> >> Discussed last month >>

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 23, 2016, at 7:26 PM, David Sweeris wrote: > > > On May 23, 2016, at 11:24, Krystof Vasa via swift-evolution > wrote: > >>> The problem can also be easily mitigated by having the IDE use a different >>> color to display a variable

Re: [swift-evolution] Enhanced existential types proposal discussion

The fun part about Nothing (⊥) is that it does have one constructor: crashing. ~Robert Widmann 2016/05/23 10:17、Matthew Johnson via swift-evolution のメッセージ: > >> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution >> wrote:

Re: [swift-evolution] Proposal: Automatic initializer generation

> On May 23, 2016, at 10:52 AM, Kevin Nattinger via swift-evolution > wrote: > > Discussed last month > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html > And (linked from that thread) last year >

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 23, 2016, at 11:08 AM, Austin Zheng via swift-evolution > wrote: > >> >> I think that *all* methods should be available - at least in principle - >> with associated types >> - replaced by their upper bounds (i.e. Any if no constraints have been given >>

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As a colorblind developer, this isn’t really an issue. The vast majority of colorblind people can discern colors. As long as the IDE allows you to customize which colors it displays, you can find a palette that will work with your eyes (for my type of colorblindness, for instance, I have

Re: [swift-evolution] Proposal: Automatic initializer generation

Thanks for the links. You can't apply auto-init behavior to all classes since it gets a bit more complicated once the only initializers available take some arguments - the compiler can't know what to pass where to super, so it would need to chain the arguments, which would lead to initializers

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> The problem can also be easily mitigated by having the IDE use a different > color to display a variable based on where it was defined (eclipse come to > mind as an example). This is something the brain naturally notices without > paying any conscious attention. Tell that to the colorblind

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I just want to highlight the Photoshop history example. I agree you’d want as much state and memory shared between steps in the history. However, I see nothing wrong with having pointers to pixel buffer, and that affecting the ‘purity’ of the state. The way Photoshop’s history is implemented,

Re: [swift-evolution] Enhanced existential types proposal discussion

> > I think that *all* methods should be available - at least in principle - with > associated types > - replaced by their upper bounds (i.e. Any if no constraints have been given > either by the protocol definition itself or th existential) if in covariant > position and > - replaced by

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution > : > > I agree; the difference between protocols with and without associated types > has been an endless source of confusion for a lot of people. > > Speaking of which, for those who care I rewrote

Re: [swift-evolution] Proposal: Automatic initializer generation

Discussed last month https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html And (linked from that thread) last year http://article.gmane.org/gmane.comp.lang.swift.evolution/727 I think it’s a good idea, but discussion seems to have just petered out without a formal

Re: [swift-evolution] Static Dispatch Pitfalls

On Mon, May 23, 2016 at 6:58 AM, Matthew Johnson wrote: > > > Sent from my iPad > > On May 22, 2016, at 11:55 PM, Xiaodi Wu wrote: > > On Sun, May 22, 2016 at 11:20 PM, Matthew Johnson > wrote: > >> >> On May 22, 2016, at

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I've jotted up a proposal here: https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385 Please let me know if there are any comments to it. Charlie > On May 20, 2016, at 9:11 AM, Krystof Vasa via swift-evolution > wrote: > >> Four questions: >> 1.

[swift-evolution] Proposal: Automatic initializer generation

A lot of initializers tediously assign values to variables which results in a lot of code such as self.variable = arg1 (or even worse variable = variable), mostly for classes that are meant to just encapsulate several values. I propose adding auto keyword (to be discussed - anyone has a better

Re: [swift-evolution] Initialiser Helper

You could move getAge() to be a private func outside of the scope of Person? > On 23 May 2016, at 11:24 PM, James Campbell via swift-evolution > wrote: > > I would like to be able to use functions to help me initilise a class or > struct so I can break down a init

Re: [swift-evolution] Initialiser Helper

You might be interested in taking a look at my proposal for partial initializers https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md This proposal was tabled for Swift 3 but I hope to revisit the topic of improving initializers in when

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On May 22, 2016, at 5:18 PM, Austin Zheng via swift-evolution > wrote: > > I agree; the difference between protocols with and without associated types > has been an endless source of confusion for a lot of people. > > Speaking of which, for

[swift-evolution] [Pitch] Add `mapValues` method to Dictionary

I really like this idea, because indeed this wasn’t possible functionally before. I have a small remark though, wouldn’t it be better to let transform be of type (Key, Value) throws -> T instead of (Value) throws -> T? You can just ignore the key (with _) if you don’t need it, but I think it

Re: [swift-evolution] Static Dispatch Pitfalls

Sent from my iPad > On May 22, 2016, at 11:55 PM, Xiaodi Wu wrote: > >> On Sun, May 22, 2016 at 11:20 PM, Matthew Johnson >> wrote: >> >>> On May 22, 2016, at 4:22 PM, Xiaodi Wu wrote: >>> On Sun, May 22, 2016 at 3:38

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

The clean way would be to make it an enum with var signum that would return -1, 0, 1: enum IntegerSign { case Negative case Zero case Positive var signum: NumberType { switch self { case .Negative: return -1 as NumberType case .Zero:

Re: [swift-evolution] Winding down the Swift 3 release

> On 19 May 2016, at 10:47, Brent Royal-Gordon wrote: > >> Is completing the generic system fundamental or not? I’d say it is vastly >> more fundamental than removing C style for loops, wouldn’t you? > > Oh, come on. Removing the C-style for loop is not what took up