Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Susan, > Am 21.07.2016 um 02:19 schrieb Susan Cheng : > > I know and I want to point out that you said value type don't have any thread > safety issues is wrong. I did not mean that, sorry. I meant: calling == on reference types in the standard implementation of

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Susan, > Am 20.07.2016 um 14:14 schrieb Susan Cheng : > > I forgot to reply, a shared value type can capture by multiple closures. > > func twoThreads() -> (Thread, Thread) { > var shared_int = 0 > return (Thread { shared_int = 1 }, Thread { shared_int = 2

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

I forgot to reply, a shared value type can capture by multiple closures. func twoThreads() -> (Thread, Thread) { var shared_int = 0 return (Thread { shared_int = 1 }, Thread { shared_int = 2 }) } Johannes Neubauer 於 2016年7月18日星期一 寫道： > > > Am 18.07.2016 um 06:47

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Allow me to reciprocate the feeling. Java equality isn't particularly relevant to Swift equality, and the majority of issues are already solved. Here's a breakdown of the first link that you posted: "Defining equals with the wrong signature." Impossible in Swift."Changing equals without also

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Félix, We just disagree here and I am confident you are wrong, but I will bring this topic up again in August after Swift 3 has been released. Some literature for you to start with (of course it is not for swift): * http://www.artima.com/lejava/articles/equality.html (from Martin Odersky

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

On Tue, Jul 19, 2016 at 9:00 AM Félix Cloutier wrote: > > Here's one way this could be implemented: if you write `struct Foo: > Equatable` without implementing a `func ==`, the compiler makes one for > you. Done. > I floated a draft proposal a while back that

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

>> This minor enhancement could most likely be obtained by just having a >> default ==, which is a project that I can get behind. > > Structs do not have a common ancestor, this is why swift uses existential > containers, in order to create polymorphic behavior for protocol types with > value

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Von meinem iPhone gesendet > Am 19.07.2016 um 08:51 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 19.07.2016 um 06:29 schrieb Félix Cloutier : >> > 1. You cannot say something is unequal although the system says it is

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 19.07.2016 um 06:29 schrieb Félix Cloutier : > >>> 1. You cannot say something is unequal although the system says it is equal >>> >>> That doesn't make me feel much safer. Comparison returned false when it >>> should have returned true? >> >> Yes you just may

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 19.07.2016 um 00:27 schrieb Xiaodi Wu : > > > > On Mon, Jul 18, 2016 at 5:15 PM, Johannes Neubauer > wrote: > > > Von meinem iPhone gesendet > > Am 18.07.2016 um 23:46 schrieb Xiaodi Wu : > > There are a lot of papers

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

>> >>> 1. You cannot say something is unequal although the system says it is equal >> >> That doesn't make me feel much safer. Comparison returned false when it >> should have returned true? > > Yes you just may have a condition inverted e.g.. You could even have a > compiler flag, where you

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

On Mon, Jul 18, 2016 at 5:15 PM, Johannes Neubauer wrote: > > > Von meinem iPhone gesendet > > Am 18.07.2016 um 23:46 schrieb Xiaodi Wu : > > On Mon, Jul 18, 2016 at 4:27 PM, Johannes Neubauer > wrote: > >> I think this

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

On Mon, Jul 18, 2016 at 4:27 PM, Johannes Neubauer wrote: > I think this discussion goes into the wrong direction. Why are we > discussing now how these types are implemented? It was just stating the > fact, that the swift compiler does not do nothing and swift is a

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

The compiler "will to the forwarding" because the implementation calls the built-in function, not because there is some special case logic in the compiler to treat that type differently from other types. On Mon, Jul 18, 2016 at 2:33 PM, L. Mihalkovic wrote: > > >

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Regards (From mobile) > On Jul 18, 2016, at 9:43 PM, Austin Zheng via swift-evolution > wrote: > > >> On Mon, Jul 18, 2016 at 12:28 PM, Johannes Neubauer via swift-evolution >> wrote: >> Dear Xiaodi, >> >> > Am 18.07.2016 um 20:55

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

I think this discussion goes into the wrong direction. Why are we discussing now how these types are implemented? It was just stating the fact, that the swift compiler does not do nothing and swift is a high-level language. I am a fan of bootstrapping (I implemented some bootstrapping processes

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

You keep saying that floating point types are "basic internal" types, but part of the purpose of having a FloatingPoint protocol and a separate BinaryFloatingPoint protocol is that you can implement your own decimal type without any compiler magic. On Mon, Jul 18, 2016 at 14:28 Johannes Neubauer

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Xiaodi, > Am 18.07.2016 um 20:55 schrieb Xiaodi Wu : > > As mentioned earlier, NaN != NaN, demonstrating that an Equatable instance > that does not always equal itself is not "radical." Plainly, your proposal is > unworkable. 1. this is a basic internal type, so it

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 18:23 schrieb Félix Cloutier : > > >> 1. You cannot say something is unequal although the system says it is equal > > That doesn't make me feel much safer. Comparison returned false when it > should have returned true? Yes you just may have a condition

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

As mentioned earlier, NaN != NaN, demonstrating that an Equatable instance that does not always equal itself is not "radical." Plainly, your proposal is unworkable. On Mon, Jul 18, 2016 at 13:48 Johannes Neubauer via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 18.07.2016 um

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 14:01 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution >> : >> >>> >>> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> 1. You cannot say something is unequal although the system says it is equal That doesn't make me feel much safer. Comparison returned false when it should have returned true? Step into, see why it happened. Sounds like your garden variety of bugs. The downside is that every comparison now

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution > : > >> >> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic : >> >> IMHO implementing your proposal would close the door on some of the things >> you do when building

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic : > > IMHO implementing your proposal would close the door on some of the things > you do when building in-memory dbs (T == U -> TRUE for T not related to U), > which if swift remains for small apps is not a terrible

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

IMHO implementing your proposal would close the door on some of the things you do when building in-memory dbs (T == U -> TRUE for T not related to U), which if swift remains for small apps is not a terrible loss, but may be more of an issue for one day doing big-data with it. Regards (From

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

See below... > Am 18.07.2016 um 12:08 schrieb Johannes Neubauer via swift-evolution > : > > Dear Félix, > > As a small follow-up, because you asked what I am protecting you from. > Dictionaries and Sets, for instance, will work only, if equality and hash > value

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Félix, As a small follow-up, because you asked what I am protecting you from. Dictionaries and Sets, for instance, will work only, if equality and hash value are computed contract conform. As soon as you let (unintendedly) differing values collapse or same values break up, you will have

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 06:47 schrieb Susan Cheng : > > so, you want to propose default == operator but not forbidding all peoples to > custom == operator? > Why don't just adding the following function to std library? > > public func == (lhs: T, rhs: T) -> Bool { > var

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 18.07.2016 um 03:51 schrieb Félix Cloutier : > > Your initial rationale no longer makes sense with your suggested solution. If > the dumb comparison returns false, people can still introduce side effects in > the comparison method, except that now it's even harder to

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

so, you want to propose default == operator but not forbidding all peoples to custom == operator? Why don't just adding the following function to std library? public func == (lhs: T, rhs: T) -> Bool { var lhs = lhs var rhs = rhs return memcmp(, , sizeof(T.self)) == 0 } Thread

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Your initial rationale no longer makes sense with your suggested solution. If the dumb comparison returns false, people can still introduce side effects in the comparison method, except that now it's even harder to find out because all of my equality tests have been rewritten as "memcmp(a, b)

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 17.07.2016 um 15:11 schrieb Brent Royal-Gordon : > >> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution >> wrote: >> >> 1. Custom implementation of equals operator `==` for value types should be >> forbidden. Rationale:

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution > wrote: > > 1. Custom implementation of equals operator `==` for value types should be > forbidden. Rationale: Why has it been added in the first place? For omitting > some values from the equals

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

In order to prevent false-negatives for reference types, I would like to add a 5th. point to my proposals: 5. Identity (i.e. `===`) should be checked even for reference types upfront and only if it returns `false` the custom `==` function of the developer is executed. This way you cannot

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Saagar, > Am 15.07.2016 um 19:05 schrieb Saagar Jha : > > Equatable, where the == operator is defined, will not let you compare two > things of a different type. This is not true for reference types. Consider the following **bad** (but compiling code): ```swift

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Susan, I wrote the former mail in a hurry: the URI example from before is a *false-positive* either and can be handled like the `Polar` example. But the problem with false-negatives are still valid. Example: ```swift func ==(lhs: A, rhs: B) { if(globalBooleanVarIsDayEven) { return

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 16.07.2016 um 03:53 schrieb Susan Cheng : > > How about Polar(r: 0, phi: 0) ? > It should all equal with any angles if r == 0. In an earlier post I wrote: > And I would do the „standard equality“ upfront even if there is a custom > implementation > and if the

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

How about Polar(r: 0, phi: 0) ? It should all equal with any angles if r == 0. 2016-07-16 0:41 GMT+08:00 Johannes Neubauer via swift-evolution < swift-evolution@swift.org>: > > > Am 15.07.2016 um 18:29 schrieb Saagar Jha : > > > > Here's a value type that uses custom

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 19:05 schrieb Saagar Jha : > > Equatable, where the == operator is defined, will not let you compare two > things of a different type. I know that. I mean, this is what I meant with „Swift does a hard job to enforce this“. > On Fri, Jul 15, 2016 at

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Equatable, where the == operator is defined, will not let you compare two things of a different type. On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer wrote: > > > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution < > swift-evolution@swift.org>: > > > > >

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha : >> >> Here's a value type that uses custom equality (at least, I think so): >> String. Since it uses extended

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:29 schrieb Saagar Jha : > > Here's a value type that uses custom equality (at least, I think so): String. > Since it uses extended grapheme clusters, internally two Strings may be > composed of different Unicode scalars, but if they create the same

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:12 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 15.07.2016 um 15:19 schrieb Shawn Erickson : >> >> Additional two "things" maybe considered equal in the chosen problem domain >> despite their identity (memory

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Here's a value type that uses custom equality (at least, I think so): String. Since it uses extended grapheme clusters, internally two Strings may be composed of different Unicode scalars, but if they create the same Characters they are considered to be equal. On Fri, Jul 15, 2016 at 09:12

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 15:19 schrieb Shawn Erickson : > > Additional two "things" maybe considered equal in the chosen problem domain > despite their identity (memory location, etc.) being different. Having the > ability to supply custom hash and equality for types can be a

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Additional two "things" maybe considered equal in the chosen problem domain despite their identity (memory location, etc.) being different. Having the ability to supply custom hash and equality for types can be a useful tool in a developers toolbox. For example two pathways of code may create what

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Hello Johannes, > Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution > : > > 1. Custom implementation of equals operator `==` for value types should be > forbidden. Rationale: Why has it been added in the first place? For omitting > some values

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Hi Austin, > Am 15.07.2016 um 00:35 schrieb Austin Zheng : > > Additive proposals are out of scope for Swift 3; you'll have better luck if > you come back around August and propose these one at a time. Ok. I didn’t know that proposals can be only for the next release. I

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Additive proposals are out of scope for Swift 3; you'll have better luck if you come back around August and propose these one at a time. I don't see the need for "poor man's existentials" - existential improvements are out of scope for the next release, and there are already a bunch of designs

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Hi Daniel, I will answer backwards, since it is easier for me this way. > Am 14.07.2016 um 22:47 schrieb Daniel Resnick : > > Furthermore, why should properties pointing to reference types always use > `===`? What if the reference type conforms to `Equatable`? I

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Forbidding custom `==` for value types would break equality for all Swift collection types, since they use reference types behind the scenes for storing memory and copy on write semantics. Furthermore, why should properties pointing to reference types always use `===`? What if the reference type

[swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Evolutionaries, First off, I like Swift! I have some proposals for swift 3ff. (since the `++` operator is discouraged ;) ): 1. Custom implementation of equals operator `==` for value types should be forbidden. Rationale: Why has it been added in the first place? For omitting some values