Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 10 Aug 2017, at 00:08, Chris Lattner via swift-evolution > wrote: > > • What is your evaluation of the proposal? Generally positive, but I don't feel that conforming to Equatable/Hashable is sufficient as an opt-in. Consider for example someone who declares their type as Equatable

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Hi Haravikk, Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution: I don't feel that conforming to Equatable/Hashable is sufficient as an opt-in. Consider for example someone who declares their type as Equatable/Hashable, then sets to work on the details of their type, forgetting to impleme

Re: [swift-evolution] Draft: Regular Expression in Swift

Hi Joshua, Thanks for bringing this topic up. It may help to outline why regular expressions were deferred until Swift 5. The work to create a regular expression type itself, and even to add a regex literal protocol, is fairly straightforward and probably could have been done in the Swift 4 ti

Re: [swift-evolution] Draft: Regular Expression in Swift

Hi Joshua, I also feel a huge gap when it comes to string matching, whether it is implementation or performance. I also wrote a library for String matching called StringMap and it has been way for performant than regular expressions. I recently proposed to include it in core foundation but it se

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 10 Aug 2017, at 10:32, Martin Waitz wrote: > > Hi Haravikk, > > Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution: >> I don't feel that conforming to >> Equatable/Hashable is sufficient as an opt-in. Consider for example >> someone who declares their type as Equatable/Hashable, the

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Huge +1 This should have been there from Swift 1, and basically forced me to use Sourcery to automatically generate all that code. Elviro > Il giorno 10 ago 2017, alle ore 01:09, Chris Lattner via swift-evolution > ha scritto: > > Hello Swift community, > > The review of SE-0185 - "Synthes

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

Imho this topic was much better than that other one ;-) — and I just realised that of metaprogramming build on top of reflection wasn't discussed in its own thread yet… I fear "constexpr" is already burned, because people associate it with things like calculating Fibonacci numbers at compile tim

Re: [swift-evolution] Enums and Source Compatibility

Since it seems to have been lost in the noise, I want to second with support for Xiaodi's syntax of having `default` appearing in the enum declaration itself. It's much clearer in its intention, feels very ‘Swifty’, and more importantly it doesn't prompt whole threads debating the semantics of

Re: [swift-evolution] private extension

> I agree, but after having originally raised the issue, members of the core > team clearly disagreed. Therefore, it's clear that this is going to have to > go through Swift Evolution or not be changed at all. And I also agree with > the notion that further discussions of access modifiers, whic

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution > wrote: > > Since it seems to have been lost in the noise, I want to second with support > for Xiaodi's syntax of having `default` appearing in the enum declaration > itself. > > It's much clearer in its intention, feels very

Re: [swift-evolution] private extension

FWIW, I can't agree that this particular subject leads to huge discussion/battle about all the access modifiers. It is just about 'private extension' inconsistency, not more. And it seems like there no(?) opinions that current situation with private extension has any sense. It really looks like

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 16:46, Matthew Johnson via swift-evolution wrote: On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution wrote: Since it seems to have been lost in the noise, I want to second with support for Xiaodi's syntax of having `default` appearing in the enum declaration itself.

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 9:25 AM, Vladimir.S wrote: > > On 10.08.2017 16:46, Matthew Johnson via swift-evolution wrote: >>> On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> Since it seems to have been lost in the noise, I want to seco

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 3:58, Jordan Rose wrote: Hi, Vladimir. I think framing this as a consumer decision is the wrong place to start. There are some enums that definitely make sense to be "closed", all the time, with no additional annotations, including Foundation.NSComparisonResult and, well, Swift.Op

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Thu, Aug 10, 2017 at 3:40 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 10 Aug 2017, at 10:32, Martin Waitz wrote: > > Hi Haravikk, > > Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution: > > I don't feel that conforming to > Equatable/Hashable is sufficient

Re: [swift-evolution] Enums and Source Compatibility

