Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Jacob Bandes-Storch via swift-evolution]

The latest comment from Brent on the PR indicated that it's ready, I
believe.

Jacob

On Sun, Jul 24, 2016 at 10:39 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Jose Cheyo Jimenez via swift-evolution  writes:
> >
> >>
> >> Is your proposal going to make the swift3 window?
> >
> > It should.  I'm planning on merging it and launching the review
> > if Chris L doesn't beat me to it (which I hope he will ;-)).
>
> I’m still waiting to be told that it is ready.  You guys appear to still
> be iterating in the PR.
>
> -Chris
> ___
> 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] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Chris Lattner via swift-evolution]

> On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Jose Cheyo Jimenez via swift-evolution  writes:
> 
>> 
>> Is your proposal going to make the swift3 window? 
> 
> It should.  I'm planning on merging it and launching the review 
> if Chris L doesn't beat me to it (which I hope he will ;-)).

I’m still waiting to be told that it is ready.  You guys appear to still be 
iterating in the PR.

-Chris
___
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

[Charlie Monroe via swift-evolution]

> ES++

^-- error: '++' is unavailable: it has been removed in Swift 3

:)

>  for exactly the same reasons. I use postfix increment because I didn’t even 
> think of the completion angle until Mark brought it up. The fingers type what 
> the fingers type.
> 
> I also support for the other many fine reasons previously mentioned in this 
> thread: matches user expectations, the description is more commonly used in 
> art than NUL, which remains obscure even if technically accurate. See also: 
> https://en.wikipedia.org/wiki/Null-terminated_string 
> . I want to contribute 
> to the “broad community support for renaming”.
> 
> That said, I’d prefer utf8String and utf8CString, but I suspect that’s a 
> non-starter, and the initial pitch misidentifies the properties as methods.
> 
> — E
> 
> 
>> On Jul 24, 2016, at 11:39 AM, Mark Dalrymple via swift-evolution 
>> > wrote:
>> 
>> +1, mainly because if someone uses on-demand completion (like me) thinking 
>> it's called "nullTerminated", typing "null" will not complete if the method 
>> name is "nulTerminated"
>> 
>> ++md
>> 
> 
> ___
> 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] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

Yep. With my proposed renaming this would work:

[["hey"], ["what"]].joined().joined(separator: “”)

But so would this, if you prefer it:

[["hey"], ["what"]].joined().joined()

On Sun, Jul 24, 2016 at 6:06 PM, Jose Cheyo Jimenez 
wrote:

