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

[Daniel Duan via swift-evolution]

Daniel Duan
Sent from my iPhone

> On Jul 23, 2016, at 3:15 PM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> This might be a radical suggestion ... or possibly a naive or unoriginal one, 
> I'll find out once I suggest it.
> 
> Swift took the bold step of establishing optionals as a central type, rather 
> than assigning dual meanings to 'default' values such as zero or false. 
> Recognising the concept of not having a value, and safeguarding against that, 
> is core to Swift.

Optional is nothing new or "bold". It's been main stream for years. Even C++ 
has it :)

> Is it possible for Swift to recognise that there are values which simply 
> aren't comparable, rather than forcing a choice between ascending, same, 
> descending? Could we add a fourth: incomparable?
> 

The problem we are trying to solve here is strict total ordering: 
https://en.m.wikipedia.org/wiki/Total_order

> What if a sort operation didn't simply return an array of ordered values? 
> What if it partitioned the values into comparable and incomparable values, 
> and returned a sorted array of the former and an unordered collection of the 
> latter?
> Maybe, this being Swift, we could use some kind of 'sort!' exclamation mark 
> to forcibly express that every value in the collection-to-be-sorted is 
> implicitly comparable, if we're sure.
> 
> 
>> On Sat, Jul 23, 2016 at 10:37 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>>> On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky 
>>>  wrote:
>>> Another option would be to leave the IEEE 754 NaN hijinks in Float and 
>>> Double (as numerics people expect), and create a new type (with a nice 
>>> approachable name) that “acts like” Double but does not model NaN. Then any 
>>> operation which would ordinarily produce a NaN, instead traps for the new 
>>> type. That way its comparison operators only have to worry about non-NaN 
>>> values, which makes everything much cleaner.
>>> 
>>> Sorting Doubles would retain its present functionality, warts and all, 
>>> which numerics people should be expected to handle. Whereas the new type 
>>> (“Number” sounds good, especially if we can make it subsume NSNumber) would 
>>> never have a NaN in the first place.
>> 
>> The other comment I would make here is that, as mentioned earlier by Pyry, 
>> there are other types for which we'll need to reckon with domain-specific 
>> "hijinks" that don't offer easy notions of identity, Unicode being one 
>> example. I'd expect that many types that model an existing domain of human 
>> endeavor will run into something like this. Thus, carefully working through 
>> a design for fundamental protocols like Equatable and Comparable that don't 
>> fall down with FP will prove more broadly fruitful. I don't think that 
>> segregating all hijinks and modeling what we *wish* the world to be is as 
>> beneficial in terms of allowing generic algorithms to work meaningfully with 
>> types that people actually use in real-world scenarios.
>>  
>>> Nevin
>>> 
>>> 
>>> 
 On Sat, Jul 23, 2016 at 4:57 PM, Xiaodi Wu via swift-evolution 
  wrote:
 Sorry to overwhelm with more emails. I'd like to show some work and 
 further analysis for your consideration that refines the sketch I just 
 wrote:
 
 Two FP values a and b can be, with respect to each other:
 
 * ordered or unordered (per IEEE, NaN compares unordered to everything, 
 including itself)
 * identical or not identical (for these purposes, we adopt Steve's 
 proposed test for identity: substitutable for all operations; thus +0 is 
 not identical to -0, but different binary representations of the same 
 value are identical)
 * equal or not equal (i.e. the behavior of the == operator today)
 
 So, if a and b are, with respect to each other:
 
 * ordered, identical, equal -- this is what happens ordinarily with two 
 equal, non-NaN values
 * ordered, identical, not equal -- this can never happen
 * ordered, not identical, equal -- only +0 and -0
 * ordered, not identical, not equal -- this is what happens ordinarily 
 with two unequal, non-NaN values
 
 * unordered, identical, equal -- this can never happen, but if NaNs are to 
 be well-behaved (for a true equivalence relation), then we will need an 
 equivalence relation in which NaN == NaN
 * unordered, identical, not equal -- this is what always happens, but if 
 NaNs are to be well-behaved, then such behavior will need to change
 * unordered, not identical, equal -- this can never happen
 * unordered, not identical, not equal -- this is what ordinarily happens 
 with one NaN and one non-NaN value
 
 Equatable can have === and my proposed ==? as part of its protocol; a 
 generic ==, as originally proposed, would be defined outside the protocol.
 A default 

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Xiaodi Wu via swift-evolution]

On Sat, Jul 23, 2016 at 5:29 PM, Andrew Trick via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jul 23, 2016, at 3:21 PM, Andrew Trick via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jul 23, 2016, at 3:16 PM, Chris Lattner  wrote:
>
>
> On Jul 23, 2016, at 2:38 PM, Andrew Trick via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jul 23, 2016, at 2:06 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  wrote:
> In the context of character sets, "nul" is the correct name for the 0
> value. "null" only makes sense when we are talking about pointer-like
> references.
>
> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name.
> Still a little bizarre looking, though, especially if it's UTF8 rather than
> ASCII. I am less bothered by it now, thanks :)
>
>
> Yeah. Using the ASCII abbreviation was intentional but after thinking
> about it for a second I still think it should be renamed. Swift methods are
> supposed to be spelled out in english. There’s no reason to use an
> abbreviation here.
>
>
> “NUL” is an abbreviation for “Null Character”.  You think that it is a
> good idea to spell out its full two-word name?
> https://en.wikipedia.org/wiki/Null_character
>
>
> I’ll take the troll bait. “nulTerminatedUTF8" should read
> “nullTerminatedUTF8” because
> 1. null-terminated is a common english phrase
> 2. the acronym is not recognizable lowercase and in the context of the
> above phrase
>
>
> :) Oops sorry, it’s not an acronym, but it never appears lowercase, or in
> the context of C strings for that matter.
>


I'm not entirely confident it was a great idea to raise this issue, but now
that we're having the discussion: NUL is of a kind with control codes BS,
CAN, CR, HT, LF, SP, DEL, the corresponding names being null, backspace,
cancel, carriage return, [horizontal] tab, line feed, space, and delete.
For most of these (with the exception of CR and LF, both because the full
name is long and the symbol is more widely used), I'd imagine that what
would be preferred in a variable name would be the written-out form.


Andy
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Andrew Trick via swift-evolution]

> On Jul 23, 2016, at 3:21 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
>> 
>> On Jul 23, 2016, at 3:16 PM, Chris Lattner  wrote:
>> 
>> 
>>> On Jul 23, 2016, at 2:38 PM, Andrew Trick via swift-evolution 
>>>  wrote:
>>> 
 
 On Jul 23, 2016, at 2:06 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  wrote:
 In the context of character sets, "nul" is the correct name for the 0 
 value. "null" only makes sense when we are talking about pointer-like 
 references.
 
 Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name. 
 Still a little bizarre looking, though, especially if it's UTF8 rather 
 than ASCII. I am less bothered by it now, thanks :)
>>> 
>>> Yeah. Using the ASCII abbreviation was intentional but after thinking about 
>>> it for a second I still think it should be renamed. Swift methods are 
>>> supposed to be spelled out in english. There’s no reason to use an 
>>> abbreviation here.
>> 
>> “NUL” is an abbreviation for “Null Character”.  You think that it is a good 
>> idea to spell out its full two-word name?
>> https://en.wikipedia.org/wiki/Null_character
> 
> I’ll take the troll bait. “nulTerminatedUTF8" should read 
> “nullTerminatedUTF8” because
> 1. null-terminated is a common english phrase
> 2. the acronym is not recognizable lowercase and in the context of the above 
> phrase

:) Oops sorry, it’s not an acronym, but it never appears lowercase, or in the 
context of C strings for that matter.
Andy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Daniel Duan via swift-evolution]

Here's the standard where the character is defined. It refers '\0' as NUL most 
of the time but uses the word NULL as well ¯\_(ツ)_/¯.

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf

I'm dubious about this. 

Daniel Duan
Sent from my iPhone

> On Jul 23, 2016, at 2:24 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> And yet the *name* of the character is the “null character”, and a string 
> that terminates in one is called a “null-terminated string”. Those are the 
> terms of art, and I would not expect an abbreviation in this context.
> 
> +1 to the proposed change.
> 
> Nevin
> 
> 
>> On Sat, Jul 23, 2016 at 5:06 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>>> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  wrote:
>>> In the context of character sets, "nul" is the correct name for the 0 
>>> value. "null" only makes sense when we are talking about pointer-like 
>>> references.
>> 
>> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name. 
>> Still a little bizarre looking, though, especially if it's UTF8 rather than 
>> ASCII. I am less bothered by it now, thanks :)
>>  
>>> 
>>> This is my impression anyways.
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Jul 23, 2016, at 1:41 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 World's shortest proposal:
 
 
 Introduction
 
 In `String`, the methods `nulTerminatedUTF8` and 
 `nulTerminatedUTF8CString` have the word "null" misspelled
 
 Motivation
 
 There is a typo
 
 Proposed solution
 
 Fix the typo
 
 Impact on existing code
 
 Emit a fix-it for existing code
 
 Alternatives considered
 
 Keep on spelling "nul" without the second "l"
 
 Acknowledgments
 
 Thanks to Andrew Trick for confirming that the existing spelling is bizarre
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0131: Add AnyHashable to the standard library" begins now and 
runs through July 25.  This proposal is a bit unusual, since it is a late 
additive proposal.  The reason we need to do something here is as a critical 
part of "SE-0116: Import Objective-C id as Swift Any type”, enabling importing 
untyped NSDictionary's and NSSet’s properly.  The core team considers this 
already conceptually approved for Swift 3 as part of SE-0116, but would greatly 
appreciate feedback on the details of the proposed design.

The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Andrew Trick via swift-evolution]

> On Jul 23, 2016, at 3:16 PM, Chris Lattner  wrote:
> 
> 
>> On Jul 23, 2016, at 2:38 PM, Andrew Trick via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On Jul 23, 2016, at 2:06 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  wrote:
>>> In the context of character sets, "nul" is the correct name for the 0 
>>> value. "null" only makes sense when we are talking about pointer-like 
>>> references.
>>> 
>>> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name. 
>>> Still a little bizarre looking, though, especially if it's UTF8 rather than 
>>> ASCII. I am less bothered by it now, thanks :)
>> 
>> Yeah. Using the ASCII abbreviation was intentional but after thinking about 
>> it for a second I still think it should be renamed. Swift methods are 
>> supposed to be spelled out in english. There’s no reason to use an 
>> abbreviation here.
> 
> “NUL” is an abbreviation for “Null Character”.  You think that it is a good 
> idea to spell out its full two-word name?
> https://en.wikipedia.org/wiki/Null_character

I’ll take the troll bait. “nulTerminatedUTF8" should read “nullTerminatedUTF8” 
because
1. null-terminated is a common english phrase
2. the acronym is not recognizable lowercase and in the context of the above 
phrase

Andy

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Chris Lattner via swift-evolution]

> On Jul 23, 2016, at 2:38 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
>> 
>> On Jul 23, 2016, at 2:06 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan > > wrote:
>> In the context of character sets, "nul" is the correct name for the 0 value. 
>> "null" only makes sense when we are talking about pointer-like references.
>> 
>> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name. 
>> Still a little bizarre looking, though, especially if it's UTF8 rather than 
>> ASCII. I am less bothered by it now, thanks :)
> 
> Yeah. Using the ASCII abbreviation was intentional but after thinking about 
> it for a second I still think it should be renamed. Swift methods are 
> supposed to be spelled out in english. There’s no reason to use an 
> abbreviation here.