I think this design does not avoid you writing something like `private enum Foo { default ... }`, which is redudant as Jordan already pointed out in his previous post, nor does it have a consistent way of declaration: enum Foo { case abc case def default } enum Foo { case abc default

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> My hunch is that structs and enums where such volatile data exists are the > exception, not the norm, when it comes to considering equality. This > proposal is very much intended to be useful syntactic sugar for the common > case while not preventing any existing behavior (providing your own > im

Re: [swift-evolution] Draft: Regular Expression in Swift

Disclaimer: I am not well versed in the various complexities of regex implementations. That being said, I would very much like to see better regex support in Swift. Preferably one that is easier to pick up than the NSRegularExpression of ObjC and possibly as easy to start using as python or rub

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 18:22, Adrian Zubarev via swift-evolution wrote: I think this design does not avoid you writing something like `private enum Foo { default ... }`, which is redudant as Jordan already pointed out in his previous post, nor does it have a consistent way of declaration: Why compiler

Re: [swift-evolution] private extension

Vladimir, please follow the link for the previous discussion. There are several reasons outlined by core team members why they felt this was not a bug, so it is definitely not the case that there are no opinions to that effect. It was a very thorough conversation on the topic, and I’m not sure what

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 9, 2017, at 22:46, David Hart wrote: > > >> On 10 Aug 2017, at 02:42, Jordan Rose > > wrote: >> >> :-) As you've all noted, there are some conflicting concerns for the default: >> >> - Source compatibility: the existing behavior for an unannotated enum

Re: [swift-evolution] Draft: Regular Expression in Swift

I guess everyone agrees that there should be support for regular expressions - I'm just not sure where, how and when to integrate it… People seem to have a (sometimes unhealthy…) passion for regex, so I'd like to encourage a critical look on their importance. For example, I don't think they belon

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md ] Hi, Tony. Glad to see this back again! Overall I'm an enthusiastic +1. The res

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 09:15, Vladimir.S via swift-evolution > wrote: > > On 10.08.2017 18:22, Adrian Zubarev via swift-evolution wrote: >> I think this design does not avoid you writing something like `private enum >> Foo { default ... }`, which is redudant as Jordan already pointed out in hi

Re: [swift-evolution] Draft: Regular Expression in Swift

> On Aug 10, 2017, at 11:48 AM, Tino Heth via swift-evolution > wrote: > > I guess everyone agrees that there should be support for regular expressions > - I'm just not sure where, how and when to integrate it… > People seem to have a (sometimes unhealthy…) passion for regex, so I'd like > to

Re: [swift-evolution] Draft: Regular Expression in Swift

Thank you for bringing this up! Swift String has a lot of expressivity gaps we’re trying to tackle in Swift 5. I think that both language and library support for flexible matching and transformation is needed, likely through a regex-like construct. Libraries and prototypes like this help drive t

Re: [swift-evolution] Draft: Regular Expression in Swift

To me, regexes definitely feel like they belong in Foundation. Also, I don’t think they’d be well-served by a literal syntax (even just ExpressibleByStringLiteral) because this privileges using the default regex options over specifying non-default options. The compilation issue seems a bit tri

[swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors: struct Snort: Hashable { static var hashValu /* NOTE MISSPELLING */ : Int { return 666 } } In the above example, the programmer meant to

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the mo

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution > wrote: > > I could have sworn that this sort of issue came up on this list earlier this > year… Someone proposed a mechanism encompassing all protocols, not just > Equatable and Hashable, to handle the issue of mistakenly be

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable,

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 19:19, Jordan Rose wrote: > > > >>> On Aug 9, 2017, at 22:46, David Hart wrote: >>> >>> >>> On 10 Aug 2017, at 02:42, Jordan Rose wrote: >>> >>> :-) As you've all noted, there are some conflicting concerns for the >>> default: >>> >>> - Source compatibility: the ex

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> > • What is your evaluation of the proposal? Very large +1 in general. I really wanted to see this happen in Swift 4. I’m very happy that it’s up for review right at the beginning of the Swift 5 process. That said, I do think the concern others have voiced regarding implicit synthes

Re: [swift-evolution] Enums and Source Compatibility - defaults