> [["hey"], ["what"]].joined().joined() // proposed
>
> vs
>
> [["hey"], ["what"]].flatten().joined(separator: “”) // now
>
> I do agree that having two way of doing it now seems odd.
>
> [["hey"], ["what"]].joined(separator: []).joined(separator: “”)  // now
>
>
>
>
> On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch 
> wrote:
>
> The thing is, joined also works on arrays-of-arrays today. The only
> difference is that flatten doesn't have a separator.
>
> We wouldn't lose what your example shows — you could do this:
>
> [["hey"], ["what"]].joined().joined(separator: “")
> On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez 
> wrote:
>
>> Here is a quick example that we would loose.
>>
>> [["hey"], ["what"]].flatten().joined(separator: “")
>>
>> [["hey"], ["what"]].flatten() //  ["hey", "what”]
>>
>> The way I think of it is flatten works on array of arrays while joined
>> works on arrays of strings.
>>
>> I guess we could do this too
>>
>> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
>>
>>
>>
>> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez 
>> wrote:
>>
>> -1 for this. To me there needs to be a difference between String (which
>> is not a normal collection) and other regular collections.
>>
>> In addition, I really don’t think this proposal has the needed strong
>> support for the change.
>>
>>
>>
>>
>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Here's a proposal draft. Comments welcome:
>>
>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325
>>
>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington 
>> wrote:
>>
>>>
>>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch 
>>> wrote:
>>> >
>>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
>>> wrote:
>>> >>
>>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>> >>>
>>> >>> In the swift-lang Slack channel, a few of us were discussing
>>> joined(separator:) and realized that flatten() does almost exactly the same
>>> thing.
>>> >>>
>>> >>> Is there interest in renaming flatten() to joined()?  Since joined
>>> takes a separator that's any Sequence, we can't have a default value for
>>> the separator parameter, but we can have a variant of joined() with no
>>> arguments.
>>> >>
>>> >> I'd like default separators for the joined() methods.
>>> >>
>>> >> 
>>> >>
>>> >> But renaming flatten() to joined() seems complicated.
>>> >>
>>> >> <
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>>> >
>>> >> <
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift
>>> >
>>> >
>>> > What makes it seem complicated? At the very least, one could just
>>> rename the flatten() function. There might also be an opportunity to
>>> combine the two files and delete some code from stdlib.
>>>
>>> There's only one joined() method (for a sequence of sequences):
>>>
>>> extension Sequence {
>>>   func joined(separator: Separator) ->
>>> JoinedSequence
>>> }
>>>
>>> There are many flatten() methods (`where` clauses omitted for brevity):
>>>
>>> extension Sequence {
>>>   func flatten() -> FlattenSequence
>>> }
>>>
>>> extension LazySequenceProtocol {
>>>   func flatten() -> LazySequence
>>> }
>>>
>>> extension LazyCollectionProtocol {
>>>   func flatten() ->
>>> LazyCollection
>>> }
>>>
>>> extension Collection {
>>>   func flatten() -> FlattenCollection
>>> }
>>>
>>> extension BidirectionalCollection {
>>>   func flatten() -> FlattenBidirectionalCollection
>>> }
>>>
>>> So it's not a simple one-to-one rename.
>>>
>>> When there's no `separator` argument, will FlattenIterator perform
>>> better than JoinedIterator?
>>>
>>> >> And what would happen to the flatMap() methods? Is flatten() a term
>>> of art?
>>> >>
>>> >> <
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>>> >
>>> >
>>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just
>>> describes literally what is being done. Frankly I'm surprised it was never
>>> named flattened(). Anyway, flatMap should stay.
>>>
>>> ## Future directions
>>>
>>> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>>>
>>
>> That's an interesting idea. It seems to be purely additive, however, so I
>> imagine it wouldn't happen until after Swift 3.
>>
>>
>>> -- Ben
>>>
>>>
>> 

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

[Pyry Jahkola via swift-evolution]

> Dave Abrahams wrote:
> 
> Asking whether zero appears in a sequence that happened to contain a NaN 
> would equally be a precondition violation.

No, it wouldn't because Double would implement Equatable + Comparable by 
providing custom implementations of ==, <, >, <=, and >=, in addition to 
Double.<=> which may trap.

My point in 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025375.html
 is that by keeping all those operators within the required interface of 
protocol Comparable, such customisation remains possible. The original proposal 
only suggested == in Equatable and <=> in Comparable. If that were the case, 
then generic algorithms would necessarily end up calling <=>.

It is key that not only <=> is a customisation point of Comparable. Only those 
generic algorithms which used <=> directly (e.g. sort, partition, binary 
search) would see precondition violations if the sequence contained one or more 
NaNs.

***

Another possible choice would be to return .descending whenever either of the 
comparands were NaN, while also making <, >, <=, and >= return false in such 
cases. Then we wouldn't see preconditionFailures but instead produced bogus 
results from sort, partition etc. That's the tradeoff Haskell has chosen for 
its `compare` function over Double, FWIW.

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

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

[["hey"], ["what"]].joined().joined() // proposed

vs

[["hey"], ["what"]].flatten().joined(separator: “”) // now

I do agree that having two way of doing it now seems odd. 

[["hey"], ["what"]].joined(separator: []).joined(separator: “”)  // now




> On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch  wrote:
> 
> The thing is, joined also works on arrays-of-arrays today. The only 
> difference is that flatten doesn't have a separator.
> 
> We wouldn't lose what your example shows — you could do this:
> 
> [["hey"], ["what"]].joined().joined(separator: “")
> On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez  > wrote:
> Here is a quick example that we would loose.
> 
> [["hey"], ["what"]].flatten().joined(separator: “")
> 
> [["hey"], ["what"]].flatten() //  ["hey", "what”]
> 
> The way I think of it is flatten works on array of arrays while joined works 
> on arrays of strings. 
> 
> I guess we could do this too
> 
> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
> 
> 
> 
>> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> -1 for this. To me there needs to be a difference between String (which is 
>> not a normal collection) and other regular collections. 
>> 
>> In addition, I really don’t think this proposal has the needed strong 
>> support for the change. 
>> 
>> 
>> 
>> 
>>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> Here's a proposal draft. Comments welcome:
>>> 
>>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington >> > wrote:
>>> 
>>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch >> > > wrote:
>>> >
>>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington >> >> > wrote:
>>> >>
>>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>> >>>
>>> >>> In the swift-lang Slack channel, a few of us were discussing 
>>> >>> joined(separator:) and realized that flatten() does almost exactly the 
>>> >>> same thing.
>>> >>>
>>> >>> Is there interest in renaming flatten() to joined()?  Since joined 
>>> >>> takes a separator that's any Sequence, we can't have a default value 
>>> >>> for the separator parameter, but we can have a variant of joined() with 
>>> >>> no arguments.
>>> >>
>>> >> I'd like default separators for the joined() methods.
>>> >>
>>> >> >> >> >
>>> >>
>>> >> But renaming flatten() to joined() seems complicated.
>>> >>
>>> >> >> >>  
>>> >> >
>>> >> >> >>  
>>> >> >
>>> >
>>> > What makes it seem complicated? At the very least, one could just rename 
>>> > the flatten() function. There might also be an opportunity to combine the 
>>> > two files and delete some code from stdlib.
>>> 
>>> There's only one joined() method (for a sequence of sequences):
>>> 
>>> extension Sequence {
>>>   func joined(separator: Separator) -> 
>>> JoinedSequence
>>> }
>>> 
>>> There are many flatten() methods (`where` clauses omitted for brevity):
>>> 
>>> extension Sequence {
>>>   func flatten() -> FlattenSequence
>>> }
>>> 
>>> extension LazySequenceProtocol {
>>>   func flatten() -> LazySequence
>>> }
>>> 
>>> extension LazyCollectionProtocol {
>>>   func flatten() -> LazyCollection
>>> }
>>> 
>>> extension Collection {
>>>   func flatten() -> FlattenCollection
>>> }
>>> 
>>> extension BidirectionalCollection {
>>>   func flatten() -> FlattenBidirectionalCollection
>>> }
>>> 
>>> So it's not a simple one-to-one rename.
>>> 
>>> When there's no `separator` argument, will FlattenIterator perform better 
>>> than JoinedIterator?
>>> 
>>> >> And what would happen to the flatMap() methods? Is flatten() a term of 
>>> >> art?
>>> >>
>>> >> >> >>  
>>> >> >
>>> >
>>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
>>> > describes literally what is being done. Frankly I'm surprised it was 
>>> > never named 

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

The thing is, joined also works on arrays-of-arrays today. The only
difference is that flatten doesn't have a separator.

We wouldn't lose what your example shows — you could do this:

[["hey"], ["what"]].joined().joined(separator: “")
On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez 
wrote:

> Here is a quick example that we would loose.
>
> [["hey"], ["what"]].flatten().joined(separator: “")
>
> [["hey"], ["what"]].flatten() //  ["hey", "what”]
>
> The way I think of it is flatten works on array of arrays while joined
> works on arrays of strings.
>
> I guess we could do this too
>
> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
>
>
>
> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez 
> wrote:
>
> -1 for this. To me there needs to be a difference between String (which is
> not a normal collection) and other regular collections.
>
> In addition, I really don’t think this proposal has the needed strong
> support for the change.
>
>
>
>
> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Here's a proposal draft. Comments welcome:
>
> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325
>
> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington 
> wrote:
>
>>
>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch 
>> wrote:
>> >
>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington 
>> wrote:
>> >>
>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>> >>>
>> >>> In the swift-lang Slack channel, a few of us were discussing
>> joined(separator:) and realized that flatten() does almost exactly the same
>> thing.
>> >>>
>> >>> Is there interest in renaming flatten() to joined()?  Since joined
>> takes a separator that's any Sequence, we can't have a default value for
>> the separator parameter, but we can have a variant of joined() with no
>> arguments.
>> >>
>> >> I'd like default separators for the joined() methods.
>> >>
>> >> 
>> >>
>> >> But renaming flatten() to joined() seems complicated.
>> >>
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>> >
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift>
>> >
>> > What makes it seem complicated? At the very least, one could just
>> rename the flatten() function. There might also be an opportunity to
>> combine the two files and delete some code from stdlib.
>>
>> There's only one joined() method (for a sequence of sequences):
>>
>> extension Sequence {
>>   func joined(separator: Separator) ->
>> JoinedSequence
>> }
>>
>> There are many flatten() methods (`where` clauses omitted for brevity):
>>
>> extension Sequence {
>>   func flatten() -> FlattenSequence
>> }
>>
>> extension LazySequenceProtocol {
>>   func flatten() -> LazySequence
>> }
>>
>> extension LazyCollectionProtocol {
>>   func flatten() ->
>> LazyCollection
>> }
>>
>> extension Collection {
>>   func flatten() -> FlattenCollection
>> }
>>
>> extension BidirectionalCollection {
>>   func flatten() -> FlattenBidirectionalCollection
>> }
>>
>> So it's not a simple one-to-one rename.
>>
>> When there's no `separator` argument, will FlattenIterator perform better
>> than JoinedIterator?
>>
>> >> And what would happen to the flatMap() methods? Is flatten() a term of
>> art?
>> >>
>> >> <
>> https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>> >
>> >
>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just
>> describes literally what is being done. Frankly I'm surprised it was never
>> named flattened(). Anyway, flatMap should stay.
>>
>> ## Future directions
>>
>> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>>
>
> That's an interesting idea. It seems to be purely additive, however, so I
> imagine it wouldn't happen until after Swift 3.
>
>
>> -- Ben
>>
>>
> ___
> 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] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() //  ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined works on 
arrays of strings. 

I guess we could do this too

[["hey"], ["what"]].joined(separator: []).joined(separator: "")



> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez  wrote:
> 
> -1 for this. To me there needs to be a difference between String (which is 
> not a normal collection) and other regular collections. 
> 
> In addition, I really don’t think this proposal has the needed strong support 
> for the change. 
> 
> 
> 
> 
>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> Here's a proposal draft. Comments welcome:
>> 
>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
>> 
>> 
>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington > > wrote:
>> 
>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch > > > wrote:
>> >
>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington > >> > wrote:
>> >>
>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>> >>>
>> >>> In the swift-lang Slack channel, a few of us were discussing 
>> >>> joined(separator:) and realized that flatten() does almost exactly the 
>> >>> same thing.
>> >>>
>> >>> Is there interest in renaming flatten() to joined()?  Since joined takes 
>> >>> a separator that's any Sequence, we can't have a default value for the 
>> >>> separator parameter, but we can have a variant of joined() with no 
>> >>> arguments.
>> >>
>> >> I'd like default separators for the joined() methods.
>> >>
>> >> > >> >
>> >>
>> >> But renaming flatten() to joined() seems complicated.
>> >>
>> >> > >>  
>> >> >
>> >> > >> >
>> >
>> > What makes it seem complicated? At the very least, one could just rename 
>> > the flatten() function. There might also be an opportunity to combine the 
>> > two files and delete some code from stdlib.
>> 
>> There's only one joined() method (for a sequence of sequences):
>> 
>> extension Sequence {
>>   func joined(separator: Separator) -> 
>> JoinedSequence
>> }
>> 
>> There are many flatten() methods (`where` clauses omitted for brevity):
>> 
>> extension Sequence {
>>   func flatten() -> FlattenSequence
>> }
>> 
>> extension LazySequenceProtocol {
>>   func flatten() -> LazySequence
>> }
>> 
>> extension LazyCollectionProtocol {
>>   func flatten() -> LazyCollection
>> }
>> 
>> extension Collection {
>>   func flatten() -> FlattenCollection
>> }
>> 
>> extension BidirectionalCollection {
>>   func flatten() -> FlattenBidirectionalCollection
>> }
>> 
>> So it's not a simple one-to-one rename.
>> 
>> When there's no `separator` argument, will FlattenIterator perform better 
>> than JoinedIterator?
>> 
>> >> And what would happen to the flatMap() methods? Is flatten() a term of 
>> >> art?
>> >>
>> >> > >>  
>> >> >
>> >
>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
>> > describes literally what is being done. Frankly I'm surprised it was never 
>> > named flattened(). Anyway, flatMap should stay.
>> 
>> ## Future directions
>> 
>> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>> 
>> That's an interesting idea. It seems to be purely additive, however, so I 
>> imagine it wouldn't happen until after Swift 3.
>> 
>> 
>> -- Ben
>> 
>> 
>> ___
>> 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

[Boris Wang via swift-evolution]

Good point,
Redundant may be a dangerous indication for unsuitable classification in
program design.

By the name,I will think there has non-null terminated CString.
But strings always terminated by null in language C.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

-1 for this. To me there needs to be a difference between String (which is not 
a normal collection) and other regular collections. 

In addition, I really don’t think this proposal has the needed strong support 
for the change. 




> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Here's a proposal draft. Comments welcome:
> 
> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
> 
> 
> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington  > wrote:
> 
> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch  > > wrote:
> >
> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington  >> > wrote:
> >>
> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
> >>>
> >>> In the swift-lang Slack channel, a few of us were discussing 
> >>> joined(separator:) and realized that flatten() does almost exactly the 
> >>> same thing.
> >>>
> >>> Is there interest in renaming flatten() to joined()?  Since joined takes 
> >>> a separator that's any Sequence, we can't have a default value for the 
> >>> separator parameter, but we can have a variant of joined() with no 
> >>> arguments.
> >>
> >> I'd like default separators for the joined() methods.
> >>
> >>  >> >
> >>
> >> But renaming flatten() to joined() seems complicated.
> >>
> >>  >>  
> >> >
> >>  >> >
> >
> > What makes it seem complicated? At the very least, one could just rename 
> > the flatten() function. There might also be an opportunity to combine the 
> > two files and delete some code from stdlib.
> 
> There's only one joined() method (for a sequence of sequences):
> 
> extension Sequence {
>   func joined(separator: Separator) -> 
> JoinedSequence
> }
> 
> There are many flatten() methods (`where` clauses omitted for brevity):
> 
> extension Sequence {
>   func flatten() -> FlattenSequence
> }
> 
> extension LazySequenceProtocol {
>   func flatten() -> LazySequence
> }
> 
> extension LazyCollectionProtocol {
>   func flatten() -> LazyCollection
> }
> 
> extension Collection {
>   func flatten() -> FlattenCollection
> }
> 
> extension BidirectionalCollection {
>   func flatten() -> FlattenBidirectionalCollection
> }
> 
> So it's not a simple one-to-one rename.
> 
> When there's no `separator` argument, will FlattenIterator perform better 
> than JoinedIterator?
> 
> >> And what would happen to the flatMap() methods? Is flatten() a term of art?
> >>
> >>  >>  
> >> >
> >
> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
> > describes literally what is being done. Frankly I'm surprised it was never 
> > named flattened(). Anyway, flatMap should stay.
> 
> ## Future directions
> 
> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
> 
> That's an interesting idea. It seems to be purely additive, however, so I 
> imagine it wouldn't happen until after Swift 3.
> 
> 
> -- Ben
> 
> 
> ___
> 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

[Xiaodi Wu via swift-evolution]

On Sun, Jul 24, 2016 at 7:09 PM, Dave Abrahams  wrote:

>
> on Sun Jul 24 2016, Saagar Jha  wrote:
>
> > Ahh…I agree in that case; something like `utf8Array` might be a better
> > choice.
>
>   Array(s.utf8)
>
> seems expressive enough to me, if what you really want is an array.  IMO
> we should consider dropping other spellings.
>

One reason why `nullTerminatedUTF8` is a pretty good name, IMO:
Array(s.utf8) is exactly one element short of Array(s.nullTeminatedUTF8),
that being the null terminator. Incidentally, Array(s.utf8) is actually a
little problematic, afaict, as its inferred type is Array<_Element>,
whatever that is. Array(s.utf8) works though.


> > Saagar Jha
> >
> >> On Jul 24, 2016, at 16:44, Xiaodi Wu  wrote:
> >>
> >> On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha  > wrote:
> >> Well, yes, but hardly anyone calls it a “char array” unless they’re
> >> trying to emphasize the fact that it’s not being used as a String.
> >>
> >> I was woefully unclear with that last email. IMO, `utf8CString` is
> >> fine, since a CString really is a null-terminated array of
> >> CChars. But `utf8String` implies that the property is a String,
> >> which `nulTerminatedUTF8` is not (it's a
> >> `ContiguousArray`).
> >>
> >> Saagar Jha
> >>
> >>
> >>
> >>> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution
> >>> >
> >>> wrote:
> >>>
> >>> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution
> >>> >
> >>> wrote:
> >>>
> >>> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution
> >>> > >
> >>> > wrote:
> >>> >
> >>> > Xiaodi Wu via swift-evolution  writes:
> >>> >
> >>> >
> >>> >> In `String`, the methods `nulTerminatedUTF8` and
> >>> >> nulTerminatedUTF8CString` have the word "null" misspelled
> >>> >
> >>> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
> >>>
> >>> One would hope so. A series of characters terminated by a zero byte.
> >>>
> >>>   /// A contiguously stored null-terminated UTF-8 representation of
> >>>   /// the string.
> >>>   ///
> >>>   /// This is a variation on nulTerminatedUTF8 that creates an array
> >>>   /// of element type CChar for use with CString API's.
> >>>
> >>> I think utf8String and utf8CString capture both meanings. I know
> they're
> >>> a little redundant but they get the meaning across, use CString term of
> >>> art, and are pithy compared to any alternatives (like
> "representation", etc)
> >>>
> >>> They're arrays though, not strings.
> >>>
> >>> -- E
> >>>
> >>>
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org 
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution <
> https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>>
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org 
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution <
> 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

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Saagar Jha  wrote:

> Ahh…I agree in that case; something like `utf8Array` might be a better
> choice.

  Array(s.utf8)

seems expressive enough to me, if what you really want is an array.  IMO
we should consider dropping other spellings.

> Saagar Jha
>
>> On Jul 24, 2016, at 16:44, Xiaodi Wu  wrote:
>> 
>> On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha > > wrote:
>> Well, yes, but hardly anyone calls it a “char array” unless they’re
>> trying to emphasize the fact that it’s not being used as a String.
>> 
>> I was woefully unclear with that last email. IMO, `utf8CString` is
>> fine, since a CString really is a null-terminated array of
>> CChars. But `utf8String` implies that the property is a String,
>> which `nulTerminatedUTF8` is not (it's a
>> `ContiguousArray`).
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution
>>> >
>>> wrote:
>>> 
>>> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution
>>> >
>>> wrote:
>>> 
>>> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution
>>> > >
>>> > wrote:
>>> >
>>> > Xiaodi Wu via swift-evolution  writes:
>>> >
>>> >
>>> >> In `String`, the methods `nulTerminatedUTF8` and
>>> >> nulTerminatedUTF8CString` have the word "null" misspelled
>>> >
>>> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>>> 
>>> One would hope so. A series of characters terminated by a zero byte.
>>> 
>>>   /// A contiguously stored null-terminated UTF-8 representation of
>>>   /// the string.
>>>   ///
>>>   /// This is a variation on nulTerminatedUTF8 that creates an array
>>>   /// of element type CChar for use with CString API's.
>>> 
>>> I think utf8String and utf8CString capture both meanings. I know they're
>>> a little redundant but they get the meaning across, use CString term of
>>> art, and are pithy compared to any alternatives (like "representation", etc)
>>>  
>>> They're arrays though, not strings.
>>> 
>>> -- E
>>> 
>>> 
>>> ___
>>> 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] Fix a typo in two String methods

[Saagar Jha via swift-evolution]

Ahh…I agree in that case; something like `utf8Array` might be a better choice.
Saagar Jha



> On Jul 24, 2016, at 16:44, Xiaodi Wu  wrote:
> 
> On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha  > wrote:
> Well, yes, but hardly anyone calls it a “char array” unless they’re trying to 
> emphasize the fact that it’s not being used as a String.
> 
> I was woefully unclear with that last email. IMO, `utf8CString` is fine, 
> since a CString really is a null-terminated array of CChars. But `utf8String` 
> implies that the property is a String, which `nulTerminatedUTF8` is not (it's 
> a `ContiguousArray`).
> 
> Saagar Jha
> 
> 
> 
>> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution 
>> > > wrote:
>> >
>> > Xiaodi Wu via swift-evolution  writes:
>> >
>> >
>> >> In `String`, the methods `nulTerminatedUTF8` and
>> >> nulTerminatedUTF8CString` have the word "null" misspelled
>> >
>> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>> 
>> One would hope so. A series of characters terminated by a zero byte.
>> 
>>   /// A contiguously stored null-terminated UTF-8 representation of
>>   /// the string.
>>   ///
>>   /// This is a variation on nulTerminatedUTF8 that creates an array
>>   /// of element type CChar for use with CString API's.
>> 
>> I think utf8String and utf8CString capture both meanings. I know they're
>> a little redundant but they get the meaning across, use CString term of
>> art, and are pithy compared to any alternatives (like "representation", etc)
>>  
>> They're arrays though, not strings.
>> 
>> -- E
>> 
>> 
>> ___
>> 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] Fix a typo in two String methods

[Xiaodi Wu via swift-evolution]

On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha  wrote:

> Well, yes, but hardly anyone calls it a “char array” unless they’re trying
> to emphasize the fact that it’s *not* being used as a String.
>

I was woefully unclear with that last email. IMO, `utf8CString` is fine,
since a CString really is a null-terminated array of CChars. But
`utf8String` implies that the property is a String, which
`nulTerminatedUTF8` is not (it's a `ContiguousArray`).

Saagar Jha
>
>
>
> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > Xiaodi Wu via swift-evolution  writes:
>> >
>> >
>> >> In `String`, the methods `nulTerminatedUTF8` and
>> >> nulTerminatedUTF8CString` have the word "null" misspelled
>> >
>> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>>
>> One would hope so. A series of characters terminated by a zero byte.
>>
>>   /// A contiguously stored null-terminated UTF-8 representation of
>>   /// the string.
>>   ///
>>   /// This is a variation on nulTerminatedUTF8 that creates an array
>>   /// of element type CChar for use with CString API's.
>>
>> I think utf8String and utf8CString capture both meanings. I know they're
>> a little redundant but they get the meaning across, use CString term of
>> art, and are pithy compared to any alternatives (like "representation",
>> etc)
>>
>
> They're arrays though, not strings.
>
> -- E
>>
>>
>> ___
>> 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] Fix a typo in two String methods

[Saagar Jha via swift-evolution]

Well, yes, but hardly anyone calls it a “char array” unless they’re trying to 
emphasize the fact that it’s not being used as a String.

Saagar Jha



> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution 
> > wrote:
> 
> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution 
> > > wrote:
> >
> > Xiaodi Wu via swift-evolution  writes:
> >
> >
> >> In `String`, the methods `nulTerminatedUTF8` and
> >> nulTerminatedUTF8CString` have the word "null" misspelled
> >
> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
> 
> One would hope so. A series of characters terminated by a zero byte.
> 
>   /// A contiguously stored null-terminated UTF-8 representation of
>   /// the string.
>   ///
>   /// This is a variation on nulTerminatedUTF8 that creates an array
>   /// of element type CChar for use with CString API's.
> 
> I think utf8String and utf8CString capture both meanings. I know they're
> a little redundant but they get the meaning across, use CString term of
> art, and are pithy compared to any alternatives (like "representation", etc)
>  
> They're arrays though, not strings.
> 
> -- E
> 
> 
> ___
> 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] Fix a typo in two String methods

[Xiaodi Wu via swift-evolution]

On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Xiaodi Wu via swift-evolution  writes:
> >
> >
> >> In `String`, the methods `nulTerminatedUTF8` and
> >> nulTerminatedUTF8CString` have the word "null" misspelled
> >
> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>
> One would hope so. A series of characters terminated by a zero byte.
>
>   /// A contiguously stored null-terminated UTF-8 representation of
>   /// the string.
>   ///
>   /// This is a variation on nulTerminatedUTF8 that creates an array
>   /// of element type CChar for use with CString API's.
>
> I think utf8String and utf8CString capture both meanings. I know they're
> a little redundant but they get the meaning across, use CString term of
> art, and are pithy compared to any alternatives (like "representation",
> etc)
>

They're arrays though, not strings.

-- E
>
>
> ___
> 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

[Nevin Brackett-Rozinsky via swift-evolution]

I think the hypothetical alternative would be `nullTerminatedCString` for
one and `nullTerminatedUTF8` for the other.

Nevin


On Sun, Jul 24, 2016 at 6:34 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Xiaodi Wu via swift-evolution  writes:
> >
> >
> >> In `String`, the methods `nulTerminatedUTF8` and
> >> nulTerminatedUTF8CString` have the word "null" misspelled
> >
> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>
> One would hope so. A series of characters terminated by a zero byte.
>
>   /// A contiguously stored null-terminated UTF-8 representation of
>   /// the string.
>   ///
>   /// This is a variation on nulTerminatedUTF8 that creates an array
>   /// of element type CChar for use with CString API's.
>
> I think utf8String and utf8CString capture both meanings. I know they're
> a little redundant but they get the meaning across, use CString term of
> art, and are pithy compared to any alternatives (like "representation",
> etc)
>
> -- E
>
>
> ___
> 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

[Erica Sadun via swift-evolution]

> On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Xiaodi Wu via swift-evolution  writes:
> 
> 
>> In `String`, the methods `nulTerminatedUTF8` and 
>> nulTerminatedUTF8CString` have the word "null" misspelled
> 
> Whoa. Isn't "Cstring" redundant with "null-terminated?"

One would hope so. A series of characters terminated by a zero byte.

  /// A contiguously stored null-terminated UTF-8 representation of
  /// the string.
  ///
  /// This is a variation on nulTerminatedUTF8 that creates an array
  /// of element type CChar for use with CString API's.

I think utf8String and utf8CString capture both meanings. I know they're
a little redundant but they get the meaning across, use CString term of
art, and are pithy compared to any alternatives (like "representation", etc)

-- E


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

Re: [swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Tim Vermeulen via swift-evolution]

Great! A +1 from me for that proposal then :)

> > On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via 
> > swift-evolutionwrote:
> > 
> > `firstIndex` is completely unambiguous, whereas with `index` people might 
> > wonder which index is returned. Also, if `lastIndex` methods ever get added 
> > to the standard library, they will be a lot more consistent with 
> > `firstIndex` than with `index`.
> > 
> > On the other hand, `index` is short and simple, and people might not care 
> > whether it is the first index that matches or a different one. Still I 
> > think `firstIndex` is more in line with the naming guidelines.
> > 
> > Thoughts?
> Working on it! 
> https://github.com/brentdax/swift-evolution/blob/09be1007c5138be2370f33d761b05b8b6700a9a3/proposals/-sequence-end-ops.md
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> 
> 
> 
___
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

[Dave Abrahams via swift-evolution]

Xiaodi Wu via swift-evolution  writes:


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

Whoa. Isn't "Cstring" redundant with "null-terminated?"

--
Dave

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

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Dave Abrahams via swift-evolution]

Jose Cheyo Jimenez via swift-evolution  writes:

> 
> Is your proposal going to make the swift3 window? 

It should.  I'm planning on merging it and launching the review 
if Chris L doesn't beat me to it (which I hope he will ;-)).

--
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-0128: Change failable UnicodeScalar initializers to failable

[Scott James Remnant via swift-evolution]

+1

Obvious improvement, and matches integer initializers.

Scott
___
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]