“NUL” is an abbreviation for “Null Character”.  You think that it is a good 
idea to spell out its full two-word name?
https://en.wikipedia.org/wiki/Null_character 


-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ross O'Brien via swift-evolution]

This might be a radical suggestion ... or possibly a naive or unoriginal
one, I'll find out once I suggest it.

Swift took the bold step of establishing optionals as a central type,
rather than assigning dual meanings to 'default' values such as zero or
false. Recognising the concept of not having a value, and safeguarding
against that, is core to Swift.
Is it possible for Swift to recognise that there are values which simply
aren't comparable, rather than forcing a choice between ascending, same,
descending? Could we add a fourth: incomparable?

What if a sort operation didn't simply return an array of ordered values?
What if it *partitioned* the values into comparable and incomparable
values, and returned a sorted array of the former and an unordered
collection of the latter?
Maybe, this being Swift, we could use some kind of 'sort!' exclamation mark
to forcibly express that every value in the collection-to-be-sorted is
implicitly comparable, if we're sure.


On Sat, Jul 23, 2016 at 10:37 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> Another option would be to leave the IEEE 754 NaN hijinks in Float and
>> Double (as numerics people expect), and create a new type (with a nice
>> approachable name) that “acts like” Double but does not model NaN. Then any
>> operation which would ordinarily produce a NaN, instead traps for the new
>> type. That way its comparison operators only have to worry about non-NaN
>> values, which makes everything much cleaner.
>>
>> Sorting Doubles would retain its present functionality, warts and all,
>> which numerics people should be expected to handle. Whereas the new type
>> (“Number” sounds good, especially if we can make it subsume NSNumber) would
>> never have a NaN in the first place.
>>
>
> The other comment I would make here is that, as mentioned earlier by Pyry,
> there are other types for which we'll need to reckon with domain-specific
> "hijinks" that don't offer easy notions of identity, Unicode being one
> example. I'd expect that many types that model an existing domain of human
> endeavor will run into something like this. Thus, carefully working through
> a design for fundamental protocols like Equatable and Comparable that don't
> fall down with FP will prove more broadly fruitful. I don't think that
> segregating all hijinks and modeling what we *wish* the world to be is as
> beneficial in terms of allowing generic algorithms to work meaningfully
> with types that people actually use in real-world scenarios.
>
>
>> Nevin
>>
>>
>>
>> On Sat, Jul 23, 2016 at 4:57 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Sorry to overwhelm with more emails. I'd like to show some work and
>>> further analysis for your consideration that refines the sketch I just
>>> wrote:
>>>
>>> Two FP values a and b can be, with respect to each other:
>>>
>>> * ordered or unordered (per IEEE, NaN compares unordered to everything,
>>> including itself)
>>> * identical or not identical (for these purposes, we adopt Steve's
>>> proposed test for identity: substitutable for all operations; thus +0 is
>>> not identical to -0, but different binary representations of the same value
>>> are identical)
>>> * equal or not equal (i.e. the behavior of the == operator today)
>>>
>>> So, if a and b are, with respect to each other:
>>>
>>> * ordered, identical, equal -- this is what happens ordinarily with two
>>> equal, non-NaN values
>>> * ordered, identical, not equal -- this can never happen
>>> * ordered, not identical, equal -- only +0 and -0
>>> * ordered, not identical, not equal -- this is what happens ordinarily
>>> with two unequal, non-NaN values
>>>
>>> * unordered, identical, equal -- this can never happen, but if NaNs are
>>> to be well-behaved (for a true equivalence relation), then we will need an
>>> equivalence relation in which NaN == NaN
>>> * unordered, identical, not equal -- this is what always happens, but if
>>> NaNs are to be well-behaved, then such behavior will need to change
>>> * unordered, not identical, equal -- this can never happen
>>> * unordered, not identical, not equal -- this is what ordinarily happens
>>> with one NaN and one non-NaN value
>>>
>>> Equatable can have === and my proposed ==? as part of its protocol; a
>>> generic ==, as originally proposed, would be defined outside the protocol.
>>> A default implementation of ==? will forward to ===, and the generic ==
>>> will be defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`.
>>> For floating point, ==? will be specialized and cease to forward to ===
>>> so that +0 and -0 compare true and NaN and anything compare nil, and
>>> floating point == will be defined notionally as `{ return (lhs ==? rhs) ??
>>> false }`.
>>>
>>>
>>> On Sat, Jul 23, 2016 at 3:09 PM, Xiaodi Wu  wrote:
>>>
 Throwing out some more radical 

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Andrew Trick via swift-evolution]

> On Jul 23, 2016, at 2:06 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  > wrote:
> In the context of character sets, "nul" is the correct name for the 0 value. 
> "null" only makes sense when we are talking about pointer-like references.
> 
> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name. Still 
> a little bizarre looking, though, especially if it's UTF8 rather than ASCII. 
> I am less bothered by it now, thanks :)

Yeah. Using the ASCII abbreviation was intentional but after thinking about it 
for a second I still think it should be renamed. Swift methods are supposed to 
be spelled out in english. There’s no reason to use an abbreviation here.

-Andy

>  
> 
> This is my impression anyways.
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jul 23, 2016, at 1:41 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> World's shortest proposal:
>> 
>> 
>> Introduction
>> 
>> In `String`, the methods `nulTerminatedUTF8` and `nulTerminatedUTF8CString` 
>> have the word "null" misspelled
>> 
>> Motivation
>> 
>> There is a typo
>> 
>> Proposed solution
>> 
>> Fix the typo
>> 
>> Impact on existing code
>> 
>> Emit a fix-it for existing code
>> 
>> Alternatives considered
>> 
>> Keep on spelling "nul" without the second "l"
>> 
>> Acknowledgments
>> 
>> Thanks to Andrew Trick for confirming that the existing spelling is bizarre
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> Another option would be to leave the IEEE 754 NaN hijinks in Float and
> Double (as numerics people expect), and create a new type (with a nice
> approachable name) that “acts like” Double but does not model NaN. Then any
> operation which would ordinarily produce a NaN, instead traps for the new
> type. That way its comparison operators only have to worry about non-NaN
> values, which makes everything much cleaner.
>
> Sorting Doubles would retain its present functionality, warts and all,
> which numerics people should be expected to handle. Whereas the new type
> (“Number” sounds good, especially if we can make it subsume NSNumber) would
> never have a NaN in the first place.
>

The other comment I would make here is that, as mentioned earlier by Pyry,
there are other types for which we'll need to reckon with domain-specific
"hijinks" that don't offer easy notions of identity, Unicode being one
example. I'd expect that many types that model an existing domain of human
endeavor will run into something like this. Thus, carefully working through
a design for fundamental protocols like Equatable and Comparable that don't
fall down with FP will prove more broadly fruitful. I don't think that
segregating all hijinks and modeling what we *wish* the world to be is as
beneficial in terms of allowing generic algorithms to work meaningfully
with types that people actually use in real-world scenarios.


> Nevin
>
>
>
> On Sat, Jul 23, 2016 at 4:57 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Sorry to overwhelm with more emails. I'd like to show some work and
>> further analysis for your consideration that refines the sketch I just
>> wrote:
>>
>> Two FP values a and b can be, with respect to each other:
>>
>> * ordered or unordered (per IEEE, NaN compares unordered to everything,
>> including itself)
>> * identical or not identical (for these purposes, we adopt Steve's
>> proposed test for identity: substitutable for all operations; thus +0 is
>> not identical to -0, but different binary representations of the same value
>> are identical)
>> * equal or not equal (i.e. the behavior of the == operator today)
>>
>> So, if a and b are, with respect to each other:
>>
>> * ordered, identical, equal -- this is what happens ordinarily with two
>> equal, non-NaN values
>> * ordered, identical, not equal -- this can never happen
>> * ordered, not identical, equal -- only +0 and -0
>> * ordered, not identical, not equal -- this is what happens ordinarily
>> with two unequal, non-NaN values
>>
>> * unordered, identical, equal -- this can never happen, but if NaNs are
>> to be well-behaved (for a true equivalence relation), then we will need an
>> equivalence relation in which NaN == NaN
>> * unordered, identical, not equal -- this is what always happens, but if
>> NaNs are to be well-behaved, then such behavior will need to change
>> * unordered, not identical, equal -- this can never happen
>> * unordered, not identical, not equal -- this is what ordinarily happens
>> with one NaN and one non-NaN value
>>
>> Equatable can have === and my proposed ==? as part of its protocol; a
>> generic ==, as originally proposed, would be defined outside the protocol.
>> A default implementation of ==? will forward to ===, and the generic ==
>> will be defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`.
>> For floating point, ==? will be specialized and cease to forward to ===
>> so that +0 and -0 compare true and NaN and anything compare nil, and
>> floating point == will be defined notionally as `{ return (lhs ==? rhs) ??
>> false }`.
>>
>>
>> On Sat, Jul 23, 2016 at 3:09 PM, Xiaodi Wu  wrote:
>>
>>> Throwing out some more radical ideas here. Suppose we had instead
>>> (taking inspiration from IEEE notation):
>>>
>>> [Pardon any errors; I'm writing freehand in Gmail]
>>>
>>> infix operator ==? { /* figure out precedence later */ }
>>>
>>> protocol Equatable {
>>>   static func ==? (lhs: Self, rhs: Self) -> Bool?
>>>   /* semantics:
>>>  this function returns nil if lhs and rhs are unordered with respect
>>> to each other
>>>  otherwise, evaluate by means of a legal equivalence relation */
>>> }
>>>
>>> func == (lhs: T, rhs: T) -> Bool {
>>>   return (lhs ==? rhs) ?? false
>>> }
>>>
>>> protocol Comparable : Equatable {
>>>   static func <=> (lhs: Self, rhs: Self) -> Ordering
>>>   /* semantics:
>>>  this is a total ordering; thus:
>>>  if `(a ==? b) == true`, then `(a <=> b) == .same`
>>>  if `(a ==? b) == false`, then `(a <=> b) != .same`
>>>  but, if `(a ==? b) == nil`, then `a <=> b` may yield any result
>>>   */
>>> }
>>>
>>>
>>> On Sat, Jul 23, 2016 at 2:35 PM, Pyry Jahkola 
>>> wrote:
>>>
 Given all this, I propose a simpler model that makes `a <=> b` follow
 the expected behaviour of < and ==, with the tradeoff that `a <=> 

Re: [swift-evolution] [Review] SE-0129: Package Manager Test Naming Conventions

[T.J. Usiyan via swift-evolution]

* What is your evaluation of the proposal?
+ 1
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
* Does this proposal fit well with the feel and direction of Swift?
Yes
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
It holds up. I would like the ability mentioned in 'Alternatives
Considered' to eventually be implemented.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick reading

On Fri, Jul 22, 2016 at 1:15 PM, Daniel Dunbar via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0129: Package Manager Test Naming Conventions" begins
> now and runs through July 26. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0129-package-manager-test-naming-conventions.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> - Daniel Dunbar
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

IMO what's causing the headaches now isn't NaN; it's actually +0 and -0.


On Sat, Jul 23, 2016 at 4:19 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> Another option would be to leave the IEEE 754 NaN hijinks in Float and
> Double (as numerics people expect), and create a new type (with a nice
> approachable name) that “acts like” Double but does not model NaN. Then any
> operation which would ordinarily produce a NaN, instead traps for the new
> type. That way its comparison operators only have to worry about non-NaN
> values, which makes everything much cleaner.
>
> Sorting Doubles would retain its present functionality, warts and all,
> which numerics people should be expected to handle. Whereas the new type
> (“Number” sounds good, especially if we can make it subsume NSNumber) would
> never have a NaN in the first place.
>
> Nevin
>
>
>
> On Sat, Jul 23, 2016 at 4:57 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Sorry to overwhelm with more emails. I'd like to show some work and
>> further analysis for your consideration that refines the sketch I just
>> wrote:
>>
>> Two FP values a and b can be, with respect to each other:
>>
>> * ordered or unordered (per IEEE, NaN compares unordered to everything,
>> including itself)
>> * identical or not identical (for these purposes, we adopt Steve's
>> proposed test for identity: substitutable for all operations; thus +0 is
>> not identical to -0, but different binary representations of the same value
>> are identical)
>> * equal or not equal (i.e. the behavior of the == operator today)
>>
>> So, if a and b are, with respect to each other:
>>
>> * ordered, identical, equal -- this is what happens ordinarily with two
>> equal, non-NaN values
>> * ordered, identical, not equal -- this can never happen
>> * ordered, not identical, equal -- only +0 and -0
>> * ordered, not identical, not equal -- this is what happens ordinarily
>> with two unequal, non-NaN values
>>
>> * unordered, identical, equal -- this can never happen, but if NaNs are
>> to be well-behaved (for a true equivalence relation), then we will need an
>> equivalence relation in which NaN == NaN
>> * unordered, identical, not equal -- this is what always happens, but if
>> NaNs are to be well-behaved, then such behavior will need to change
>> * unordered, not identical, equal -- this can never happen
>> * unordered, not identical, not equal -- this is what ordinarily happens
>> with one NaN and one non-NaN value
>>
>> Equatable can have === and my proposed ==? as part of its protocol; a
>> generic ==, as originally proposed, would be defined outside the protocol.
>> A default implementation of ==? will forward to ===, and the generic ==
>> will be defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`.
>> For floating point, ==? will be specialized and cease to forward to ===
>> so that +0 and -0 compare true and NaN and anything compare nil, and
>> floating point == will be defined notionally as `{ return (lhs ==? rhs) ??
>> false }`.
>>
>>
>> On Sat, Jul 23, 2016 at 3:09 PM, Xiaodi Wu  wrote:
>>
>>> Throwing out some more radical ideas here. Suppose we had instead
>>> (taking inspiration from IEEE notation):
>>>
>>> [Pardon any errors; I'm writing freehand in Gmail]
>>>
>>> infix operator ==? { /* figure out precedence later */ }
>>>
>>> protocol Equatable {
>>>   static func ==? (lhs: Self, rhs: Self) -> Bool?
>>>   /* semantics:
>>>  this function returns nil if lhs and rhs are unordered with respect
>>> to each other
>>>  otherwise, evaluate by means of a legal equivalence relation */
>>> }
>>>
>>> func == (lhs: T, rhs: T) -> Bool {
>>>   return (lhs ==? rhs) ?? false
>>> }
>>>
>>> protocol Comparable : Equatable {
>>>   static func <=> (lhs: Self, rhs: Self) -> Ordering
>>>   /* semantics:
>>>  this is a total ordering; thus:
>>>  if `(a ==? b) == true`, then `(a <=> b) == .same`
>>>  if `(a ==? b) == false`, then `(a <=> b) != .same`
>>>  but, if `(a ==? b) == nil`, then `a <=> b` may yield any result
>>>   */
>>> }
>>>
>>>
>>> On Sat, Jul 23, 2016 at 2:35 PM, Pyry Jahkola 
>>> wrote:
>>>
 Given all this, I propose a simpler model that makes `a <=> b` follow
 the expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and
 `.nan <=> b` will abort with a precondition failure:

 1) We keep the current Interface of Equatable  unchanged, with !=
 defined in terms of ==.

 2) Comparable would still refine Equatable, and include all the
 comparison operators, adding the new <=>:

 protocol Comparable : Equatable {
   static func <=>(lhs: Self, rhs: Self) -> Ordering
   static func <(lhs: Self, rhs: Self) -> Bool
   static func >(lhs: Self, rhs: Self) -> Bool
   static func <=(lhs: Self, rhs: Self) -> Bool
   static func >=(lhs: Self, rhs: Self) -> Bool
 }

 The 

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Nevin Brackett-Rozinsky via swift-evolution]

