Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Am 26.10.2016 um 00:08 schrieb Anton Zhilin via swift-evolution > : > > Why can't we just remove distinction between operator and identifier symbols? > I'd be fine with the following: > > ```swift > infix operator map > infix func map(lhs: [Int], rhs: (Int) ->

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

Von meinem iPhone gesendet > Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution > : > > > > ~Robert Widmann > > 2016/09/26 16:29、sergio via swift-evolution > のメッセージ: > >> HI all, >> >> a debate has recently taken

Re: [swift-evolution] Renaming for Protocol Conformance

Von meinem iPhone gesendet > Am 02.09.2016 um 17:56 schrieb Thorsten Seitz via swift-evolution > : > >> Am 24.08.2016 um 21:35 schrieb Xiaodi Wu via swift-evolution >> : >> >>> On Wed, Aug 24, 2016 at 1:59 PM, Jonathan Hull

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

MfG Johannes Neubauer Von meinem iPad gesendet > Am 30.08.2016 um 08:43 schrieb Goffredo Marocchi via swift-evolution > : > > The problem is, if I have to reimplement this thing in every single project I > touch, that's a huge impact. I shouldn't have to copy &

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

Dear Jiannan, > Am 11.08.2016 um 16:52 schrieb Cao, Jiannan via swift-evolution > : > > > Some ones proposal have always been accepted very quickly even though it is > not fully discussed. > > I don't know why. > > so if some one always focus on swift-evolution

Re: [swift-evolution] Location of ! in Boolean negation expressions

I think your syntax is too near to forced unwrapping. It's just do I put the ! Before or after the dot. This becomes even harder to read if you want to use both at the same time. Then you end up with !.! Further on, if you want to negate a complete expression, the ! Is again before the

Re: [swift-evolution] Improved value and move semantics

> Am 05.08.2016 um 17:17 schrieb Joe Groff : > >> >> On Aug 4, 2016, at 11:31 AM, Johannes Neubauer wrote: >> >>> >>> Am 04.08.2016 um 20:21 schrieb Joe Groff : >>> On Aug 4, 2016, at 11:20 AM, Johannes Neubauer

Re: [swift-evolution] Improved value and move semantics

> Am 04.08.2016 um 20:21 schrieb Joe Groff : > >> >> On Aug 4, 2016, at 11:20 AM, Johannes Neubauer wrote: >> >> >>> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution >>> : >>> On Aug 4, 2016,

Re: [swift-evolution] Improved value and move semantics

> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution > : > >> >> On Aug 4, 2016, at 9:39 AM, Joe Groff wrote: >> >>> >>> On Aug 3, 2016, at 8:46 PM, Chris Lattner wrote: >>> >>> On Aug 3, 2016, at 7:57 PM,

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

+1 for Discourse. It is much more accessible. When I subscribed to swift-evolution I was curious how bigger discussions would work since I used mailing-lists only for small teams yet. After some replies to a thread it started to get really ugly to quote relevant parts of several old posts and

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

+1 to move away from mail ;). Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack extensively. [0]: https://slack.com/ [1]: http://www.teamwire.eu/ Von meinem iPhone gesendet > Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution > : > >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Am 23.07.2016 um 06:34 schrieb Stephen Canon via swift-evolution > : > >> The point of this design is that `===` means identity and that `.same ` >> also means identity. >> >> Since this is new territory I suppose we get to decide what identity >> means for

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

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

Von meinem iPhone gesendet > Am 19.07.2016 um 08:51 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > > >> Am 19.07.2016 um 06:29 schrieb Félix Cloutier <felix...@yahoo.ca>: >> >>>> >>>>>

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

t;> implement equality, that is **not reflexive**. >> >> Swift (AFAIK) has three goals: >> >> 1. simplicity >> 2. performance >> 3. safety >> >> Allowing things like NaN != NaN in custom value types **without** even >> flagging it with 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

performance 3. safety Allowing things like NaN != NaN in custom value types **without** even flagging it with a keyword like `iknowthisisdangerousbutiknowwhatido`, is against goal 3. All the best Johannes > > > On Mon, Jul 18, 2016 at 13:48 Johannes Neubauer via swift-evolution > &

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

n my book, radical changes should be considered with > extreme skepticism, and should have an extremely compelling case behind them. First off, I don’t think, that the changes are that radical and second this example gives a small insight how bad you can implement equality in swift: >>> Am 16.0

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 > <swift-evolution@swift.org>: > > >> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution >> <swift-evolution@swift.org>: >> >>> >>> 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

> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > >> >> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic <laurent.mihalko...@gmail.com>: >> >> IMHO implementing your proposal would close the door o

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

Jul 18, 2016, at 12:21 PM, Johannes Neubauer via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> See below... >> >>> Am 18.07.2016 um 12:08 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

See below... > Am 18.07.2016 um 12:08 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > > 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

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

. **That** will be bugs hard to find. All the best Johannes > Am 18.07.2016 um 11:50 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > > >> Am 18.07.2016 um 03:51 schrieb Félix Cloutier <felix...@yahoo.ca>: >> >> Your initial

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

operator-methods (or any other) as well as a `default` clause for reference types, so that equality of mixed-types just result in `false`, so that this is not possible anymore (see excerpt of discussion): > Am 16.07.2016 um 15:18 schrieb Johannes Neubauer via swift-evolution > <swift-evolutio

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 <br...@architechies.com>: > >> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> 1. Custom implementation of equals operator `==` for valu

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

implement an equals operator, that says two objects are **not** equal although they are the very same instance. > Am 16.07.2016 um 13:50 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > > I wrote the former mail in a hurry: the URI example from bef

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

On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer <neuba...@kingsware.de> wrote: > > > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution > > <swift-evolution@swift.org>: > > > > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha <saagarj

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 > <swift-evolution@swift.org>: > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha <saagarjh...@gmail.com>: >> >> Here's a value type that uses custom equality (at least, I thi

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 > <swift-evolution@swift.org>: > > >> Am 15.07.2016 um 15:19 schrieb Shawn Erickson <shaw...@gmail.com>: >> >> Additional two "things" maybe considered equal in the chos

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

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

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

[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