Asking whether zero appears in a sequence that happened to contain a NaN would 
equally be a precondition violation. I don't think that's an acceptable cliff. 
The point of NaNs and Infs is that they flow through a multidimensional 
calculation without disturbing the parts that are still valid, rather than, 
e.g., 
trapping. 

Sent from my moss-covered three-handled family gradunza

> On Jul 24, 2016, at 10:40 AM, Pyry Jahkola  wrote:
> 
> Pyry Jahkola wrote:
> 
>>> or even to ask whether
>>> someSequence.contains(.nan).  IMO that's not really acceptable.
>> 
>> Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the 
>> == operator which is part of the protocol and thus wouldn't call <=> on 
>> FloatingPoint types which override the default implementation.
> 
> Oops, spoke too soon. Well, I think it's easy enough to require people to 
> write numbers.contains(where: { $0.isNaN }) in this use case.
> 
> — Pyry
___
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

[Xiaodi Wu via swift-evolution]

Oops. Written in a hurry. I will fix all inaccuracies identified so far.
On Sun, Jul 24, 2016 at 14:50 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> ES++  for exactly the same reasons. I use postfix increment because I
> didn’t even think of the completion angle until Mark brought it up. The
> fingers type what the fingers type.
>
> I also support for the other many fine reasons previously mentioned in
> this thread: matches user expectations, the description is more commonly
> used in art than NUL, which remains obscure even if technically accurate.
> See also: https://en.wikipedia.org/wiki/Null-terminated_string. I want to
> contribute to the “broad community support for renaming”.
>
> That said, I’d prefer utf8String and utf8CString, but I suspect that’s a
> non-starter, and the initial pitch misidentifies the properties as methods.
>
> — E
>
>
> On Jul 24, 2016, at 11:39 AM, Mark Dalrymple via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1, mainly because if someone uses on-demand completion (like me) thinking
> it's called "nullTerminated", typing "null" will not complete if the method
> name is "nulTerminated"
>
> ++md
>
>
> ___
> 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