And yet the *name* of the character is the “null character
”, and a string that
terminates in one is called a “null-terminated string
”. Those are the
terms of art, and I would not expect an abbreviation in this context.

+1 to the proposed change.

Nevin


On Sat, Jul 23, 2016 at 5:06 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sat, Jul 23, 2016 at 3:54 PM, Daniel Duan  wrote:
>
>> In the context of character sets, "nul" is the correct name for the 0
>> value. "null" only makes sense when we are talking about pointer-like
>> references.
>>
>
> Oh, I see: "NUL-terminated" is a thing because "NUL" is the ASCII name.
> Still a little bizarre looking, though, especially if it's UTF8 rather than
> ASCII. I am less bothered by it now, thanks :)
>
>
>>
>> This is my impression anyways.
>>
>> Daniel Duan
>> Sent from my iPhone
>>
>> On Jul 23, 2016, at 1:41 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> World's shortest proposal:
>>
>>
>> *Introduction*
>>
>> In `String`, the methods `nulTerminatedUTF8` and
>> `nulTerminatedUTF8CString` have the word "null" misspelled
>>
>> *Motivation*
>>
>> There is a typo
>>
>> *Proposed solution*
>>
>> Fix the typo
>>
>> *Impact on existing code*
>>
>> Emit a fix-it for existing code
>>
>> *Alternatives considered*
>>
>> Keep on spelling "nul" without the second "l"
>>
>> *Acknowledgments*
>>
>> Thanks to Andrew Trick for confirming that the existing spelling is
>> bizarre
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

Another option would be to leave the IEEE 754 NaN hijinks in Float and
Double (as numerics people expect), and create a new type (with a nice
approachable name) that “acts like” Double but does not model NaN. Then any
operation which would ordinarily produce a NaN, instead traps for the new
type. That way its comparison operators only have to worry about non-NaN
values, which makes everything much cleaner.

Sorting Doubles would retain its present functionality, warts and all,
which numerics people should be expected to handle. Whereas the new type
(“Number” sounds good, especially if we can make it subsume NSNumber) would
never have a NaN in the first place.

Nevin



