Re: [swift-evolution] Equatability for enums with associated values

That seems pretty close to Rust’s derive. Why not invent a similar syntax in Swift? Otherwise it will make us look through all the sources to make sure deriving is used. enum Option: @derive Equatable { ... } Also, we can get better looking compilation errors, like: ERROR at line 1, col 14:

Re: [swift-evolution] Equatability for enums with associated values

Sent from my iPhone > On Jan 13, 2017, at 13:51, Adam Shin via swift-evolution > wrote: > > When using enums with associated values, it's often necessary to check for > equality between two enum objects in some way. That can lead to boilerplate > code like this:

Re: [swift-evolution] Equatability for enums with associated values

A million yes-es please. l8r Sean > On Jan 13, 2017, at 1:51 PM, Adam Shin via swift-evolution > wrote: > > When using enums with associated values, it's often necessary to check for > equality between two enum objects in some way. That can lead to boilerplate >

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 1:10 PM, Anton Zhilin via swift-evolution > wrote: > > That seems pretty close to Rust’s derive. Why not invent a similar syntax in > Swift? Otherwise it will make us look through all the sources to make sure > deriving is used. > > enum

[swift-evolution] Equatability for enums with associated values

When using enums with associated values, it's often necessary to check for equality between two enum objects in some way. That can lead to boilerplate code like this: enum Option { case foo(String) case bar(Int) case zip } func ==(lhs: Option, rhs: Option) -> Bool { switch (lhs, rhs)

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 1:15 PM, Tony Allevato via swift-evolution > wrote: > > This is a request that comes up frequently; I wrote an early draft proposal > for it several months ago, with it covering all value types, not just enums, > and also including Hashable as

Re: [swift-evolution] Range and ClosedRange

FWIW, the common RangeProtocol unifying both Range and ClosedRange existed for a while when the new collection indexing model was being implemented. Here is the commit removing it: https://github.com/apple/swift/pull/2108/commits/8e886a3bdded61e266678704a13edce00a4a8867

Re: [swift-evolution] Equatability for enums with associated values

+1, with the caveat that you should still have to explicitly mark it Equatable. I think the “when all their associated values were Equatable” is the technical issue holding this type of thing up. The ability to spell that type of thing is on the generics roadmap, but I don’t know when it will

Re: [swift-evolution] Equatability for enums with associated values

This is a request that comes up frequently; I wrote an early draft proposal for it several months ago, with it covering all value types, not just enums, and also including Hashable as well as Equatable: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad Since it's purely additive,

[swift-evolution] [Proposal] Allow scoped properties from within computed properties

Hi, I've done a lot of Objective-C and have been been a fan of Swift since it's come out, however, there's a small feature of Objective-C that I would really like to see implemented in Swift: In Objective-C you have a few options implementation-wise when creating properties for your class. You

Re: [swift-evolution] [Proposal] Allow scoped properties from within computed properties

> On Jan 13, 2017, at 11:27, Joseph Newton via swift-evolution > wrote: > > Hi, > > I've done a lot of Objective-C and have been been a fan of Swift since it's > come out, however, there's a small feature of Objective-C that I would really > like to see

Re: [swift-evolution] Allow ' in variable/constant names?

Interesting background, I wasn’t aware of that. George. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow scoped properties from within computed properties

There was a proposal for custom behaviors using `@`, which if I recall would offer encapsulation along the lines of what you're proposing. It was an extensively designed system which was deferred for consideration, but which would be in scope again in phase 2. The proposal is in the

Re: [swift-evolution] Generic Subscripts

> On Jan 12, 2017, at 1:37 PM, Slava Pestov via swift-evolution > wrote: > >> Before I submit it, could someone let me know if adding generics to >> subscripts would influence the ABI? ( still feel pretty clueless in that >> area). > > It won’t change the ABI of

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 12:14 PM, Jonathan Hull via swift-evolution > wrote: > > I think the “when all their associated values were Equatable” is the > technical issue holding this type of thing up. The ability to spell that > type of thing is on the generics

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 15:10, Anton Zhilin via swift-evolution > wrote: > > That seems pretty close to Rust’s derive. Why not invent a similar syntax in > Swift? Otherwise it will make us look through all the sources to make sure > deriving is used. > > enum

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution > wrote: > > [Resending to list with original message removed for length.] > > This is fantastic. Glad to see it take shape. Very neat and insightful to > have trailingZeros on BinaryInteger but