[Erica Sadun via swift-evolution]

ES++  for exactly the same reasons. I use postfix increment because I didn’t 
even think of the completion angle until Mark brought it up. The fingers type 
what the fingers type.

I also support for the other many fine reasons previously mentioned in this 
thread: matches user expectations, the description is more commonly used in art 
than NUL, which remains obscure even if technically accurate. See also: 
https://en.wikipedia.org/wiki/Null-terminated_string 
. I want to contribute to 
the “broad community support for renaming”.

That said, I’d prefer utf8String and utf8CString, but I suspect that’s a 
non-starter, and the initial pitch misidentifies the properties as methods.

— E


> On Jul 24, 2016, at 11:39 AM, Mark Dalrymple via swift-evolution 
>  wrote:
> 
> +1, mainly because if someone uses on-demand completion (like me) thinking 
> it's called "nullTerminated", typing "null" will not complete if the method 
> name is "nulTerminated"
> 
> ++md
> 

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

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

[Ben Rimmington via swift-evolution]

> On 22 Jul 2016, at 18:43, Dave Abrahams wrote:
> 
>> on Fri Jul 22 2016, Haravikk  wrote:
>> 
>> In my own hacked implementation I'm using Order.before, Order.same,
>> and Order.after. It's not much of a change, but it seems to clarify
>> what the enum is, at least in my opinion.
> 
> I always thought the name “Order” would be perfect if it weren't so
> short and likely to conflict with type names that user code will want.
> We do have qualification to fall back on, so this is a judgement call.