Okay I came to the conclusion that this won’t work that easily. Here is my reasoning why I think that way. If one assume for a second that one day we might have value sub typing - yes not now and not in the next Swift version, but hear me out please - we will come back and discuss the alignment

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that. On Thu, Aug 10, 2

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 22:36, Adrian Zubarev > wrote: > > Okay I came to the conclusion that this won’t work that easily. Here is my > reasoning why I think that way. If one assume for a second that one day we > might have value sub typing - yes not now and not in the next Swift version, > bu

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 10, 2017, at 3:52 PM, David Hart via swift-evolution > wrote: > > > > On 10 Aug 2017, at 22:36, Adrian Zubarev > wrote: > >> Okay I came to the conclusion that this won’t work that easily. Here is my >> reasoning why I think that way. If one

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard. Thank you all, - David > On Aug 10, 2017, at 1:51 PM, Xiaodi Wu wrote: > > Ri

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Thu, Aug 10, 2017 at 11:05 AM Jordan Rose wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md > ] > > Hi, Tony. Glad to see this back again! > > Overall I'm an enthusiastic +1. The restrictions and future work you've > list

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

@Xiaodi I have a slightly different view of this. Currently, if you have a type that conforms to a protocol, and you do not need to write any additional code in order for the type to conform to the protocol, then the protocol must have default implementations of its requirements. Because some ty

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

Yes, but to be clear, this is an objection that is equally applicable to any change where a protocol requirement is given a default implementation. Unless I’m mistaken, ordinarily, the addition of such a default implementation isn’t even considered an API change and doesn’t require Swift Evolution

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 10, 2017, at 14:48, Tony Allevato wrote: > > On Thu, Aug 10, 2017 at 11:05 AM Jordan Rose > wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md > >

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

Sorry, I think I misunderstood your earlier email. I believe we are in agreement. > On Aug 10, 2017, at 5:54 PM, Xiaodi Wu wrote: > > Yes, but to be clear, this is an objection that is equally applicable to any > change where a protocol requirement is given a default implementation. > > Unles

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 10, 2017, at 3:40 AM, Haravikk via swift-evolution > wrote: > > This is not the same as a default protocol implementation Actually, I could easily imagine that a future version of Swift with macro support might do this with a default protocol implementation: extension Equatab

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Do you mean something like this, then? ``` struct Foo: Equatable { let x: Int } func test(_ lhs: T, _ rhs: T) -> Bool { return lhs == rhs } extension Foo { static func == (lhs: Foo, rhs: Foo) -> Bool { return lhs.x % 2 == rhs.x % 2 } } print(test(Foo(x: 5), Foo(x: 7))) // true ```

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 10, 2017, at 15:34, Tony Allevato wrote: > > Do you mean something like this, then? > > ``` > struct Foo: Equatable { > let x: Int > } > > func test(_ lhs: T, _ rhs: T) -> Bool { > return lhs == rhs > } > > extension Foo { > static func == (lhs: Foo, rhs: Foo) -> Bool { >

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 9, 2017, at 20:00, Zach Waldowski via swift-evolution > wrote: > > On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote: >> Ah, I forgot to mention: per my response to Charlie, the vast majority of >> enums in ObjC Foundation (80-90%) seem to be "open". I should ha

Re: [swift-evolution] Enums and Source Compatibility

Both you and Vladimir are bringing up this point, with Vladimir explicitly suggesting a "future" case that's different from "default". Again, the pushback we get here is that the "future" case is untestable…but maybe that's still an option worth having. (At the very least, it's worth recording i

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 10, 2017, at 13:00, David Hart wrote: > > > > On 10 Aug 2017, at 19:19, Jordan Rose > wrote: > >> >> >>> On Aug 9, 2017, at 22:46, David Hart >> > wrote: >>> >>> On 10 Aug 2017, at 02:42, Jordan Rose >>>

Re: [swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

This strikes me as another good way to look at it. Thanks guys, - David > On Aug 10, 2017, at 2:54 PM, Robert Bennett wrote: > > @Xiaodi I have a slightly different view of this. Currently, if you have a > type that conforms to a protocol, and you do not need to write any additional > code i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Sent from my iPhone > On Aug 9, 2017, at 10:37 PM, Adrian Zubarev via swift-evolution > wrote: > > Well, if there is one, then I apologize for bothering anyone. I just assumed > it would be included in the proposal itself, and I couldn't find it myself. > ;) This is a good point. We'll up

Re: [swift-evolution] Enums and Source Compatibility - defaults

Hi all, I thought I’d chime in with my own 2c… I’d probably prefer something more like “final” and vs non-final. It’s the concept we’re dancing around - can you add something to extend it? In which case, final would allow exhaustive use, and non-final would require handling the default case. C