Re: [swift-evolution] protocol-oriented integers (take 2)

Thanks, that's very helpful. Yes, my question was more directed to those situations that can't be optimized away. It's good to know that the maximum total cost is an and and a shift, which is what it sounded like but wasn't made explicit. On Fri, Jan 13, 2017 at 17:25 Stephen Canon

Re: [swift-evolution] Equatability for enums with associated values

> On Jan 13, 2017, at 2:30 PM, David Sweeris via swift-evolution > wrote: > > > On Jan 13, 2017, at 15:10, Anton Zhilin via swift-evolution > > wrote: > >> That seems pretty close to Rust’s derive. Why

Re: [swift-evolution] protocol-oriented integers (take 2)

Hi Xiaodi, > What is the performance penalty as compared to the existing operators? First of all, I don’t have the concrete numbers unfortunately. But… If we are talking about concrete types, there should be very little difference between the two smart and masking shifts. For example, the

Re: [swift-evolution] protocol-oriented integers (take 2)

[Resending to list with original message removed for length.] This is fantastic. Glad to see it take shape. Very neat and insightful to have trailingZeros on BinaryInteger but leadingZeros on FixedWidthInteger. A couple of questions on smart shifts: What is the performance penalty as compared to

Re: [swift-evolution] Range and ClosedRange

On Fri, Jan 13, 2017 at 2:05 PM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > FWIW, the common RangeProtocol unifying both Range and ClosedRange existed > for a while when the new collection indexing model was being implemented. > > Here is the commit removing it:

Re: [swift-evolution] Equatability for enums with associated values

Such a proposed syntax doesn't solve the general problem though, which is that comparing two enum values requires enumerating all of the cases to test whether they are (1) the same and (2) have the same associated values, if any. The desire here is to get rid of the boilerplate that users must

Re: [swift-evolution] Equatability for enums with associated values

I think it is better to create a syntax for getting the associated values and then comparing them. enum Option { case foo(String) case bar(Int) case zip } let op = Option.foo("hello") let bb = Option.foo("world") // proposed tuple-like syntax op.foo.0 // returns Optional("hello") // then we

Re: [swift-evolution] [Pitch] Named subscripts 2

Thank you for your answer, but i just feel that options should be a property. I'm ok with my current solution but it can be simplified with named subscript.___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] protocol-oriented integers (take 2)

Great work, all. I'm not sure I ever commented on SE-0104, so I've read through this one more carefully. Here are some things that came to mind: *## Arithmetic* Why are ExpressibleByIntegerLiteral and init?(exactly:) required? I could understand needing access to 0, but this could be provided by

Re: [swift-evolution] Generic Subscripts

> On Jan 13, 2017, at 9:50 AM, John McCall via swift-evolution > wrote: > > I'm also not sure we'd ever want the element type to be inferred from context > like this. Generic subscripts as I see it are about being generic over > *indexes*, not somehow about

[swift-evolution] [Pitch] Named subscripts 2

Hello Swift community, I found this very useful while wrapping c api, although this may simplify the code in other cases when subscript doesn't have it's own state and(or) share some state form the container. here is an example:

Re: [swift-evolution] Range and ClosedRange

I read this great post. But it shows an example where the problem is circumvented because the algorithm can work on a more general protocol. But the problem still persists for algorithms which make sense for any countable range (open and closed). > On 13 Jan 2017, at 02:57, Adriano Ferreira

Re: [swift-evolution] Throws? and throws!

I can see the appeal, but really throwable errors are just one kind of error that can happen in code. Preconditions are a different thing. They represent axioms that must be kept for a sane program. It’s up to the programmer to decide whether something should be treated as an axiom or

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 2:58 PM, Jonathan Hull via swift-evolution > wrote: > > I really like swift’s error handling system overall. It strikes a good > balance between safety and usability. > > There are some cases where it would be nice to throw errors, but errors

Re: [swift-evolution] Throws? and throws!

> On 13 Jan 2017, at 17:10, Joe Groff via swift-evolution > wrote: > > >> On Jan 12, 2017, at 2:58 PM, Jonathan Hull via swift-evolution >> wrote: >> >> I really like swift’s error handling system overall. It strikes a good >> balance