enum TotalOrder {
  case ascending
  case identical
  case descending
}

-- Ben

___
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]

Pyry Jahkola wrote:

>> or even to ask whether
>> someSequence.contains(.nan).  IMO that's not really acceptable.
> 
> Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the == 
> operator which is part of the protocol and thus wouldn't call <=> on 
> FloatingPoint types which override the default implementation.

Oops, spoke too soon. Well, I think it's easy enough to require people to write 
numbers.contains(where: { $0.isNaN }) in this use case.

— Pyry
___
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

[Mark Dalrymple via swift-evolution]

+1, mainly because if someone uses on-demand completion (like me) thinking
it's called "nullTerminated", typing "null" will not complete if the method
name is "nulTerminated"

++md


On Sun, Jul 24, 2016 at 12:22 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Fair enough.  I’m personally fine with “nullTerminatedUTF8” - I’m saying
> that “nullCharacterTerminatedUTF8” would be unhelpful.
>
> -Chris
>
> On Jul 24, 2016, at 12:00 AM, Félix Cloutier  wrote:
>
> So I can see in hindsight that perhaps people meant "NUL-terminated
> string" the whole time, but "NUL-terminated string" has 19,700 results on
> Google, whereas "null-terminated string" has 192,000.
>
> I have a funny anecdote to share. I got really upset on reddit one day
>  that someone said that some trojan was a "virus".
> That's not right! Trojans are not viruses! And then someone came along and
> asked, "what type of software would you use to remove a trojan?" And the
> answer to that, of course, is an anti-virus.
>
> I can come up with a number of other instances where people use
> technically incorrect names that are just so powerfully ingrained that it's
> not even worth it to fight back. Like JPEG vs JFIF.
>
> Point being, while I have lots of respect for standards, if what you want
> is consensus, siding with the 90% is a better idea.
>
> Félix
>
> Le 23 juil. 2016 à 15:21:48, Andrew Trick via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
> 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
>
> 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
>
>
___
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 Sun Jul 24 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.
>
> I don't think this is correct naming. It might be in case of structs,
> but in case of a pointer on the heap, I think this is misleading. It
> would be absolutely valid to write:
>
> let obj = NSObject()
> withUnsafePointer(toCopyOf: obj) { ptr in
>   print(ptr)
> }
>
> and it doesn't create any copy of anything. 