On Sat, Jul 23, 2016 at 4:57 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Sorry to overwhelm with more emails. I'd like to show some work and
> further analysis for your consideration that refines the sketch I just
> wrote:
>
> Two FP values a and b can be, with respect to each other:
>
> * ordered or unordered (per IEEE, NaN compares unordered to everything,
> including itself)
> * identical or not identical (for these purposes, we adopt Steve's
> proposed test for identity: substitutable for all operations; thus +0 is
> not identical to -0, but different binary representations of the same value
> are identical)
> * equal or not equal (i.e. the behavior of the == operator today)
>
> So, if a and b are, with respect to each other:
>
> * ordered, identical, equal -- this is what happens ordinarily with two
> equal, non-NaN values
> * ordered, identical, not equal -- this can never happen
> * ordered, not identical, equal -- only +0 and -0
> * ordered, not identical, not equal -- this is what happens ordinarily
> with two unequal, non-NaN values
>
> * unordered, identical, equal -- this can never happen, but if NaNs are to
> be well-behaved (for a true equivalence relation), then we will need an
> equivalence relation in which NaN == NaN
> * unordered, identical, not equal -- this is what always happens, but if
> NaNs are to be well-behaved, then such behavior will need to change
> * unordered, not identical, equal -- this can never happen
> * unordered, not identical, not equal -- this is what ordinarily happens
> with one NaN and one non-NaN value
>
> Equatable can have === and my proposed ==? as part of its protocol; a
> generic ==, as originally proposed, would be defined outside the protocol.
> A default implementation of ==? will forward to ===, and the generic ==
> will be defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`.
> For floating point, ==? will be specialized and cease to forward to === so
> that +0 and -0 compare true and NaN and anything compare nil, and floating
> point == will be defined notionally as `{ return (lhs ==? rhs) ?? false }`.
>
>
> On Sat, Jul 23, 2016 at 3:09 PM, Xiaodi Wu  wrote:
>
>> Throwing out some more radical ideas here. Suppose we had instead (taking
>> inspiration from IEEE notation):
>>
>> [Pardon any errors; I'm writing freehand in Gmail]
>>
>> infix operator ==? { /* figure out precedence later */ }
>>
>> protocol Equatable {
>>   static func ==? (lhs: Self, rhs: Self) -> Bool?
>>   /* semantics:
>>  this function returns nil if lhs and rhs are unordered with respect
>> to each other
>>  otherwise, evaluate by means of a legal equivalence relation */
>> }
>>
>> func == (lhs: T, rhs: T) -> Bool {
>>   return (lhs ==? rhs) ?? false
>> }
>>
>> protocol Comparable : Equatable {
>>   static func <=> (lhs: Self, rhs: Self) -> Ordering
>>   /* semantics:
>>  this is a total ordering; thus:
>>  if `(a ==? b) == true`, then `(a <=> b) == .same`
>>  if `(a ==? b) == false`, then `(a <=> b) != .same`
>>  but, if `(a ==? b) == nil`, then `a <=> b` may yield any result
>>   */
>> }
>>
>>
>> On Sat, Jul 23, 2016 at 2:35 PM, Pyry Jahkola 
>> wrote:
>>
>>> Given all this, I propose a simpler model that makes `a <=> b` follow
>>> the expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and
>>> `.nan <=> b` will abort with a precondition failure:
>>>
>>> 1) We keep the current Interface of Equatable  unchanged, with !=
>>> defined in terms of ==.
>>>
>>> 2) Comparable would still refine Equatable, and include all the
>>> comparison operators, adding the new <=>:
>>>
>>> protocol Comparable : Equatable {
>>>   static func <=>(lhs: Self, rhs: Self) -> Ordering
>>>   static func <(lhs: Self, rhs: Self) -> Bool
>>>   static func >(lhs: Self, rhs: Self) -> Bool
>>>   static func <=(lhs: Self, rhs: Self) -> Bool
>>>   static func >=(lhs: Self, rhs: Self) -> Bool
>>> }
>>>
>>> The comparison operators are kept in the interface so that partially
>>> ordered types such as Double can be supported in generic code. However, the
>>> documentation should recommend against defining `<` manually.
>>>
>>> 3) Default implementations for  are provided for the
>>> following operators: ==, <, >, 

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Jacob Bandes-Storch via swift-evolution]

+1

On Sat, Jul 23, 2016 at 1:41 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> World's shortest proposal:
>
>
> *Introduction*
>
> In `String`, the methods `nulTerminatedUTF8` and
> `nulTerminatedUTF8CString` have the word "null" misspelled
>
> *Motivation*
>
> There is a typo
>
> *Proposed solution*
>
> Fix the typo
>
> *Impact on existing code*
>
> Emit a fix-it for existing code
>
> *Alternatives considered*
>
> Keep on spelling "nul" without the second "l"
>
> *Acknowledgments*
>
> Thanks to Andrew Trick for confirming that the existing spelling is bizarre
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Sorry to overwhelm with more emails. I'd like to show some work and further
analysis for your consideration that refines the sketch I just wrote:

Two FP values a and b can be, with respect to each other:

* ordered or unordered (per IEEE, NaN compares unordered to everything,
including itself)
* identical or not identical (for these purposes, we adopt Steve's proposed
test for identity: substitutable for all operations; thus +0 is not
identical to -0, but different binary representations of the same value are
identical)
* equal or not equal (i.e. the behavior of the == operator today)

So, if a and b are, with respect to each other:

* ordered, identical, equal -- this is what happens ordinarily with two
equal, non-NaN values
* ordered, identical, not equal -- this can never happen
* ordered, not identical, equal -- only +0 and -0
* ordered, not identical, not equal -- this is what happens ordinarily with
two unequal, non-NaN values

* unordered, identical, equal -- this can never happen, but if NaNs are to
be well-behaved (for a true equivalence relation), then we will need an
equivalence relation in which NaN == NaN
* unordered, identical, not equal -- this is what always happens, but if
NaNs are to be well-behaved, then such behavior will need to change
* unordered, not identical, equal -- this can never happen
* unordered, not identical, not equal -- this is what ordinarily happens
with one NaN and one non-NaN value

Equatable can have === and my proposed ==? as part of its protocol; a
generic ==, as originally proposed, would be defined outside the protocol.
A default implementation of ==? will forward to ===, and the generic ==
will be defined as `{ return (lhs ==? rhs) ?? (lhs === rhs) }`.
For floating point, ==? will be specialized and cease to forward to === so
that +0 and -0 compare true and NaN and anything compare nil, and floating
point == will be defined notionally as `{ return (lhs ==? rhs) ?? false }`.


On Sat, Jul 23, 2016 at 3:09 PM, Xiaodi Wu  wrote:

> Throwing out some more radical ideas here. Suppose we had instead (taking
> inspiration from IEEE notation):
>
> [Pardon any errors; I'm writing freehand in Gmail]
>
> infix operator ==? { /* figure out precedence later */ }
>
> protocol Equatable {
>   static func ==? (lhs: Self, rhs: Self) -> Bool?
>   /* semantics:
>  this function returns nil if lhs and rhs are unordered with respect
> to each other
>  otherwise, evaluate by means of a legal equivalence relation */
> }
>
> func == (lhs: T, rhs: T) -> Bool {
>   return (lhs ==? rhs) ?? false
> }
>
> protocol Comparable : Equatable {
>   static func <=> (lhs: Self, rhs: Self) -> Ordering
>   /* semantics:
>  this is a total ordering; thus:
>  if `(a ==? b) == true`, then `(a <=> b) == .same`
>  if `(a ==? b) == false`, then `(a <=> b) != .same`
>  but, if `(a ==? b) == nil`, then `a <=> b` may yield any result
>   */
> }
>
>
> On Sat, Jul 23, 2016 at 2:35 PM, Pyry Jahkola  wrote:
>
>> Given all this, I propose a simpler model that makes `a <=> b` follow the
>> expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and
>> `.nan <=> b` will abort with a precondition failure:
>>
>> 1) We keep the current Interface of Equatable  unchanged, with != defined
>> in terms of ==.
>>
>> 2) Comparable would still refine Equatable, and include all the
>> comparison operators, adding the new <=>:
>>
>> protocol Comparable : Equatable {
>>   static func <=>(lhs: Self, rhs: Self) -> Ordering
>>   static func <(lhs: Self, rhs: Self) -> Bool
>>   static func >(lhs: Self, rhs: Self) -> Bool
>>   static func <=(lhs: Self, rhs: Self) -> Bool
>>   static func >=(lhs: Self, rhs: Self) -> Bool
>> }
>>
>> The comparison operators are kept in the interface so that partially
>> ordered types such as Double can be supported in generic code. However, the
>> documentation should recommend against defining `<` manually.
>>
>> 3) Default implementations for  are provided for the
>> following operators: ==, <, >, <=, and >=.
>>
>> 4) User-defined types will need to define just <=> to conform to
>> Comparable. (Even == can be omitted!)
>>
>> 5) FloatingPoint types implement custom versions of ==, <, >, <=, and >=
>> using the standard IEEE 754 definition (i.e. comparisons involving NaN
>> return false). Zero is zero; `0.0 == -0.0 && !(-0.0 < 0.0)` holds.
>>
>> 6) FloatingPoint types implement <=> as:
>>
>> func <=> (lhs: T, rhs: T) -> Ordering {
>>   if lhs < rhs { return .ascending }
>>   if rhs < lhs { return .descending }
>>   precondition(lhs == rhs)
>>   return .same
>> }
>>
>> 7) Algorithms using <=> directly should mention so in their documentation
>> as a precondition that they require total order between elements. Many
>> generic algorithms can be defined in terms of == or <, and should.
>>
>> If we took the oroginally planned route that distinguished between
>> identities such 

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

[Dave Abrahams via swift-evolution]

on Sat Jul 23 2016, Xiaodi Wu  wrote:

> That last sentence: division is defined in Arithmetic (IIUC--I'm not in
> front of a traditional computer ATM). 

Yes.

> I would expect, for any arithmetic type T, that the following would
> return true:
>
> let a, b, c: T
> if a == b {
> return c/a == c/b
> }
>
> This would not hold for all a and b if -0 === +0.

That would be nice, wouldn't it?  But there are lots of expected
arithmetic laws that floating point won't obey.

>
>
> On Sat, Jul 23, 2016 at 13:41 Dave Abrahams  wrote:
>
>>
>> on Sat Jul 23 2016, Xiaodi Wu  wrote:
>>
>> > On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon 
>> wrote:
>> >
>> >> > 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 floating point.  Should +0 and -0 have the same identity or
>> >> > not?  I’ll leave the answer to folks more knowledgable about numerics
>> >> > than I.
>> >>
>> >> Boy, I take my wife out for a movie and come back to 50 new messages on
>> SE.
>> >>
>> >> I need to read the entire thread more carefully, but off the top of my
>> >> head, I think that `-0 === +0` is False.  If we’re going to have an
>> >> `isSame` / `isIdentical` / whatever it's called, I would expect it to
>> imply
>> >> substitutability.  Although -0 == +0, they are not equivalent when
>> >> substituted:
>> >>
>> >> - 1/(-0) != 1/0
>> >> - Float(-0).sign != Float(+0).sign
>> >> - etc
>> >>
>> >> This probably then implies that `<=>` is not `.same` either.  I’ll read
>> >> the rest of this and respond more completely tomorrow.
>> >>
>> >
>> > Eagerly await your evaluation of the discussion. In the meantime:
>> >
>> > I think Dave's view that `===` defines identity in terms of "essential"
>> > qualities implies that two identical values can be
>> > different/non-substitutable in "inessential" qualities. For generic
>> > purposes, the sign of zero could be one such inessential quality.
>>
>> Yes, and I think our view of how people work with numbers in swift (and
>> their protocol conformances) reflect this approach.
>>
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/16321
>>
>> My sense is that we want to choose the default notions of identity and
>> ordering so as to support the way people think about these numeric
>> types, inexact though it may be.  Therefore, finding 0.0 in a sequence
>> of floats should succeed when the sequence contains -0.0, and a stable
>> sort on floating point keys should preserve the relative order of all
>> elements having +0.0 and -0.0 keys.
>>
>> People that want to work with inessential qualities such as the sign of
>> zero can always pass Float.totalOrdering (or whatever) to their
>> closure-accepting algorithms.
>>
>> [In order to support the user model, we still need to fix the semantics
>> of the default identity and ordering operations so that things like
>> sorting and searching work, which is why == and < won't cut it for these
>> purposes]
>>
>> > On the other hand, the stdlib stride algorithm is going to be borked if
>> -0
>> > < +0. Of course, as we already started to do there, we could specialize
>> for
>> > floating point and then adjust accordingly. However, it seems to me that
>> > every generic algorithm that performs comparisons and can take floating
>> > point arguments would have to be specialized to account for floating
>> point
>> > -0 != +0 (`index(of:)` being the previous example). This appears to
>> defeat
>> > the aim of trying to accommodate FP at all in this revised design for
>> > Comparables.
>>
>> Yes, that would be a disaster, generically speaking.
>>
>> > The argument for `-0 === +0` is that -0 and +0 should be equivalent when
>> > substituted for every comparison operation. For FP operations, you'd
>> > continue to test (as you have to test now) `a == b && a.sign == b.sign`
>> if
>> > you cared about the sign of zero. For non-FP arithmetic operations, hmm,
>> > not sure how to square that circle.
>>
>> I followed all of this... except, what are you getting at with that last
>> sentence?
>>
>> --
>> Dave
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Dave Abrahams via swift-evolution]

on Fri Jul 22 2016, Charlie Monroe  wrote:

> Ok, I'll update the proposal to withdraw the change of inout for
> withUnsafePointer.

We could also add

withUnsafePointer(toCopyOf: x)

but that can also come later if we decide we need it.

> Under the discussion for the pull request, Bob mentioned possible
> removal of the multi-pointer variants
> (i.e. withUnsafe[Mutable]Pointers) - is this something that you'd
> agree on?

Absolutely.

> If so, I'd add this to the proposal since I agree that this is an API
> that is rarely used, can be used by nesting two
> withUnsafe[Mutable]Pointer calls and is limited to three pointers at
> max anyway. It almost feels like NSAssert1, NSAssert2, etc.
>
>> On Jul 23, 2016, at 3:35 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Fri Jul 22 2016, Xiaodi Wu  wrote:
>> 
>>> On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> 
 
 on Fri Jul 22 2016, Xiaodi Wu  wrote:
 
> On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>> 
>> on Fri Jul 22 2016, Bob Wilson  wrote:
>> 
>>> It is not so clear what to do about SR-1956. (Charlie and I had some
>>> comments on this in https://github.com/apple/swift-evolution/pull/437
>>> .) Jordan raised
>>> the objection that when using withUnsafePointer with a global, there
>>> is an expectation that you’ll get the same address every
>>> time. Removing inout would cause the argument to be passed by value
>>> and the address would refer to a copy. Dmitri agreed that this could
>>> be a problem. On the other hand, if you don’t care about the address,
>>> or if you’re not using a value type, it would indeed be convenient to
>>> have a version of withUnsafePointer that does not require an inout
>>> argument.
>>> 
>>> Option 1: Keep inout (not addressing SR-1956). In this case, there’s
>>> no reason to have both withUnsafePointer and
>>> withUnsafeMutablePointer. If you want to call a function that expects
>>> an UnsafePointer, you can give it an UnsafeMutablePointer and there
>>> will be an implicit conversion to make it work. I discussed this with
>>> Apple’s stdlib team and they recommended that if we have only one
>>> function we use the shorter name “withUnsafePointer” and have it use
>>> an UnsafeMutablePointer.
>> 
>> Very much in favor of Option 1.
>> 
> 
> Ditto, except that I think there is some value in keeping both (i.e.
 doing
> nothing): allowing the user to document intent. It would be inconsistent
> and potentially confusing to call the function that returns an
> `UnsafeMutablePointer` `withUnsafePointer`.
 
 It doesn't return an `UnsafeMutablePointer`, it passes an
 `UnsafeMutablePointer` to the body of the closure.
 
>>> 
>>> Brainfart. Yes, that's what I meant to write. Sorry.
>>> 
> It's rarely used enough, and the shorter name needlessly raises the
> question of where I'm really "supposed to be" mutating the
> pointee.
 
 I don't understand; you only have the pointee inside the closure.
 That's where you mutate it (obviously?)
 
>>> 
>>> If my closure does not mutate the pointee, `withUnsafePointer(_:)` allows
>>> me to document that. Everything *works* with
>>> `withUnsafeMutablePointer(_:)`, but I cannot read the code and understand
>>> that no mutation has happened within the body of the closure. [Am I wrong
>>> on this?]
>> 
>> No, you're right.
>> 
>>> For instance, I've been working with some of the Accelerate.framework
>>> functions and the arguments are often cryptic. Take this call:
>>> 
>>> ```
>>> cblas_sgemm(CblasColMajor, CblasNoTrans, CblasNoTrans, m, n, k, 1, matrix,
>>> m, b, k, 1, , m)
>>> ```
>>> 
>>> There are times when I'd want to
>>> call `cblas_sgemm(_:_:_:_:_:_:_:_:_:_:_:_:_:_:)` inside an
>>> `withUnsafe[Mutable]Pointer(_:)` closure. Distinguishing
>>> `withUnsafePointer(_:)` and `withUnsafeMutablePointer(_:)` would allow a
>>> reader to know from the outset if `$0.pointee is mutated without having to
>>> know that the second-from-last argument is the one that stores the result
>>> (it is not consistently second-from-last; for vDSP_* functions, it's often
>>> the third-from-last argument, and for others it can be the first argument).
>>> Removing the current `withUnsafePointer(_:)` would decrease clarity for the
>>> reader here.
>> 
>> Okay, fair enough.
>> 
 I've not had to use these functions much, but the distinction between
