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 == in value types, creates
I know and I want to point out that you said value type don't have any
thread safety issues is wrong.
Johannes Neubauer 於 2016年7月20日星期三 寫道：
> 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.
> >
> >
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 })
> }
You are not sharin
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 schrieb Susan Cheng >:
But I don't want swift force using default equal comparator before my
implementation when I knew it was redundant that everything checking twice.
I have wrote lots of structure type with cache object for lazy evaluation.
All of them dose not need to compare the cache object.
Johannes Neubauer 於
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 cha
Dear Tony,
> Am 19.07.2016 um 18:10 schrieb Tony Allevato :
>
> I floated a draft proposal a while back that addressed exactly this use case:
>
> https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad
I will take a look at it, thank you very much.
> It's purely additive so it's eff
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 e
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 addressed exactly this use
case:
ht
>> 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
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
> equal
That doesn't make me feel
> 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 have a condition inver
> 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 and books around in (scientific) literature about
> generics, inh
>>
>>> 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 r
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 discussion goes into the wrong direction. Why are we
>> discussing now how t
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 high-level
> language.
>
Swif
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:
>
>
> Regards
> (From mobile)
>
> On J
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 schrieb Xiaodi Wu :
>> >
>> > As mentioned earlier, NaN !=
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
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
On Mon, Jul 18, 2016 at 12:28 PM, Johannes Neubauer via swift-evolution <
swift-evolution@swift.org> wrote:
> 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
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 can have a special beha
> 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 inverted e.g.. You co
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 14:0
> 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 :
>>>
>>> IMHO implementing your proposal would close the door on some of the t
> 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 sta
> 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 in-memory dbs (T == U -> TRUE for T not related to U),
>>
> 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 loss, but may be more
> of an
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 mobi
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 are computed contract conform
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 u
> 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 lhs = lhs
> var rhs =
> 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 find out because
> al
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(&lhs, &rhs, sizeof(T.self)) == 0
}
T
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) ||
> 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: Why has it been added in the first place? For omitt
> 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 test?
This limitation would
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 implem
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
class A: Equatable {}
cl
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 fa
> 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 „standard equality“ says `tru
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 equality (at least, I think s
> 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 10:02 Johannes Neubauer
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>:
> >
> >
> >> Am 15.07.2016 um 18:
> 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 grapheme clusters, internally two Strings may
>> be comp
> 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 Characters
> they are c
> 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 location, etc.) being different. Having the
>>
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 Johanne
> 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 useful tool in
> a deve
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
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 from the equals test?
It would
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 will come
back later ;)
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 flo
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 proposed to use `===`, since a
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 co
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
56 matches
Mail list logo