No, it actually does create a copy of the argument.  When you copy a
reference, that's a real thing, even though it doesn't copy the instance
the reference refers to.

> I'd personally prefer renaming the current behavior to
> withUnsafePointer(byReferenceTo:) which is more descriptive.

I don't see how that helps anything.

>> 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.
>
> I've updated the proposal and created a pull request.
>
>> 
>>> 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 

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

[Pyry Jahkola via swift-evolution]

Dave Abrahams 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:
> 
> This effectively makes it a precondition violation to default-sort
> a sequence of floats that contains a NaN

Correct. I'm still pondering if that could be alleviated in this model with 
minor modifications. Note however, that the proposed IEEE 754 total order would 
put negative NaNs at front and positive NaNs at the end. I can't say that's too 
useful either.

> or even to ask whether
> someSequence.contains(.nan).  IMO that's not really acceptable.

Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the == 
operator which is part of the protocol and thus wouldn't call <=> on 
FloatingPoint types which override the default implementation.

— Pyry

___
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 Sat Jul 23 2016, Xiaodi Wu  wrote:

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

Yes, and specifically division by zero, which *seriously doesn't concern
me*.  I view the reason for floating point's (1/0 == Inf) to be very
similar to its reason for having NaN, which I understand to be this:
practitioners want to do very large multivariate calculations where if
*some* of the results can't be computed, it doesn't scuttle all of them.
They also want to preserve as much information as possible about the
likely nature of results when precision limits come into play