> `Array.withUnsafeBufferPointer(_:)` and
> `Array.withUnsafeMutableBufferPointer(_:)` has conditioned me to
> mutate the pointee using only "mutable" functions.
 
 Not sure if you're just drawing 

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Jose Cheyo Jimenez via swift-evolution]

I'm finding it really hard to see the advantage of this proposal with out 
reconciling the possibility of .self going away. I think this should be 
postponed after .self is reviewed in swift 4. Premature optimization imo. 

> On Jul 22, 2016, at 3:20 PM, David Hart via swift-evolution 
>  wrote:
> 
> Where do these double generics come from? Never saw them...
> 
>> On 22 Jul 2016, at 17:54, Anton Zhilin  wrote:
>> 
>> 2016-07-22 18:51 GMT+03:00 David Hart :
>>> Isn't the solution to a lot of these issues allowing explicit 
>>> generalization instead of this meta type business?
>> 
>> And what would you suggest for "double generics" in initializers?
>> ExampleType()  // not good
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Fix a typo in two String methods

[Xiaodi Wu via swift-evolution]

World's shortest proposal:


*Introduction*

In `String`, the methods `nulTerminatedUTF8` and `nulTerminatedUTF8CString`
have the word "null" misspelled

*Motivation*

There is a typo

*Proposed solution*

Fix the typo

*Impact on existing code*

Emit a fix-it for existing code

*Alternatives considered*

Keep on spelling "nul" without the second "l"

*Acknowledgments*

Thanks to Andrew Trick for confirming that the existing spelling is bizarre
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Anton Zhilin via swift-evolution]

Is noone interested? We are going to go for the second round of review with
this version of proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

Given all this, I propose a simpler model that makes `a <=> b` follow the 
expected behaviour of < and ==, with the tradeoff that `a <=> .nan` and `.nan 
<=> b` will abort with a precondition failure:

1) We keep the current Interface of Equatable  unchanged, with != defined in 
terms of ==.

2) Comparable would still refine Equatable, and include all the comparison 
operators, adding the new <=>:

protocol Comparable : Equatable {
  static func <=>(lhs: Self, rhs: Self) -> Ordering
  static func <(lhs: Self, rhs: Self) -> Bool
  static func >(lhs: Self, rhs: Self) -> Bool
  static func <=(lhs: Self, rhs: Self) -> Bool
  static func >=(lhs: Self, rhs: Self) -> Bool
}

The comparison operators are kept in the interface so that partially ordered 
types such as Double can be supported in generic code. However, the 
documentation should recommend against defining `<` manually.

3) Default implementations for  are provided for the 
following operators: ==, <, >, <=, and >=.

4) User-defined types will need to define just <=> to conform to Comparable. 
(Even == can be omitted!)

5) FloatingPoint types implement custom versions of ==, <, >, <=, and >= using 
the standard IEEE 754 definition (i.e. comparisons involving NaN return false). 
Zero is zero; `0.0 == -0.0 && !(-0.0 < 0.0)` holds.

6) FloatingPoint types implement <=> as:

func <=> (lhs: T, rhs: T) -> Ordering {
  if lhs < rhs { return .ascending }
  if rhs < lhs { return .descending }
  precondition(lhs == rhs)
  return .same
}

7) Algorithms using <=> directly should mention so in their documentation as a 
precondition that they require total order between elements. Many generic 
algorithms can be defined in terms of == or <, and should.

If we took the oroginally planned route that distinguished between identities 
such as -0.0 vs. +0.0, or between the 2⁴⁹ - 2 ≈ 5.6 × 10¹⁴ possible NaN values 
that Double has, we'd also need to consider other oddballs like the difference 
and ordering between the Strings "ä" and "a\u{308}", which are considered equal 
but produce a different Unicode representation. I think it's best to hide those 
identities behind another interface than Equatable and Comparable, and let the 
protocols serve more mundane application logic.

— Pyry

> Dave Abrahams wrote:
> 
> 
>> on Sat Jul 23 2016, Xiaodi Wu  wrote:
>> 
>> On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon  wrote:
>> 
 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 floating point.  Should +0 and -0 have the same identity or
 not?  I’ll leave the answer to folks more knowledgable about numerics
 than I.
>>> 
>>> Boy, I take my wife out for a movie and come back to 50 new messages on SE.
>>> 
>>> I need to read the entire thread more carefully, but off the top of my
>>> head, I think that `-0 === +0` is False.  If we’re going to have an
>>> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply
>>> substitutability.  Although -0 == +0, they are not equivalent when
>>> substituted:
>>> 
>>> - 1/(-0) != 1/0
>>> - Float(-0).sign != Float(+0).sign
>>> - etc
>>> 
>>> This probably then implies that `<=>` is not `.same` either.  I’ll read
>>> the rest of this and respond more completely tomorrow.
>> 
>> Eagerly await your evaluation of the discussion. In the meantime:
>> 
>> I think Dave's view that `===` defines identity in terms of "essential"
>> qualities implies that two identical values can be
>> different/non-substitutable in "inessential" qualities. For generic
>> purposes, the sign of zero could be one such inessential quality.
> 
> Yes, and I think our view of how people work with numbers in swift (and
> their protocol conformances) reflect this approach.  
> 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/16321
> 
> My sense is that we want to choose the default notions of identity and
> ordering so as to support the way people think about these numeric
> types, inexact though it may be.  Therefore, finding 0.0 in a sequence
> of floats should succeed when the sequence contains -0.0, and a stable
> sort on floating point keys should preserve the relative order of all
> elements having +0.0 and -0.0 keys.  
> 
> People that want to work with inessential qualities such as the sign of
> zero can always pass Float.totalOrdering (or whatever) to their
> closure-accepting algorithms.
> 
> [In order to support the user model, we still need to fix the semantics
> of the default identity and ordering operations so that things like
> sorting and searching work, which is why == and < won't cut it for these
> purposes]
> 
>> On the other hand, the stdlib stride algorithm is going to be borked if -0
>> < +0. Of course, as we already started to do there, we could specialize for
>> floating point and then adjust accordingly. 

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

[Xiaodi Wu via swift-evolution]

That last sentence: division is defined in Arithmetic (IIUC--I'm not in
front of a traditional computer ATM). I would expect, for any arithmetic
type T, that the following would return true:

let a, b, c: T
if a == b {
return c/a == c/b
}

This would not hold for all a and b if -0 === +0.

On Sat, Jul 23, 2016 at 13:41 Dave Abrahams  wrote:

>
> on Sat Jul 23 2016, Xiaodi Wu  wrote:
>
> > On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon 
> wrote:
> >
> >> > 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 floating point.  Should +0 and -0 have the same identity or
> >> > not?  I’ll leave the answer to folks more knowledgable about numerics
> >> > than I.
> >>
> >> Boy, I take my wife out for a movie and come back to 50 new messages on
> SE.
> >>
> >> I need to read the entire thread more carefully, but off the top of my
> >> head, I think that `-0 === +0` is False.  If we’re going to have an
> >> `isSame` / `isIdentical` / whatever it's called, I would expect it to
> imply
> >> substitutability.  Although -0 == +0, they are not equivalent when
> >> substituted:
> >>
> >> - 1/(-0) != 1/0
> >> - Float(-0).sign != Float(+0).sign
> >> - etc
> >>
> >> This probably then implies that `<=>` is not `.same` either.  I’ll read
> >> the rest of this and respond more completely tomorrow.
> >>
> >
> > Eagerly await your evaluation of the discussion. In the meantime:
> >
> > I think Dave's view that `===` defines identity in terms of "essential"
> > qualities implies that two identical values can be
> > different/non-substitutable in "inessential" qualities. For generic
> > purposes, the sign of zero could be one such inessential quality.
>
> Yes, and I think our view of how people work with numbers in swift (and
> their protocol conformances) reflect this approach.
>
> http://article.gmane.org/gmane.comp.lang.swift.evolution/16321
>
> My sense is that we want to choose the default notions of identity and
> ordering so as to support the way people think about these numeric
> types, inexact though it may be.  Therefore, finding 0.0 in a sequence
> of floats should succeed when the sequence contains -0.0, and a stable
> sort on floating point keys should preserve the relative order of all
> elements having +0.0 and -0.0 keys.
>
> People that want to work with inessential qualities such as the sign of
> zero can always pass Float.totalOrdering (or whatever) to their
> closure-accepting algorithms.
>
> [In order to support the user model, we still need to fix the semantics
> of the default identity and ordering operations so that things like
> sorting and searching work, which is why == and < won't cut it for these
> purposes]
>
> > On the other hand, the stdlib stride algorithm is going to be borked if
> -0
> > < +0. Of course, as we already started to do there, we could specialize
> for
> > floating point and then adjust accordingly. However, it seems to me that
> > every generic algorithm that performs comparisons and can take floating
> > point arguments would have to be specialized to account for floating
> point
> > -0 != +0 (`index(of:)` being the previous example). This appears to
> defeat
> > the aim of trying to accommodate FP at all in this revised design for
> > Comparables.
>
> Yes, that would be a disaster, generically speaking.
>
> > The argument for `-0 === +0` is that -0 and +0 should be equivalent when
> > substituted for every comparison operation. For FP operations, you'd
> > continue to test (as you have to test now) `a == b && a.sign == b.sign`
> if
> > you cared about the sign of zero. For non-FP arithmetic operations, hmm,
> > not sure how to square that circle.
>
> I followed all of this... except, what are you getting at with that last
> sentence?
>
> --
> Dave
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Fri Jul 22 2016, jaden.geller-AT-gmail.com wrote:

> What if you wanted to filter such that you keep values less than some
> element that happens to be positive zero; might that keep around any
> negative zeros? Seems problematic.

I agree.

>> On Jul 22, 2016, at 7:53 PM, Dave Abrahams  wrote:
>> 
>> 
>>> on Fri Jul 22 2016, Xiaodi Wu  wrote:
>>> 
 On Fri, Jul 22, 2016 at 9:38 PM,  wrote:
 
 This seems reasonable to me. I don't see why `===` has to do a total order
 comparison when we already have another operator, `<=>`, that does that.
>>> 
>>> I take it back. It wouldn't solve the issue that generic `<` would
>>> still behave in surprising ways, where two equal floating point values
>>> represented differently might be less than each other or greater than
>>> each other.
>> 
>> I wonder if that's really a problem.  What generic algorithm are you
>> going to run on a collection of floats where it *would* be problematic?
>> Hmm, stableSort would not necessarily preserve the order of zeros in the
>> original collection if it contained both positive and negative zeros.
>> 
>>> I think what we really want is all identity and comparison divorced
>>> from IEEE totalOrder.
>> 
>> That might work.  Thanks for thinking this problem through; keep it up!
>> 
 On Jul 22, 2016, at 7:35 PM, Xiaodi Wu  wrote:
 
 On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams 
 wrote:
 
> 
>> on Fri Jul 22 2016, Xiaodi Wu  wrote:
>> 
>> On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson <
> matt...@anandabits.com>
>> wrote:
>> 
>>> 
>>> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu  wrote:
>>> 
>>> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson <
> matt...@anandabits.com>
>>> wrote:
>>> 
 
 On Jul 22, 2016, at 9:04 PM, Xiaodi Wu  wrote:
 
 On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson <
> matt...@anandabits.com>
 wrote:
 
> 
> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
> On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>> "The totalOrder predicate will order these cases, and it also
>> distinguishes between different representations of NaNs and between
> the
>> same decimal floating point number encoded in different ways."
>> - [Wikipedia](
> https://en.wikipedia.org/wiki/IEEE_floating_point#Total-ordering_predicate
>> )
>> 
>> Sounds like `===` should not return `true` for zeros of different
>> signs, then.
> 
> Fair enough; the result of that will be, as Pyry noted above, that:
> 
> ```
> [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0
> ```
> 
> 
> Maybe we need floating point specific implementations of some
> algorithms
> to resolve this problem?
> 
> It doesn’t seem like there is a way to provide the semantics
> required by
> generic algorithms and still provide the expected behavior for
> floating
> point values.
 
 Well, what I'm trying to say is that generic algorithms such as
 `index(of:)` require only an equivalence relation. For floating point
 types, there are three ways to slice it:
 
 1. NaN != NaN and +0 == -0 [what the traditional comparison operators
> are
 constrained to do]
 2. NaN == NaN, +0 == -0, and the same number encoded different ways
 compare equal
 3. NaN == NaN, +0 != -0, and the same number encoded different ways
 compare not equal
 
 Both #2 and #3 can fall out of valid equivalence relations; if `===`
 behaved like #2 for FloatingPoint types, then generic algorithms work
> just
 fine. If we insist on using a total ordering defined by `<=>` all the
> time,
 then we've got problems.
 
 
 And if we don’t then we’re back to 3 different concepts of equality.
 There is definitely a tradeoff no matter what we choose.
>>> 
>>> If some types have three concepts of equality, each with their
> particular
>>> use, why must we eliminate one of them?
>>> 
>>> 
>>> This isn’t about eliminating concepts of equality for a type.  They can
>>> have 42 if they want.
>>> 
>>> This is about the right way to define the semantics of specific
>>> protocols.  It says nothing about additional notions of equality a
> type may
>>> have available.
>>> 
>>> The difficulty is finding a design for the protocols that makes sense
> with
>>> floating point types 

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

[Dave Abrahams via swift-evolution]

on Sat Jul 23 2016, Xiaodi Wu  wrote:

> On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon  wrote:
>
>> > 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 floating point.  Should +0 and -0 have the same identity or
>> > not?  I’ll leave the answer to folks more knowledgable about numerics
>> > than I.
>>
>> Boy, I take my wife out for a movie and come back to 50 new messages on SE.
>>
>> I need to read the entire thread more carefully, but off the top of my
>> head, I think that `-0 === +0` is False.  If we’re going to have an
>> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply
>> substitutability.  Although -0 == +0, they are not equivalent when
>> substituted:
>>
>> - 1/(-0) != 1/0
>> - Float(-0).sign != Float(+0).sign
>> - etc
>>
>> This probably then implies that `<=>` is not `.same` either.  I’ll read
>> the rest of this and respond more completely tomorrow.
>>
>
> Eagerly await your evaluation of the discussion. In the meantime:
>
> I think Dave's view that `===` defines identity in terms of "essential"
> qualities implies that two identical values can be
> different/non-substitutable in "inessential" qualities. For generic
> purposes, the sign of zero could be one such inessential quality.

Yes, and I think our view of how people work with numbers in swift (and
their protocol conformances) reflect this approach.  

http://article.gmane.org/gmane.comp.lang.swift.evolution/16321

My sense is that we want to choose the default notions of identity and
ordering so as to support the way people think about these numeric
types, inexact though it may be.  Therefore, finding 0.0 in a sequence
of floats should succeed when the sequence contains -0.0, and a stable
sort on floating point keys should preserve the relative order of all
elements having +0.0 and -0.0 keys.  

People that want to work with inessential qualities such as the sign of
zero can always pass Float.totalOrdering (or whatever) to their
closure-accepting algorithms.

[In order to support the user model, we still need to fix the semantics
of the default identity and ordering operations so that things like
sorting and searching work, which is why == and < won't cut it for these
purposes]

> On the other hand, the stdlib stride algorithm is going to be borked if -0
> < +0. Of course, as we already started to do there, we could specialize for
> floating point and then adjust accordingly. However, it seems to me that
> every generic algorithm that performs comparisons and can take floating
> point arguments would have to be specialized to account for floating point
> -0 != +0 (`index(of:)` being the previous example). This appears to defeat
> the aim of trying to accommodate FP at all in this revised design for
> Comparables.

Yes, that would be a disaster, generically speaking.

> The argument for `-0 === +0` is that -0 and +0 should be equivalent when
> substituted for every comparison operation. For FP operations, you'd
> continue to test (as you have to test now) `a == b && a.sign == b.sign` if
> you cared about the sign of zero. For non-FP arithmetic operations, hmm,
> not sure how to square that circle.

I followed all of this... except, what are you getting at with that last
sentence?

--
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jul 22, 2016 at 11:34 PM, Stephen Canon  wrote:

> > 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 floating point.  Should +0 and -0 have the same identity or
> > not?  I’ll leave the answer to folks more knowledgable about numerics
> > than I.
>
> Boy, I take my wife out for a movie and come back to 50 new messages on SE.
>
> I need to read the entire thread more carefully, but off the top of my
> head, I think that `-0 === +0` is False.  If we’re going to have an
> `isSame` / `isIdentical` / whatever it's called, I would expect it to imply
> substitutability.  Although -0 == +0, they are not equivalent when
> substituted:
>
> - 1/(-0) != 1/0
> - Float(-0).sign != Float(+0).sign
> - etc
>
> This probably then implies that `<=>` is not `.same` either.  I’ll read
> the rest of this and respond more completely tomorrow.
>

Eagerly await your evaluation of the discussion. In the meantime:

I think Dave's view that `===` defines identity in terms of "essential"
qualities implies that two identical values can be
different/non-substitutable in "inessential" qualities. For generic
purposes, the sign of zero could be one such inessential quality.

On the other hand, the stdlib stride algorithm is going to be borked if -0
< +0. Of course, as we already started to do there, we could specialize for
floating point and then adjust accordingly. However, it seems to me that
every generic algorithm that performs comparisons and can take floating
point arguments would have to be specialized to account for floating point
-0 != +0 (`index(of:)` being the previous example). This appears to defeat
the aim of trying to accommodate FP at all in this revised design for
Comparables.

The argument for `-0 === +0` is that -0 and +0 should be equivalent when
substituted for every comparison operation. For FP operations, you'd
continue to test (as you have to test now) `a == b && a.sign == b.sign` if
you cared about the sign of zero. For non-FP arithmetic operations, hmm,
not sure how to square that circle.


> – Steve
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev via swift-evolution]

Updated with changes written by Anton: 
https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md

Introduction

This proposal renames T.Type to Metatype, renames type(of:) to metatype(of:) 
and removes P.Protocol metatypes.

Swift-evolution threads:

[Revision] [Pitch] Rename T.Type
[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

Explanation of metatypes
Current behavior of .Protocol

For protocols P, besides normal P.Type, there is also a “restricting metatype” 
P.Protocol that is the same as P.Type, except that it can only reflect P itself 
and not any of its subtypes:

Int.self is CustomStringConvertible.Type  //=> true
Int.self is CustomStringConvertible.Protocol  //=> false
Even without P.Protocol, we can test for equality:

Int.self is CustomStringConvertible.Type  //=> true
Int.self == CustomStringConvertible.self  //=> false
For protocols P, P.self returns a P.Protocol, not P.Type:

let metatype = CustomStringConvertible.self
print(type(of: metatype))  //=> CustomStringConvertible.Protocol
In practise, the existence of P.Protocol creates problems. If T is a generic 
parameter, then T.Type turns into P.Protocol if a protocol P is passed:

func printMetatype(_ meta: T.Type) {
print(dynamicType(meta))
let copy = T.self
print(dynamicType(copy))
}

printMetatype(CustomStringConvertible.self)  //=> 
CustomStringConvertible.Protocol x2
Lets review the following situation:

func isIntSubtype(of: T.Type) -> Bool {
return Int.self is T.Type
}

isIntSubtype(of: CustomStringConvertible.self)  //=> false
Now we understand that because T is a protocol P, T.Type turns into a 
P.Protocol, and we get the confusing behaviour.

Summing up issues with P.Protocol, it does not bring any additional 
functionality (we can test .Types for is and for ==), but tends to appear 
unexpectedly and break subtyping with metatypes.

Even more issues with .Protocol

[1] When T is a protocol P, T.Type is the metatype of the protocol type itself, 
P.Protocol. Int.self is not P.self.

[2] There isn’t a way to generically expression P.Type yet.

[3] The syntax would have to be changed in the compiler to get something that 
behaves like .Type today.

Written by Joe Groff: [1] [2] [3]
There is a workaround for isIntSubtype example above. If we pass a P.Type.Type, 
then it turns into P.Type.Protocol, but it is still represented with .Type in 
generic contexts. If we manage to drop outer .Type, then we get P.Type:

func isIntSubtype(of _: T.Type) -> Bool {
  return Int.self is T   // not T.Type here anymore
}

isIntSubtype(of: CustomStringConvertible.Type.self) //=> true
In this call, T = CustomStringConvertible.Type. We can extend this issue and 
find the second problem by checking against the metatype of Any:

func isIntSubtype(of _: T.Type) -> Bool {
return Int.self is T
}

isIntSubtype(of: Any.Type.self) //=> true

isIntSubtype(of: Any.self)  //=> true
When using Any, the compiler does not require .Type and returns true for both 
variations.

The third issue shows itself when we try to check protocol relationship with 
another protocol. Currently, there is no way (that we know of) to solve this 
problem:

protocol Parent {}
protocol Child : Parent {}

func isChildSubtype(of _: T.Type) -> Bool {
return Child.self is T
}

isChildSubtype(of: Parent.Type.self) //=> false
We also believe that this issue is the reason why the current global functions 
sizeof, strideof and alignof make use of generic (_: T.Type) declaration 
notation instead of (_: Any.Type).

Magical members

There were the following “magical” members of all types/instances:

.dynamicType, which was replaced with type(of:) function by SE–0096.
.Type and .Protocol, which we propose to remove, see below.
.Self, which acts like an associatedtype.
.self, which will be reviewed in a separate proposal.
The tendency is to remove “magical” members: with this proposal there will only 
be .Self (does not count) and .self.

Also, .Type notation works like a generic type, and giving it generic syntax 
seems to be a good idea (unification).

Proposed solution

Remove P.Protocol type without a replacement. P.self will never return a 
P.Protocol.
Rename T.Type to Metatype.
Rename type(of:) function from SE–0096 to metatype(of:).
Impact on existing code

This is a source-breaking change that can be automated by a migrator. All 
occurrences of T.Type and T.Protocol will be changed to Metatype. All usages 
of type(of:) will be changed to metatype(of:)

Alternatives considered

Rename T.self to T.metatype. However, this can be proposed separately.
Use Type instead of Metatype. However, Metatype is more precise here.


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Review] SE-0130: Replace repeating Character and UnicodeScalar forms of String.init

[Haravikk via swift-evolution]

> On 22 Jul 2016, at 21:23, Chris Lattner via swift-evolution 
>  wrote:
>   * What is your evaluation of the proposal?

I think I'm generally in favour (see later).

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

It's pretty minor but disproportionately annoying, so worth addressing.

>   * Does this proposal fit well with the feel and direction of Swift?

This I'm not sure on, partly because no alternatives are given. In particular 
I'm wondering whether this could be addressed instead by adding a string 
literal version of the initialiser, as this should I think giving the compiler 
an exact match to select instead?

It's tough to weigh in on which is better though, as I don't use this much at 
all; I do however have a couple of uses of the Character initialiser that I'd 
be very slightly inconvenienced by if they were removed, but hardly upset 
about. I just wanted to float that I believe this may be an alternative that 
hasn't been considered:

public init(repeating repeatedValue:StringLiteralType, count:Int) { … }
public mutating func append(_ other:StringLiteralType) { … }

But both alternatives are sufficiently Swift-y, and I'm not too bothered either 
way so long as the ambiguity is addressed.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

[Georgios Moschovitis via swift-evolution]

> The current syntax establishes a relationship.
> 
> X: Y
> 
> means "X will have interface of Y". Note there's no mention of inheritance or 
> protocol here: they both establish this relationship. This is why we can use
> 
> z is Y
> 
> To check whether such relationship holds. Again, there's no need to worry 
> whether Y is a class or protocol.

Totally agree. You shouldn’t care if Y is a class or protocol. You might even 
want to convert a protocol to a class down the road.

The current syntax is great, no need for changes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 23 Jul 2016, at 06:00, Wang LiMing via swift-evolution 
>  wrote:
> 
> 
> There’s two case :
>1. Bug from customer’s code
>2. Bug from library/Framwork’s code
> 
> If we fix the case 1(forbidden subclass/overriding), means the 
> library/framework’s author must fix case 2
> 
> If want customer fix the case 2(allow subclass/overriding), means we can’t 
> fix the case 1
> 
> What’s our target? case 1 or case 2? 

Beside input validation, proper use of failable initialisers, and exceptions... 
how and why would you target case 1 further as a library author practically? It 
sounds like something useful in some cases and noble in intention but also a 
bit of a slippery slope to patronising your users... you may as well write the 
whole code for then ;). Seriously though, what would your reasons be for case 1?

> Case 1 depends on the decision of case 2(customer fix or author fix)
> 
> It’s big problem that can’t solved by language features.
> 
> 
> I think our target should be a language with better features that can improve 
> the quality of code/product.
> 
> 
> 
>> 在 2016年7月23日，上午2:39，Dave Abrahams via swift-evolution 
>>  写道：
>> 
>> 
>> on Fri Jul 22 2016, Paul Cantrell  wrote:
>> 
 On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution
  wrote:
 
 I wrote that subclassability is not an important element of safety
 **independent of overriding**.  If you don't allow any overriding,
 your code is always “resilient” enough to handle subclassing.
>>> 
>>> Code can make assumptions about a type having a fixed set of
>>> subclasses known at compile time:
>>> 
>>>switch foo {
>>>case is YinFoo:
>>>...
>>>case is YangFoo:
>>>...
>>>default:
>>>fatalError("only two kinds of Foo known")
>>>}
>>> 
>>> Granted, code like this is usually a sign of a flawed
>>> design. Reasonable uses for the “fixed, known set of subtypes” pattern
>>> are rare.
>>> 
>>> Design quality questions aside, however, it is not strictly true that
>>> preventing all member overrides guarantees that code is resilient to
>>> unexpected subclassing.
>> 
>> Point taken.
>> 
>> -- 
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Neubauer via swift-evolution]

> 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 floating point.  Should +0 and -0 have the same identity or
>> not?  I’ll leave the answer to folks more knowledgable about numerics
>> than I.
> 
> Boy, I take my wife out for a movie and come back to 50 new messages on SE.

I had the same feeling (short nap for the night and 96 new messages to this 
thread). I really do like the discussion whether NaN != NaN and similar cases 
are breaking the contract of ==. I think it is. I started some proposals last 
week [0], where I pointed out, that implementing equivalence relations is 
error-prone and the std lib is relying on it. We had there these special cases 
for Floating points, too. I think it is crucial to get `==` right, and then we 
get `<=` right :).

IMO, the core of the proposals idea is a good one: separating custom 
implementations from the ones that std lib relies on. Then you could have 
unchangeable default behavior (in terms of not allowing false-negatives like 
NaN != NaN) and still have custom implementations. The std lib (and any other 
library that needs equality and comparable follow the contract) will just 
continue working.

I didn’t read everything in this thread, but there were proposals to use === 
instead of isSame, but currently when I write `-0.0 === 0.0` just says that 
this operator is not implemented for Float (a value type). This makes totally 
sense, because value types have by definition no identity.

The discussions about is NaN != NaN and will code be portable and the like are 
reasonable, but Swift should IMO not try to make it easy for programmers of 
other languages to convert (hey Swift drops i++ and ++i and the like because 
this is not the focus), but to make it simple „as is“ (so for new programmers 
and for all who are willing to get oneself into Swift).

So putting all this special semantics for floating point into a special custom 
implementation would be good with me. It would be great if operators in Swift 
could contain letters. Then we could have `==` (standard conform) and `==f` or 
something like this for floating point semantics.

All the best
Johannes

[0]: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024599.html

> 
> I need to read the entire thread more carefully, but off the top of my head, 
> I think that `-0 === +0` is False.  If we’re going to have an `isSame` / 
> `isIdentical` / whatever it's called, I would expect it to imply 
> substitutability.  Although -0 == +0, they are not equivalent when 
> substituted:
> 
> - 1/(-0) != 1/0
> - Float(-0).sign != Float(+0).sign
> - etc
> 
> This probably then implies that `<=>` is not `.same` either.  I’ll read the 
> rest of this and respond more completely tomorrow.
> 
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Xiaodi Wu via swift-evolution]

On Sat, Jul 23, 2016 at 1:52 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 22, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution
> >  wrote:
> >> I have been looking at the parts of this proposal related to
> >> withUnsafe[Mutable]Pointer:
> >>
> > [...]
> >
> > I agree with everything that Bob said, and I would like to comment on
> this part:
> >
> >> unsafeAddressOf is removed, in favor of adding a unsafeAddress field on
> ObjectIdentifier. ObjectIdentifier already contains a raw pointer in the
> internal _value field and can be initialized with AnyObject just like the
> argument of unsafeAddressOf.
> >
> > I think we should not add the ObjectIdentifier.unsafeAddress API.  I
> > don't agree with the motivation from the proposal:
> >
> >> Remove unsafeAddressOf and use Unmanaged.takeUnretainedValue(_:)
> instead. This, however, requires the caller to deal with retain logic for
> something as simple as getting an object address.
> >
> > We want users to be explicit about their reference counting semantics
> > when working unsafely with object addresses.  Otherwise it is not
> > clear for how long the resulting pointer is valid.  Getting an unsafe
> > object address is not "simple", it is not commonly when working with
> > Swift or Objective-C APIs, and there should be no need to have
> > shorthand convenience syntax for it.  The current way to perform
> > manual reference counting and bridging of objects to the unsafe world
> > is through Unmanaged, so the conversion from object to a pointer
> > should be on Unmanaged (where it is now).
>
> The general consensus on where the unsafeAddressOf is used the mosed has
> been settled (here in the original discussion and what I've googled on
> Stackoverflow) on that it's mostly used for logging an object address as
> part of description or debugDescription (or various other debugging
> purposes).
>
> In the original discussion about the pointer and buffer routines cleanup
> here Jordan suggested using ObjectIdentifier instead (
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23168) - and I
> have to agree with him. Not that the entire ObjectIdentifier should be
> interpoled into the description string, but that ObjectIdentifier expresses
> what you want.
>

ObjectIdentifier itself conforms to Hashable, and I recently patched it to
be CustomDebugStringConvertible, so that you can not only compare
ObjectIdentifier instances to know if objects live at the same address, you
can now log a unique debug description for each instance. That should be
sufficient for most use cases you describe above. If you actually need the
*address* and not just some identifier for the object (presumably because
you'll use that information to do something at that address), then surely
you should explicitly indicate what you're doing about reference counting.


> The ObjectIdentifier IMHO has potential for more - a lot of various
> debugging purposes come to mind since it can point to an object that is no
> longer allocated. In this sense, it could also hold dynamicType of the
> object it was created with, but that's purely additive, so I left it out of
> this proposal.
>
> I still believe that the ObjectIdentifier is missing the "unsafeAddress"
> property that would expose the already-contained internal raw pointer. And
> for most uses of the current unsafeAddressOf, this is the equivalent
> behavior.
>
> As Xiaodi has mentioned as an argument for keeping both withUnsafePointer
> and withUnsafeMutablePointer for the sake of readibility and expressing
> your intentions, this is a similar case:
>
> print(Unmanaged.takeUnretained(obj))
>
> vs.
>
> print(ObjectIdentifer(obj).unsafeAddress)
>
> The first doesn't express the intentions at all, while the latter does.
> Using the first one seems like an abuse of the fact that the "Unretained"
> returns the same address - AFAIK, if you have an ObjC class that implements
> its own retain selector, it can theoretically return another value via
> takeRetained.
>
> Or, another alternative is to use
>
> unsafeBitCast(obj, to: UnsafePointer.self)
>
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j > (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Charlie Monroe via swift-evolution]

> On Jul 22, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution 
>  wrote:
> 
> On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution
>  wrote:
>> I have been looking at the parts of this proposal related to
>> withUnsafe[Mutable]Pointer:
>> 
> [...]
> 
> I agree with everything that Bob said, and I would like to comment on this 
> part:
> 
>> unsafeAddressOf is removed, in favor of adding a unsafeAddress field on 
>> ObjectIdentifier. ObjectIdentifier already contains a raw pointer in the 
>> internal _value field and can be initialized with AnyObject just like the 
>> argument of unsafeAddressOf.
> 
> I think we should not add the ObjectIdentifier.unsafeAddress API.  I
> don't agree with the motivation from the proposal:
> 
>> Remove unsafeAddressOf and use Unmanaged.takeUnretainedValue(_:) instead. 
>> This, however, requires the caller to deal with retain logic for something 
>> as simple as getting an object address.
> 
> We want users to be explicit about their reference counting semantics
> when working unsafely with object addresses.  Otherwise it is not
> clear for how long the resulting pointer is valid.  Getting an unsafe
> object address is not "simple", it is not commonly when working with
> Swift or Objective-C APIs, and there should be no need to have
> shorthand convenience syntax for it.  The current way to perform
> manual reference counting and bridging of objects to the unsafe world
> is through Unmanaged, so the conversion from object to a pointer
> should be on Unmanaged (where it is now).

The general consensus on where the unsafeAddressOf is used the mosed has been 
settled (here in the original discussion and what I've googled on 
Stackoverflow) on that it's mostly used for logging an object address as part 
of description or debugDescription (or various other debugging purposes).

In the original discussion about the pointer and buffer routines cleanup here 
Jordan suggested using ObjectIdentifier instead 
(http://article.gmane.org/gmane.comp.lang.swift.evolution/23168) - and I have 
to agree with him. Not that the entire ObjectIdentifier should be interpoled 
into the description string, but that ObjectIdentifier expresses what you want.

The ObjectIdentifier IMHO has potential for more - a lot of various debugging 
purposes come to mind since it can point to an object that is no longer 
allocated. In this sense, it could also hold dynamicType of the object it was 
created with, but that's purely additive, so I left it out of this proposal.

I still believe that the ObjectIdentifier is missing the "unsafeAddress" 
property that would expose the already-contained internal raw pointer. And for 
most uses of the current unsafeAddressOf, this is the equivalent behavior.

As Xiaodi has mentioned as an argument for keeping both withUnsafePointer and 
withUnsafeMutablePointer for the sake of readibility and expressing your 
intentions, this is a similar case:

print(Unmanaged.takeUnretained(obj))

vs.

print(ObjectIdentifer(obj).unsafeAddress)

The first doesn't express the intentions at all, while the latter does. Using 
the first one seems like an abuse of the fact that the "Unretained" returns the 
same address - AFAIK, if you have an ObjC class that implements its own retain 
selector, it can theoretically return another value via takeRetained.

Or, another alternative is to use

unsafeBitCast(obj, to: UnsafePointer.self)

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jaden Geller via swift-evolution]

What if you wanted to filter such that you keep values less than some element 
that happens to be positive zero; might that keep around any negative zeros? 
Seems problematic.

> On Jul 22, 2016, at 7:53 PM, Dave Abrahams  wrote:
> 
> 
>> on Fri Jul 22 2016, Xiaodi Wu  wrote:
>> 
>>> On Fri, Jul 22, 2016 at 9:38 PM,  wrote:
>>> 
>>> This seems reasonable to me. I don't see why `===` has to do a total order
>>> comparison when we already have another operator, `<=>`, that does that.
>> 
>> I take it back. It wouldn't solve the issue that generic `<` would
>> still behave in surprising ways, where two equal floating point values
>> represented differently might be less than each other or greater than
>> each other.
> 
> I wonder if that's really a problem.  What generic algorithm are you
> going to run on a collection of floats where it *would* be problematic?
> Hmm, stableSort would not necessarily preserve the order of zeros in the
> original collection if it contained both positive and negative zeros.
> 
>> I think what we really want is all identity and comparison divorced
>> from IEEE totalOrder.
> 
> That might work.  Thanks for thinking this problem through; keep it up!
> 
>>> On Jul 22, 2016, at 7:35 PM, Xiaodi Wu  wrote:
>>> 
>>> On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams 
>>> wrote:
>>> 
 
> on Fri Jul 22 2016, Xiaodi Wu  wrote:
> 
> On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson <
 matt...@anandabits.com>
> wrote:
> 
>> 
>> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu  wrote:
>> 
>> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson <
 matt...@anandabits.com>
>> wrote:
>> 
>>> 
>>> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu  wrote:
>>> 
>>> On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson <
 matt...@anandabits.com>
>>> wrote:
>>> 
 
 On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:
 
 On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution <
 swift-evolution@swift.org> wrote:
 
> "The totalOrder predicate will order these cases, and it also
> distinguishes between different representations of NaNs and between
 the
> same decimal floating point number encoded in different ways."
> - [Wikipedia](
 https://en.wikipedia.org/wiki/IEEE_floating_point#Total-ordering_predicate
> )
> 
> Sounds like `===` should not return `true` for zeros of different
> signs, then.
 
 Fair enough; the result of that will be, as Pyry noted above, that:
 
 ```
 [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0
 ```
 
 
 Maybe we need floating point specific implementations of some
 algorithms
 to resolve this problem?
 
 It doesn’t seem like there is a way to provide the semantics
 required by
 generic algorithms and still provide the expected behavior for
 floating
 point values.
>>> 
>>> Well, what I'm trying to say is that generic algorithms such as
>>> `index(of:)` require only an equivalence relation. For floating point
>>> types, there are three ways to slice it:
>>> 
>>> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators
 are
>>> constrained to do]
>>> 2. NaN == NaN, +0 == -0, and the same number encoded different ways
>>> compare equal
>>> 3. NaN == NaN, +0 != -0, and the same number encoded different ways
>>> compare not equal
>>> 
>>> Both #2 and #3 can fall out of valid equivalence relations; if `===`
>>> behaved like #2 for FloatingPoint types, then generic algorithms work
 just
>>> fine. If we insist on using a total ordering defined by `<=>` all the
 time,
>>> then we've got problems.
>>> 
>>> 
>>> And if we don’t then we’re back to 3 different concepts of equality.
>>> There is definitely a tradeoff no matter what we choose.
>> 
>> If some types have three concepts of equality, each with their
 particular
>> use, why must we eliminate one of them?
>> 
>> 
>> This isn’t about eliminating concepts of equality for a type.  They can
>> have 42 if they want.
>> 
>> This is about the right way to define the semantics of specific
>> protocols.  It says nothing about additional notions of equality a
 type may
>> have available.
>> 
>> The difficulty is finding a design for the protocols that makes sense
 with
>> floating point types because we want them to be able to conform to the
>> protocols.
> 
> Agreed. My argument is that if a Comparable can define its own `===`,
 still
> supplying a valid equivalence 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Charlie Monroe via swift-evolution]

Ok, I'll update the proposal to withdraw the change of inout for 
withUnsafePointer.

Under the discussion for the pull request, Bob mentioned possible removal of 
the multi-pointer variants (i.e. withUnsafe[Mutable]Pointers) - is this 
something that you'd agree on? 

If so, I'd add this to the proposal since I agree that this is an API that is 
rarely used, can be used by nesting two withUnsafe[Mutable]Pointer calls and is 
limited to three pointers at max anyway. It almost feels like NSAssert1, 
NSAssert2, etc.

> On Jul 23, 2016, at 3:35 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Jul 22 2016, Xiaodi Wu  wrote:
> 
>> On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> 
>>> 
>>> on Fri Jul 22 2016, Xiaodi Wu  wrote:
>>> 
 On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution <
 swift-evolution@swift.org> wrote:
 
> 
> on Fri Jul 22 2016, Bob Wilson  wrote:
> 
>> It is not so clear what to do about SR-1956. (Charlie and I had some
>> comments on this in https://github.com/apple/swift-evolution/pull/437
>> .) Jordan raised
>> the objection that when using withUnsafePointer with a global, there
>> is an expectation that you’ll get the same address every
>> time. Removing inout would cause the argument to be passed by value
>> and the address would refer to a copy. Dmitri agreed that this could
>> be a problem. On the other hand, if you don’t care about the address,
>> or if you’re not using a value type, it would indeed be convenient to
>> have a version of withUnsafePointer that does not require an inout
>> argument.
>> 
>> Option 1: Keep inout (not addressing SR-1956). In this case, there’s
>> no reason to have both withUnsafePointer and
>> withUnsafeMutablePointer. If you want to call a function that expects
>> an UnsafePointer, you can give it an UnsafeMutablePointer and there
>> will be an implicit conversion to make it work. I discussed this with
>> Apple’s stdlib team and they recommended that if we have only one
>> function we use the shorter name “withUnsafePointer” and have it use
>> an UnsafeMutablePointer.
> 
> Very much in favor of Option 1.
> 
 
 Ditto, except that I think there is some value in keeping both (i.e.
>>> doing
 nothing): allowing the user to document intent. It would be inconsistent
 and potentially confusing to call the function that returns an
 `UnsafeMutablePointer` `withUnsafePointer`.
>>> 
>>> It doesn't return an `UnsafeMutablePointer`, it passes an
>>> `UnsafeMutablePointer` to the body of the closure.
>>> 
>> 
>> Brainfart. Yes, that's what I meant to write. Sorry.
>> 
 It's rarely used enough, and the shorter name needlessly raises the
 question of where I'm really "supposed to be" mutating the
 pointee.
>>> 
>>> I don't understand; you only have the pointee inside the closure.
>>> That's where you mutate it (obviously?)
>>> 
>> 
>> If my closure does not mutate the pointee, `withUnsafePointer(_:)` allows
>> me to document that. Everything *works* with
>> `withUnsafeMutablePointer(_:)`, but I cannot read the code and understand
>> that no mutation has happened within the body of the closure. [Am I wrong
>> on this?]
> 
> No, you're right.
> 
>> For instance, I've been working with some of the Accelerate.framework
>> functions and the arguments are often cryptic. Take this call:
>> 
>> ```
>> cblas_sgemm(CblasColMajor, CblasNoTrans, CblasNoTrans, m, n, k, 1, matrix,
>> m, b, k, 1, , m)
>> ```
>> 
>> There are times when I'd want to
>> call `cblas_sgemm(_:_:_:_:_:_:_:_:_:_:_:_:_:_:)` inside an
>> `withUnsafe[Mutable]Pointer(_:)` closure. Distinguishing
>> `withUnsafePointer(_:)` and `withUnsafeMutablePointer(_:)` would allow a
>> reader to know from the outset if `$0.pointee is mutated without having to
>> know that the second-from-last argument is the one that stores the result
>> (it is not consistently second-from-last; for vDSP_* functions, it's often
>> the third-from-last argument, and for others it can be the first argument).
>> Removing the current `withUnsafePointer(_:)` would decrease clarity for the
>> reader here.
> 
> Okay, fair enough.
> 
>>> I've not had to use these functions much, but the distinction between
 `Array.withUnsafeBufferPointer(_:)` and
 `Array.withUnsafeMutableBufferPointer(_:)` has conditioned me to
 mutate the pointee using only "mutable" functions.
>>> 
>>> Not sure if you're just drawing an analogy,
>> 
>> I was trying to. I guess ineffectively.
>> 
>>> but if not, those two
>>> methods are not under discussion here.  They are meaningfully different,
>>> whereas the existing functions are not, and the one currently called
>>> withUnsafePointer is always going to