When I read what mathematicians say about division by zero (e.g.
https://www.quora.com/Is-1-0-infinity/answer/Dan-Piponi and
https://www.quora.com/Is-1-0-infinity/answer/Michael-Lamar), it seems to
me that there is no well-defined answer, and we could view +Inf and -Inf
as the way floating point responds to a precondition violation.

I would *much* rather do a little handwaving in the area of division by
zero than in the areas of equivalence and ordering.

> 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 

Re: [swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Jose Cheyo Jimenez via swift-evolution]

Is your proposal going to make the swift3 window? 

On Jul 24, 2016, at 8:23 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via swift-evolution 
>>  wrote:
>> 
>> `firstIndex` is completely unambiguous, whereas with `index` people might 
>> wonder which index is returned. Also, if `lastIndex` methods ever get added 
>> to the standard library, they will be a lot more consistent with 
>> `firstIndex` than with `index`.
>> 
>> On the other hand, `index` is short and simple, and people might not care 
>> whether it is the first index that matches or a different one. Still I think 
>> `firstIndex` is more in line with the naming guidelines.
>> 
>> Thoughts?
> 
> Working on it! 
> https://github.com/brentdax/swift-evolution/blob/09be1007c5138be2370f33d761b05b8b6700a9a3/proposals/-sequence-end-ops.md
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

[Dave Abrahams via swift-evolution]

on Sat Jul 23 2016, 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:

This effectively makes it a precondition violation to default-sort
a sequence of floats that contains a NaN or even to ask whether
someSequence.contains(.nan).  IMO that's not really acceptable.

> 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, 

I agree that our default ordering and equivalence tests should not
consider these differences to be essential/salient.

> 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 

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

[Jose Cheyo Jimenez via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

> On Jul 24, 2016, at 2:21 AM, Boris Wang  wrote:
> 
> just write code in playground：
> struct MyStruct ｛
> var t = 0
> ｝
> sizeof(MyStruct)
> 
> Compiler error：
> Missing '.self' for reference to metatype of type 'MyStruct'
> 
> The metatype is from swift it self!
> 
> What the hell was the .self?
> 
> 
> Jose Cheyo Jimenez via swift-evolution 于2016年7月24日 
> 周日04:45写道：
>> 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 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]

Fair enough.  I’m personally fine with “nullTerminatedUTF8” - I’m saying that 
“nullCharacterTerminatedUTF8” would be unhelpful.

-Chris

> On Jul 24, 2016, at 12:00 AM, Félix Cloutier  wrote:
> 
> So I can see in hindsight that perhaps people meant "NUL-terminated string" 
> the whole time, but "NUL-terminated string" has 19,700 results on Google, 
> whereas "null-terminated string" has 192,000.
> 
> I have a funny anecdote to share. I got really upset on reddit one day 
>  that someone said that some trojan was a "virus". 
> That's not right! Trojans are not viruses! And then someone came along and 
> asked, "what type of software would you use to remove a trojan?" And the 
> answer to that, of course, is an anti-virus.
> 
> I can come up with a number of other instances where people use technically 
> incorrect names that are just so powerfully ingrained that it's not even 
> worth it to fight back. Like JPEG vs JFIF.
> 
> Point being, while I have lots of respect for standards, if what you want is 
> consensus, siding with the 90% is a better idea.
> 
> Félix
> 
>> Le 23 juil. 2016 à 15:21:48, Andrew Trick via swift-evolution 
>> > a écrit :
>> 
>>> 
>>> 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 
>> 

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

Re: [swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Brent Royal-Gordon via swift-evolution]

> On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via swift-evolution 
>  wrote:
> 
> `firstIndex` is completely unambiguous, whereas with `index` people might 
> wonder which index is returned. Also, if `lastIndex` methods ever get added 
> to the standard library, they will be a lot more consistent with `firstIndex` 
> than with `index`.
> 
> On the other hand, `index` is short and simple, and people might not care 
> whether it is the first index that matches or a different one. Still I think 
> `firstIndex` is more in line with the naming guidelines.
> 
> Thoughts?

Working on it! 
https://github.com/brentdax/swift-evolution/blob/09be1007c5138be2370f33d761b05b8b6700a9a3/proposals/-sequence-end-ops.md

-- 
Brent Royal-Gordon
Architechies

___
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]

>> 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.

I don't think this is correct naming. It might be in case of structs, but in 
case of a pointer on the heap, I think this is misleading. It would be 
absolutely valid to write:

let obj = NSObject()
withUnsafePointer(toCopyOf: obj) { ptr in
print(ptr)
}

and it doesn't create any copy of anything. I'd personally prefer renaming the 
current behavior to withUnsafePointer(byReferenceTo:) which is more descriptive.

> 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.

I've updated the proposal and created a pull request.

> 
>> 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 

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

[Charlie Monroe via swift-evolution]

> > 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).

Thanks for the patch. Nevertheless, see how ObjC prints an object:



Using the ObjectIdentifier to mimic this behavior (using current 
implementation), you get



Not everyone needs to be happy with this. Yes, you could really do this now:

let identifier = ObjectIdentifier(obj)
let ptr = (nil as UnsafePointer).advancedBy(Int(identifier.uintValue))

Since you can get the uintValue, which is in fact the numeric value of the 
pointer, I don't see the harm in exposing the pointer value as well, explicitly 
naming it "unsafeAddress".

> 
> 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] [Revision] [Pitch] Rename `T.Type`

[Boris Wang via swift-evolution]

Got it, thanks!
Anton Zhilin 于2016年7月24日 周日17:32写道：

> 2016-07-24 12:21 GMT+03:00 Boris Wang via swift-evolution <
> swift-evolution@swift.org>:
>
>> just write code in playground：
>> struct MyStruct ｛
>> var t = 0
>> ｝
>> sizeof(MyStruct)
>>
>> Compiler error：
>> Missing '.self' for reference to metatype of type 'MyStruct'
>>
>> The metatype is from swift it self!
>>
>> What the hell was the .self?
>>
>
> Boris, you should write `sizeof(MyStruct.self)` in your example. Removal
> of `.self` is deferred from Swift 3.
> SE lists are not the best place to learn about metatypes, but here is some
> explanation:
> https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Tim Vermeulen via swift-evolution]

`firstIndex` is completely unambiguous, whereas with `index` people might 
wonder which index is returned. Also, if `lastIndex` methods ever get added to 
the standard library, they will be a lot more consistent with `firstIndex` than 
with `index`.

On the other hand, `index` is short and simple, and people might not care 
whether it is the first index that matches or a different one. Still I think 
`firstIndex` is more in line with the naming guidelines.

Thoughts?
___
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]

2016-07-24 12:21 GMT+03:00 Boris Wang via swift-evolution <
swift-evolution@swift.org>:

> just write code in playground：
> struct MyStruct ｛
> var t = 0
> ｝
> sizeof(MyStruct)
>
> Compiler error：
> Missing '.self' for reference to metatype of type 'MyStruct'
>
> The metatype is from swift it self!
>
> What the hell was the .self?
>

Boris, you should write `sizeof(MyStruct.self)` in your example. Removal of
`.self` is deferred from Swift 3.
SE lists are not the best place to learn about metatypes, but here is some
explanation:
https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Boris Wang via swift-evolution]

just write code in playground：
struct MyStruct ｛
var t = 0
｝
sizeof(MyStruct)

Compiler error：
Missing '.self' for reference to metatype of type 'MyStruct'

The metatype is from swift it self!

What the hell was the .self?


Jose Cheyo Jimenez via swift-evolution 于2016年7月24日
周日04:45写道：

> 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 <
> swift-evolution@swift.org> 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 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

[Félix Cloutier via swift-evolution]

So I can see in hindsight that perhaps people meant "NUL-terminated string" the 
whole time, but "NUL-terminated string" has 19,700 results on Google, whereas 
"null-terminated string" has 192,000.

I have a funny anecdote to share. I got really upset on reddit one day 
 that someone said that some trojan was a "virus". 
That's not right! Trojans are not viruses! And then someone came along and 
asked, "what type of software would you use to remove a trojan?" And the answer 
to that, of course, is an anti-virus.

I can come up with a number of other instances where people use technically 
incorrect names that are just so powerfully ingrained that it's not even worth 
it to fight back. Like JPEG vs JFIF.

Point being, while I have lots of respect for standards, if what you want is 
consensus, siding with the 90% is a better idea.

Félix

> Le 23 juil. 2016 à 15:21:48, Andrew Trick via swift-evolution 
>  a écrit :
> 
>> 
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution