Re: [swift-users] the pain of strings

[Taylor Swift via swift-users]

I agree, and the new format of the swift 4 API docs are much harder to find
things in than the swift 3 ones. Perusing all the types and free functions
in alphabetical order is so much easier than trying to guess what “topic”
something is sorted under.

On Sat, Jul 1, 2017 at 12:54 AM, David Baraff  wrote:

>
> On Jun 30, 2017, at 9:48 PM, Taylor Swift via swift-users <
> swift-users@swift.org> wrote:
>
>
> Swift's strings were very deliberately designed this way. It's tougher to
>> get off the ground, sure, but it's better in the long run.
>>
>>
> It probably is, but the correct idiom is not very well known, and sadly
> most tutorials and unofficial guides are still teaching dumb ways of
> subscripting into strings (or worse, falling back into NSString methods
> without mentioning so) so the end result is people writing less performant
> code rather than more performant code.
>
>
> An efficient solution doesn’t help if even experienced programmers can’t
> easily arrive at it.  (I’m highly experienced, but I’ll admit I only put in
> about 5 minutes before I posted that.  on the other hand, it shouldn’t take
> 5 minutes to figure out something that simple with strings.  still, maybe i
> would have done the simple “suffix()” thing had i been looking at the
> actual swift 4 api’s, but i only had swift 3 api’s in front of me.)
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[David Baraff via swift-users]

> On Jun 30, 2017, at 9:48 PM, Taylor Swift via swift-users 
>  wrote:
> 
> 
> Swift's strings were very deliberately designed this way. It's tougher to get 
> off the ground, sure, but it's better in the long run.
> 
> 
> It probably is, but the correct idiom is not very well known, and sadly most 
> tutorials and unofficial guides are still teaching dumb ways of subscripting 
> into strings (or worse, falling back into NSString methods without mentioning 
> so) so the end result is people writing less performant code rather than more 
> performant code.

An efficient solution doesn’t help if even experienced programmers can’t easily 
arrive at it.  (I’m highly experienced, but I’ll admit I only put in about 5 
minutes before I posted that.  on the other hand, it shouldn’t take 5 minutes 
to figure out something that simple with strings.  still, maybe i would have 
done the simple “suffix()” thing had i been looking at the actual swift 4 
api’s, but i only had swift 3 api’s in front of me.)

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

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

Re: [swift-users] Class vs Structures

[Taylor Swift via swift-users]

An addendum: if something represents a specific “thing” that can’t be
duplicated without consequence, often that means it should be stored in one
specific place in your code, not made into a class.

On Fri, Jun 30, 2017 at 10:10 PM, Brent Royal-Gordon via swift-users <
swift-users@swift.org> wrote:

> On Jun 29, 2017, at 10:40 AM, Vitor Navarro via swift-users <
> swift-users@swift.org> wrote:
>
> Do you guys have any guideline regarding usage here?
>
>
> Here's my suggestion: Use a class when the object represents a specific
> *thing* that can't be duplicated without consequence; use a struct (or
> enum) when the instance represents some abstract data with no concrete
> existence. Some examples using framework types:
>
> * A piece of text is just some data; duplicating it doesn't do anything
> except maybe use more memory. So `String` should be a struct.
>
> * A label is a particular thing that exists at a particular place on
> screen; if you duplicated it, you'd end up with two labels on the screen,
> or with an off-screen copy of a label that wouldn't have any effect when
> you mutated it. So `UILabel` should be a class.
>
> * A URL is just some data; if you construct two URLs with the same
> contents, they are completely interchangeable. So `URL` should be a struct.
>
> * A connection to a web server to retrieve the contents of a URL is a
> particular thing; if you duplicated it, you would either establish another
> connection, or the two instances would interfere with each other (e.g.
> canceling one would cancel the other). So `URLSessionTask` and
> `NSURLConnection` are classes.
>
> Sometimes the same problem, approached in slightly different ways, would
> allow you to use either one. For instance, a database record is a
> particular *thing* and should probably be a class, but copy the values of
> the fields (perhaps omitting the ID) out of it and suddenly you have a
> plausible struct. As a *general* rule, it's usually better to use structs
> where possible because it's easier to reason about their behavior—mutations
> in one function don't suddenly pop up in a totally unrelated function—but
> sometimes a particular type works very easily as a class and very awkwardly
> as a struct. Ultimately, it's a judgement call.
>
> The other point I will make is this: "Protocol-oriented programming" is
> new and exciting and often very useful, but it's a tool, not a religion. If
> subclassing works well for your use case, then subclass away.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[Taylor Swift via swift-users]

> Swift's strings were very deliberately designed this way. It's tougher to
> get off the ground, sure, but it's better in the long run.
>
>
It probably is, but the correct idiom is not very well known, and sadly
most tutorials and unofficial guides are still teaching dumb ways of
subscripting into strings (or worse, falling back into NSString methods
without mentioning so) so the end result is people writing less performant
code rather than more performant code.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[Brent Royal-Gordon via swift-users]

> On Jun 30, 2017, at 2:44 PM, David Baraff via swift-users 
>  wrote:
> 
> Python:
>  shortID = longerDeviceID[-2:]# give me the last two 
> characters
> 
> Swift:
>  let shortID = 
> String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 
> 2))

This actually perfectly illustrates why Swift is designed the way it is.

The first thing to notice is that the Python version is terse, but it's 
actually impossible to know what it actually *does*. Is it operating on bytes, 
code units, Unicode scalars, or grapheme clusters? Well, that depends: is this 
Python 2 or Python 3? If it's 2, is this a `string` or a `unicode`? If it's 3, 
is it a `string` or a `bytes`? And if it is one of the Unicode-aware types, how 
are those indexed? (I honestly don't know—I can't find anything about that in 
the documentation.) And forget about understanding its performance 
characteristics—that's an implementation detail.

The second thing to notice is that your Swift solution is very inefficient. It 
counts all the characters in the string, subtracts two, then counts all but the 
last two characters in the string before returning the last two. That is, it 
unnecessarily walks over the entire string twice. If you read your expression 
closely, all of this behavior is plainly stated in the code.

What you actually want to do is count back two characters from the *end*, like 
so:

let shortID = 
String(longerDeviceID.characters[longerDeviceID.characters.index(longerDeviceID.characters.endIndex,
 offsetBy: -2) ..< longerDeviceID.characters.endIndex])

Or, in Swift 4:

let shortID = 
String(longerDeviceID[longerDeviceID.index(longerDeviceID.endIndex, offsetBy: 
-2)...])

Or, as Adrian Zubarev pointed out, you can use the very convenient `suffix(_:)` 
method, available on any `Sequence`:

let shortID = String(longerDeviceID.characters.suffix(2))   // 
Swift 3
let shortID = String(longerDeviceID.suffix(2))  
// Swift 4

Swift's strings were very deliberately designed this way. It's tougher to get 
off the ground, sure, but it's better in the long run.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-users] Class vs Structures

[Brent Royal-Gordon via swift-users]

> On Jun 29, 2017, at 10:40 AM, Vitor Navarro via swift-users 
>  wrote:
> 
> Do you guys have any guideline regarding usage here?


Here's my suggestion: Use a class when the object represents a specific *thing* 
that can't be duplicated without consequence; use a struct (or enum) when the 
instance represents some abstract data with no concrete existence. Some 
examples using framework types:

* A piece of text is just some data; duplicating it doesn't do anything except 
maybe use more memory. So `String` should be a struct.

* A label is a particular thing that exists at a particular place on screen; if 
you duplicated it, you'd end up with two labels on the screen, or with an 
off-screen copy of a label that wouldn't have any effect when you mutated it. 
So `UILabel` should be a class.

* A URL is just some data; if you construct two URLs with the same contents, 
they are completely interchangeable. So `URL` should be a struct.

* A connection to a web server to retrieve the contents of a URL is a 
particular thing; if you duplicated it, you would either establish another 
connection, or the two instances would interfere with each other (e.g. 
canceling one would cancel the other). So `URLSessionTask` and 
`NSURLConnection` are classes.

Sometimes the same problem, approached in slightly different ways, would allow 
you to use either one. For instance, a database record is a particular *thing* 
and should probably be a class, but copy the values of the fields (perhaps 
omitting the ID) out of it and suddenly you have a plausible struct. As a 
*general* rule, it's usually better to use structs where possible because it's 
easier to reason about their behavior—mutations in one function don't suddenly 
pop up in a totally unrelated function—but sometimes a particular type works 
very easily as a class and very awkwardly as a struct. Ultimately, it's a 
judgement call.

The other point I will make is this: "Protocol-oriented programming" is new and 
exciting and often very useful, but it's a tool, not a religion. If subclassing 
works well for your use case, then subclass away.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-users] the pain of strings

[Charles Srstka via swift-users]

> On Jun 30, 2017, at 4:44 PM, David Baraff via swift-users 
>  wrote:
> 
> I know, I’ve read tons about about this.  I sympathize.  Unicode, it’s all 
> very complex.
> 
> But.
> 
>  BUT.
> 
> Python:
>  shortID = longerDeviceID[-2:]# give me the last two 
> characters
> 
> Swift:
>  let shortID = 
> String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 
> 2))
> 
> I can’t even read the above without my eyes glazing over.  As has been 
> pointed out, an API which demands this much verbosity is crippling for many 
> developers, to say the least.
> 
> With Swift 4, am I correct that it will be at least:
> 
>  let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))

Hey, look on the bright side. They could have done what they’ve done with Data; 
make it *look* like simple integer subscripts will work, when actually they 
will blow up in your face at runtime.

func parseSome(data: Data) {
let magic = data[0..<4]
}

That’ll read the first four bytes of ‘data’ into ‘magic’, right? Well, not if 
someone does this when calling the function:

func parseSome(data: inputData[someStart..___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[David Baraff via swift-users]

> On Jun 30, 2017, at 6:06 PM, Kyle Murray  wrote:
> 
> Hi David,
> 
> You can see the new APIs for Swift 4's String here: 
> https://developer.apple.com/documentation/swift/string?changes=latest_minor 
> wow,
>  that’s awesome — i never knew you could get a diff view.  good stuff!!

I’ve written the more common new swift 4 functions i need as extensions in my 
project so i can write swift 4 syntax while waiting for xcode 9 to become 
stable/safe enough for use.

Thanks, this was all super-helpful for me.  Looking forward to the Substring 
API, quite a bit.

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

Re: [swift-users] the pain of strings

[Adrian Zubarev via swift-users]

Plus if you want to play with Swift 4 without running a toolchain or the new 
Xcode you can do it in your browser:

https://swift.sandbox.bluemix.net/#/repl

Just change that repl to Swift 4.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 03:02:38, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

The best docs you can get without Xcode I know about is this one here: 

https://developer.apple.com/documentation/swift/string

In Swift 4 a String will yet again become a collection type.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 02:57:05, David Baraff (davidbar...@gmail.com) schrieb:

I only know a little bit of what I’ve read online in blog posts and such.  I 
don’t have access to the Swift 4 API documentation, since i’m not running the 
xcode beta yet.

Is there someplace I can see the actual new API’s for String, in swift 4?  i 
googled but haven’t found it yet.


On Jun 30, 2017, at 5:44 PM, Adrian Zubarev  
wrote:

Well you’ve mentioned Swift 4 in your original post, therefore I provided a 
solution using Swift 4. It’s returning a view called `Substring`.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:38:42, David Baraff (davidbar...@gmail.com) schrieb:

I’m sorry, but I don’t see suffix() as a member function in any documentation, 
nor does it complete in Xcode.
Is this perhaps only in Swift 4?

If so, that’s a definite improvement!


Begin forwarded message:

From: Adrian Zubarev 
Subject: Re: [swift-users] the pain of strings
Date: June 30, 2017 at 3:13:42 PM PDT
To: David Baraff 
Cc: swift-users@swift.org

This looks way better than the subscript in Python and 1000 times better than 
your example. It might be a good idea to look up possible API first before 
writing such ugly long lines. I mean they get the job done, but just why so 
complicated? :(





-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:08:47, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

let longString = "1234567890"
print(longString.suffix(2)) // prints "90"


-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
(swift-users@swift.org) schrieb:

I know, I’ve read tons about about this. I sympathize. Unicode, it’s all very 
complex.

But.

BUT.

Python:
shortID = longerDeviceID[-2:] # give me the last two characters

Swift:
let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over. As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

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

Re: [swift-users] the pain of strings

[Kyle Murray via swift-users]

Hi David,

You can see the new APIs for Swift 4's String here: 
https://developer.apple.com/documentation/swift/string?changes=latest_minor 


The page indicates changes and additions since Xcode 8.3's Swift 3.1, 
corresponding with the version of Swift 4 that's in Xcode 9 beta 2.

Hope this helps,
Kyle

> On Jun 30, 2017, at 5:57 PM, David Baraff via swift-users 
>  wrote:
> 
> I only know a little bit of what I’ve read online in blog posts and such.  I 
> don’t have access to the Swift 4 API documentation, since i’m not running the 
> xcode beta yet.
> 
> Is there someplace I can see the actual new API’s for String, in swift 4?  i 
> googled but haven’t found it yet.
> 
> 
>> On Jun 30, 2017, at 5:44 PM, Adrian Zubarev > > wrote:
>> 
>> Well you’ve mentioned Swift 4 in your original post, therefore I provided a 
>> solution using Swift 4. It’s returning a view called `Substring`.
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 1. Juli 2017 um 00:38:42, David Baraff (davidbar...@gmail.com 
>> ) schrieb:
>> 
>>> I’m sorry, but I don’t see suffix() as a member function in any 
>>> documentation, nor does it complete in Xcode.
>>> Is this perhaps only in Swift 4?
>>> 
>>> If so, that’s a definite improvement!
>>> 
>>> 
>>> Begin forwarded message:
>>> 
 From: Adrian Zubarev >>> >
 Subject: Re: [swift-users] the pain of strings
 Date: June 30, 2017 at 3:13:42 PM PDT
 To: David Baraff mailto:davidbar...@gmail.com>>
 Cc: swift-users@swift.org 
 
 This looks way better than the subscript in Python and 1000 times better 
 than your example. It might be a good idea to look up possible API first 
 before writing such ugly long lines. I mean they get the job done, but 
 just why so complicated? :(
 
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 1. Juli 2017 um 00:08:47, Adrian Zubarev 
 (adrian.zuba...@devandartist.com ) 
 schrieb:
 
> let longString = "1234567890"
> print(longString.suffix(2)) // prints "90"
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
> (swift-users@swift.org ) schrieb:
> 
>> I know, I’ve read tons about about this. I sympathize. Unicode, it’s all 
>> very complex.
>> 
>> But.
>> 
>> BUT.
>> 
>> Python:
>> shortID = longerDeviceID[-2:] # give me the last two characters
>> 
>> Swift:
>> let shortID = 
>> String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count
>>  - 2))
>> 
>> I can’t even read the above without my eyes glazing over. As has been 
>> pointed out, an API which demands this much verbosity is crippling for 
>> many developers, to say the least.
>> 
>> With Swift 4, am I correct that it will be at least:
>> 
>> let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] the pain of strings

[David Baraff via swift-users]

I only know a little bit of what I’ve read online in blog posts and such.  I 
don’t have access to the Swift 4 API documentation, since i’m not running the 
xcode beta yet.

Is there someplace I can see the actual new API’s for String, in swift 4?  i 
googled but haven’t found it yet.


> On Jun 30, 2017, at 5:44 PM, Adrian Zubarev  
> wrote:
> 
> Well you’ve mentioned Swift 4 in your original post, therefore I provided a 
> solution using Swift 4. It’s returning a view called `Substring`.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 1. Juli 2017 um 00:38:42, David Baraff (davidbar...@gmail.com 
> ) schrieb:
> 
>> I’m sorry, but I don’t see suffix() as a member function in any 
>> documentation, nor does it complete in Xcode.
>> Is this perhaps only in Swift 4?
>> 
>> If so, that’s a definite improvement!
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Adrian Zubarev >> >
>>> Subject: Re: [swift-users] the pain of strings
>>> Date: June 30, 2017 at 3:13:42 PM PDT
>>> To: David Baraff mailto:davidbar...@gmail.com>>
>>> Cc: swift-users@swift.org 
>>> 
>>> This looks way better than the subscript in Python and 1000 times better 
>>> than your example. It might be a good idea to look up possible API first 
>>> before writing such ugly long lines. I mean they get the job done, but just 
>>> why so complicated? :(
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 1. Juli 2017 um 00:08:47, Adrian Zubarev 
>>> (adrian.zuba...@devandartist.com ) 
>>> schrieb:
>>> 
 let longString = "1234567890"
 print(longString.suffix(2)) // prints "90"
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
 (swift-users@swift.org ) schrieb:
 
> I know, I’ve read tons about about this. I sympathize. Unicode, it’s all 
> very complex.
> 
> But.
> 
> BUT.
> 
> Python:
> shortID = longerDeviceID[-2:] # give me the last two characters
> 
> Swift:
> let shortID = 
> String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count
>  - 2))
> 
> I can’t even read the above without my eyes glazing over. As has been 
> pointed out, an API which demands this much verbosity is crippling for 
> many developers, to say the least.
> 
> With Swift 4, am I correct that it will be at least:
> 
> let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[Adrian Zubarev via swift-users]

The best docs you can get without Xcode I know about is this one here: 

https://developer.apple.com/documentation/swift/string

In Swift 4 a String will yet again become a collection type.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 02:57:05, David Baraff (davidbar...@gmail.com) schrieb:

I only know a little bit of what I’ve read online in blog posts and such.  I 
don’t have access to the Swift 4 API documentation, since i’m not running the 
xcode beta yet.

Is there someplace I can see the actual new API’s for String, in swift 4?  i 
googled but haven’t found it yet.


On Jun 30, 2017, at 5:44 PM, Adrian Zubarev  
wrote:

Well you’ve mentioned Swift 4 in your original post, therefore I provided a 
solution using Swift 4. It’s returning a view called `Substring`.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:38:42, David Baraff (davidbar...@gmail.com) schrieb:

I’m sorry, but I don’t see suffix() as a member function in any documentation, 
nor does it complete in Xcode.
Is this perhaps only in Swift 4?

If so, that’s a definite improvement!


Begin forwarded message:

From: Adrian Zubarev 
Subject: Re: [swift-users] the pain of strings
Date: June 30, 2017 at 3:13:42 PM PDT
To: David Baraff 
Cc: swift-users@swift.org

This looks way better than the subscript in Python and 1000 times better than 
your example. It might be a good idea to look up possible API first before 
writing such ugly long lines. I mean they get the job done, but just why so 
complicated? :(





-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:08:47, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

let longString = "1234567890"
print(longString.suffix(2)) // prints "90"


-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
(swift-users@swift.org) schrieb:

I know, I’ve read tons about about this. I sympathize. Unicode, it’s all very 
complex.

But.

BUT.

Python:
shortID = longerDeviceID[-2:] # give me the last two characters

Swift:
let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over. As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

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

Re: [swift-users] the pain of strings

[Adrian Zubarev via swift-users]

Well you’ve mentioned Swift 4 in your original post, therefore I provided a 
solution using Swift 4. It’s returning a view called `Substring`.

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:38:42, David Baraff (davidbar...@gmail.com) schrieb:

I’m sorry, but I don’t see suffix() as a member function in any documentation, 
nor does it complete in Xcode.
Is this perhaps only in Swift 4?

If so, that’s a definite improvement!


Begin forwarded message:

From: Adrian Zubarev 
Subject: Re: [swift-users] the pain of strings
Date: June 30, 2017 at 3:13:42 PM PDT
To: David Baraff 
Cc: swift-users@swift.org

This looks way better than the subscript in Python and 1000 times better than 
your example. It might be a good idea to look up possible API first before 
writing such ugly long lines. I mean they get the job done, but just why so 
complicated? :(




-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:08:47, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

let longString = "1234567890"
print(longString.suffix(2)) // prints "90"


-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
(swift-users@swift.org) schrieb:

I know, I’ve read tons about about this. I sympathize. Unicode, it’s all very 
complex.

But.

BUT.

Python:
shortID = longerDeviceID[-2:] # give me the last two characters

Swift:
let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over. As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

Re: [swift-users] Class vs Structures

[Maury Markowitz via swift-users]

> On Jun 29, 2017, at 2:42 PM, Taylor Swift via swift-users 
>  wrote:
> 
> When in doubt, go with a struct. Probably nineteen types out of twenty I 
> write are structs.

The the 20th is likely when you're using one of Obj-C's features, like KVO.


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

Re: [swift-users] the pain of strings

[David Baraff via swift-users]

I’m sorry, but I don’t see suffix() as a member function in any documentation, 
nor does it complete in Xcode.
Is this perhaps only in Swift 4?

If so, that’s a definite improvement!


Begin forwarded message:

> From: Adrian Zubarev 
> Subject: Re: [swift-users] the pain of strings
> Date: June 30, 2017 at 3:13:42 PM PDT
> To: David Baraff 
> Cc: swift-users@swift.org
> 
> This looks way better than the subscript in Python and 1000 times better than 
> your example. It might be a good idea to look up possible API first before 
> writing such ugly long lines. I mean they get the job done, but just why so 
> complicated? :(
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 1. Juli 2017 um 00:08:47, Adrian Zubarev (adrian.zuba...@devandartist.com 
> ) schrieb:
> 
>> let longString = "1234567890"
>> print(longString.suffix(2)) // prints "90"
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
>> (swift-users@swift.org ) schrieb:
>> 
>>> I know, I’ve read tons about about this. I sympathize. Unicode, it’s all 
>>> very complex.
>>> 
>>> But.
>>> 
>>> BUT.
>>> 
>>> Python:
>>> shortID = longerDeviceID[-2:] # give me the last two characters
>>> 
>>> Swift:
>>> let shortID = 
>>> String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count 
>>> - 2))
>>> 
>>> I can’t even read the above without my eyes glazing over. As has been 
>>> pointed out, an API which demands this much verbosity is crippling for many 
>>> developers, to say the least.
>>> 
>>> With Swift 4, am I correct that it will be at least:
>>> 
>>> let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))
>>> 
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[Adrian Zubarev via swift-users]

This looks way better than the subscript in Python and 1000 times better than 
your example. It might be a good idea to look up possible API first before 
writing such ugly long lines. I mean they get the job done, but just why so 
complicated? :(



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 00:08:47, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

let longString = "1234567890"
print(longString.suffix(2)) // prints "90"


-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
(swift-users@swift.org) schrieb:

I know, I’ve read tons about about this. I sympathize. Unicode, it’s all very 
complex.

But.

BUT.

Python:
shortID = longerDeviceID[-2:] # give me the last two characters

Swift:
let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over. As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

Re: [swift-users] the pain of strings

[Adrian Zubarev via swift-users]

let longString = "1234567890"
print(longString.suffix(2)) // prints "90"


-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 23:45:01, David Baraff via swift-users 
(swift-users@swift.org) schrieb:

I know, I’ve read tons about about this. I sympathize. Unicode, it’s all very 
complex.

But.

BUT.

Python:
shortID = longerDeviceID[-2:]   # give me the last two characters

Swift:
let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over. As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

[swift-users] the pain of strings

[David Baraff via swift-users]

I know, I’ve read tons about about this.  I sympathize.  Unicode, it’s all very 
complex.

But.

  BUT.

Python:
  shortID = longerDeviceID[-2:] # give me the last two characters

Swift:
  let shortID = 
String(longerDeviceID.characters.dropFirst(longerDeviceID.characters.count - 2))

I can’t even read the above without my eyes glazing over.  As has been pointed 
out, an API which demands this much verbosity is crippling for many developers, 
to say the least.

With Swift 4, am I correct that it will be at least:

  let shortID = String(longerDeviceID.dropFirst(longerDeviceID.count - 2))



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

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Taylor Swift via swift-users]

You should probably use `withExtendedLifetime(_:_:)
`
for this.

On Fri, Jun 30, 2017 at 2:54 PM, Charles Srstka via swift-users <
swift-users@swift.org> wrote:

> > On Jun 30, 2017, at 1:47 PM, Mike Ferenduros via swift-users <
> swift-users@swift.org> wrote:
> >
> > I'm doing a RAII sort of thing with an object, and would like to keep it
> alive until an completion-block is called (asynchronously).
> >
> > Is it sufficient to say '_ = x' in the completion-block to keep a live
> reference to the object?
> >
> > I was told that the optimiser is free to discard this line, and thus the
> object could be freed prematurely depending on how the code is compiled. If
> so, is there an idiomatic way to do this? Or should I just avoid RAII in
> Swift?
>
> Nope. In fact, if you try this, you’ll find that it dies immediately after
> the initializer returns:
>
> class C {
> deinit { print("Deinit!") }
> }
>
> do {
> print("Creating")
> _ = C()
> print("Created")
> }
> print("Left the block”)
>
> - - - - -
>
> Creating
> Deinit!
> Created
> Left the block
>
> Charles
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Mike Ferenduros via swift-users]

Awesome, thanks :)

> On 30 Jun 2017, at 22:27, Joe Groff  wrote:
> 
> 
>> On Jun 30, 2017, at 12:25 PM, Mike Ferenduros  
>> wrote:
>> 
>> Ah, I think I was unclear - I want to extend the lifetime into an escaping 
>> closure, not just within a scope, and I was wondering what the minimal way 
>> is to do that.
> 
> I see. Using `withExtendedLifetime` inside the closure still ought to 
> guarantee that the closure captures the variable, and will have the effect of 
> keeping it alive till the closure dies.
> 
> -Joe
> 
>>> On 30 Jun 2017, at 22:15, Joe Groff  wrote:
>>> 
>>> 
 On Jun 30, 2017, at 12:13 PM, Mike Ferenduros  
 wrote:
 
 With an empty body, you mean?
>>> 
>>> I'd say it's probably more readable to nest the code that's dependent on 
>>> the lifetime of the object in the block body, though you can just put 
>>> `withExtendedLifetime(x) { }` at the end of the region (or `defer { 
>>> withExtendedLifetime... }` at the beginning) if you can't have the nesting 
>>> for whatever reason.
>>> 
>>> -Joe
>>> 
> On 30 Jun 2017, at 22:00, Joe Groff  wrote:
> 
> 
>> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
>>  wrote:
>> 
>> I'm doing a RAII sort of thing with an object, and would like to keep it 
>> alive until an completion-block is called (asynchronously).
>> 
>> Is it sufficient to say '_ = x' in the completion-block to keep a live 
>> reference to the object?
>> 
>> I was told that the optimiser is free to discard this line, and thus the 
>> object could be freed prematurely depending on how the code is compiled. 
>> If so, is there an idiomatic way to do this? Or should I just avoid RAII 
>> in Swift?
> 
> `withExtendedLifetime(x) { ... }` is the supported way of extending the 
> lifetime of an object.
> 
> -Joe
>>> 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Joe Groff via swift-users]

> On Jun 30, 2017, at 12:25 PM, Mike Ferenduros  
> wrote:
> 
> Ah, I think I was unclear - I want to extend the lifetime into an escaping 
> closure, not just within a scope, and I was wondering what the minimal way is 
> to do that.

I see. Using `withExtendedLifetime` inside the closure still ought to guarantee 
that the closure captures the variable, and will have the effect of keeping it 
alive till the closure dies.

-Joe

>> On 30 Jun 2017, at 22:15, Joe Groff  wrote:
>> 
>> 
>>> On Jun 30, 2017, at 12:13 PM, Mike Ferenduros  
>>> wrote:
>>> 
>>> With an empty body, you mean?
>> 
>> I'd say it's probably more readable to nest the code that's dependent on the 
>> lifetime of the object in the block body, though you can just put 
>> `withExtendedLifetime(x) { }` at the end of the region (or `defer { 
>> withExtendedLifetime... }` at the beginning) if you can't have the nesting 
>> for whatever reason.
>> 
>> -Joe
>> 
 On 30 Jun 2017, at 22:00, Joe Groff  wrote:
 
 
> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
>  wrote:
> 
> I'm doing a RAII sort of thing with an object, and would like to keep it 
> alive until an completion-block is called (asynchronously).
> 
> Is it sufficient to say '_ = x' in the completion-block to keep a live 
> reference to the object?
> 
> I was told that the optimiser is free to discard this line, and thus the 
> object could be freed prematurely depending on how the code is compiled. 
> If so, is there an idiomatic way to do this? Or should I just avoid RAII 
> in Swift?
 
 `withExtendedLifetime(x) { ... }` is the supported way of extending the 
 lifetime of an object.
 
 -Joe
>> 

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

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Mike Ferenduros via swift-users]

Ah, I think I was unclear - I want to extend the lifetime into an escaping 
closure, not just within a scope, and I was wondering what the minimal way is 
to do that.

> On 30 Jun 2017, at 22:15, Joe Groff  wrote:
> 
> 
>> On Jun 30, 2017, at 12:13 PM, Mike Ferenduros  
>> wrote:
>> 
>> With an empty body, you mean?
> 
> I'd say it's probably more readable to nest the code that's dependent on the 
> lifetime of the object in the block body, though you can just put 
> `withExtendedLifetime(x) { }` at the end of the region (or `defer { 
> withExtendedLifetime... }` at the beginning) if you can't have the nesting 
> for whatever reason.
> 
> -Joe
> 
>>> On 30 Jun 2017, at 22:00, Joe Groff  wrote:
>>> 
>>> 
 On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
  wrote:
 
 I'm doing a RAII sort of thing with an object, and would like to keep it 
 alive until an completion-block is called (asynchronously).
 
 Is it sufficient to say '_ = x' in the completion-block to keep a live 
 reference to the object?
 
 I was told that the optimiser is free to discard this line, and thus the 
 object could be freed prematurely depending on how the code is compiled. 
 If so, is there an idiomatic way to do this? Or should I just avoid RAII 
 in Swift?
>>> 
>>> `withExtendedLifetime(x) { ... }` is the supported way of extending the 
>>> lifetime of an object.
>>> 
>>> -Joe
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Joe Groff via swift-users]

> On Jun 30, 2017, at 12:13 PM, Mike Ferenduros  
> wrote:
> 
> With an empty body, you mean?

I'd say it's probably more readable to nest the code that's dependent on the 
lifetime of the object in the block body, though you can just put 
`withExtendedLifetime(x) { }` at the end of the region (or `defer { 
withExtendedLifetime... }` at the beginning) if you can't have the nesting for 
whatever reason.

-Joe

>> On 30 Jun 2017, at 22:00, Joe Groff  wrote:
>> 
>> 
>>> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
>>>  wrote:
>>> 
>>> I'm doing a RAII sort of thing with an object, and would like to keep it 
>>> alive until an completion-block is called (asynchronously).
>>> 
>>> Is it sufficient to say '_ = x' in the completion-block to keep a live 
>>> reference to the object?
>>> 
>>> I was told that the optimiser is free to discard this line, and thus the 
>>> object could be freed prematurely depending on how the code is compiled. If 
>>> so, is there an idiomatic way to do this? Or should I just avoid RAII in 
>>> Swift?
>> 
>> `withExtendedLifetime(x) { ... }` is the supported way of extending the 
>> lifetime of an object.
>> 
>> -Joe

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

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Joe Groff via swift-users]

> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
>  wrote:
> 
> I'm doing a RAII sort of thing with an object, and would like to keep it 
> alive until an completion-block is called (asynchronously).
> 
> Is it sufficient to say '_ = x' in the completion-block to keep a live 
> reference to the object?
> 
> I was told that the optimiser is free to discard this line, and thus the 
> object could be freed prematurely depending on how the code is compiled. If 
> so, is there an idiomatic way to do this? Or should I just avoid RAII in 
> Swift?

`withExtendedLifetime(x) { ... }` is the supported way of extending the 
lifetime of an object.

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

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Mike Ferenduros via swift-users]

With an empty body, you mean?

> On 30 Jun 2017, at 22:00, Joe Groff  wrote:
> 
> 
>> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users 
>>  wrote:
>> 
>> I'm doing a RAII sort of thing with an object, and would like to keep it 
>> alive until an completion-block is called (asynchronously).
>> 
>> Is it sufficient to say '_ = x' in the completion-block to keep a live 
>> reference to the object?
>> 
>> I was told that the optimiser is free to discard this line, and thus the 
>> object could be freed prematurely depending on how the code is compiled. If 
>> so, is there an idiomatic way to do this? Or should I just avoid RAII in 
>> Swift?
> 
> `withExtendedLifetime(x) { ... }` is the supported way of extending the 
> lifetime of an object.
> 
> -Joe
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Charles Srstka via swift-users]

> On Jun 30, 2017, at 1:47 PM, Mike Ferenduros via swift-users 
>  wrote:
> 
> I'm doing a RAII sort of thing with an object, and would like to keep it 
> alive until an completion-block is called (asynchronously).
> 
> Is it sufficient to say '_ = x' in the completion-block to keep a live 
> reference to the object?
> 
> I was told that the optimiser is free to discard this line, and thus the 
> object could be freed prematurely depending on how the code is compiled. If 
> so, is there an idiomatic way to do this? Or should I just avoid RAII in 
> Swift?

Nope. In fact, if you try this, you’ll find that it dies immediately after the 
initializer returns:

class C {
deinit { print("Deinit!") }
}

do {
print("Creating")
_ = C()
print("Created")
}
print("Left the block”)

- - - - -

Creating
Deinit!
Created
Left the block

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

[swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Mike Ferenduros via swift-users]

I'm doing a RAII sort of thing with an object, and would like to keep it
alive until an completion-block is called (asynchronously).

Is it sufficient to say '_ = x' in the completion-block to keep a live
reference to the object?

I was told that the optimiser is free to discard this line, and thus the
object could be freed prematurely depending on how the code is compiled. If
so, is there an idiomatic way to do this? Or should I just avoid RAII in
Swift?

Thanks!
Mike Ferenduros
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Passing Data to a f(void *) function

[Taylor Swift via swift-users]

I believe UnsafeRawPointer is a subtype of any UnsafePointer type, so
UnsafePointer’s are always implicitly convertible to UnsafeRawPointers.
So even the following compiles:


import Foundation

func f(_ a:UnsafeRawPointer)
{

}

let data = Data(bytes: [1, 2, 3, 4])
data.withUnsafeBytes{ (ptr:UnsafePointer>) in f(ptr) }

So annotate ptr with its actual type, and it should just work.

On Fri, Jun 30, 2017 at 10:57 AM, Daniel Dunbar via swift-users <
swift-users@swift.org> wrote:

>
> > On Jun 30, 2017, at 7:40 AM, Martin R via swift-users <
> swift-users@swift.org> wrote:
> >
> > I have a C function
> >
> >void myfunc(const void *ptr);
> >
> > which is imported to Swift as
> >
> >func myfunc(_ ptr: UnsafeRawPointer!)
> >
> > This compiles and runs without problems:
> >
> >let data = Data(bytes: [1, 2, 3, 4])
> >data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)
> >
> > and the type of `ptr` is inferred as `UnsafePointer`. But adding
> an explicit type
> > annotation produces a compiler warning:
>
> How do you know the inferred type is `UnsafePointer`? I think it is
> more likely it is `UnsafePointer`, and the following compiles:
> ```
> let data = Data(bytes: [1, 2, 3, 4])
> data.withUnsafeBytes { (ptr: UnsafePointer) in
> myfunc(ptr)
> }
> ```
>
>  - Daniel
>
> >
> >data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } //
> (B)
> >// warning: UnsafePointer has been replaced by UnsafeRawPointer
> >
> > which is understandable in the view of "SE-0107 UnsafeRawPointer API".
> >
> > The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and
> that does not
> > compile anymore:
> >
> >data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
> >// error: cannot convert value of type 'Void' to closure result type
> '_'
> >
> > because there is no `withUnsafeBytes()` method taking a
> `(UnsafeRawPointer)->ResultType`
> > closure.
> >
> >
> > My questions are:
> >
> > 1. Why are (A) and (B) treated differently?
> >
> > 2. Is (A) "legal", or should one use some non-void pointer
> >
> >data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } //
> (D)
> >
> >   (which feels wrong to me because it is converted back to a void
> pointer when
> >   calling the function).
> >
> > 3. Or should there be a `withUnsafeRawPointer()` method which makes (C)
> compile as
> >
> >  data.withUnsafeRawBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) }
> >
> >   This would also allow to access the data at byte offsets more easily,
> e.g.
> >
> >   data.withUnsafeRawBytes { ptr in
> >   let u16 = ptr.load(fromByteOffset: 4, as: UInt16.self)
> >   }
> >
> >   Does that makes sense?
> >
> > Regards, Martin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift alternative for heterogeneous collection of objects with "generic" contents.

[Joe Groff via swift-users]

> On Jun 29, 2017, at 10:59 PM, Mikhail Seriukov via swift-users 
>  wrote:
> 
> Hello everyone,
> In objc there is quite common pattern when we use a base class with a type 
> property and concrete subclasses where type is uniquely identifying the 
> subclass.
> We can then safely put subclasses objects into an array and then safely 
> downcast them when needed. 
> This kind of behaviour is commonly used in data sources implementations.
> 
> Like this:
> 
> typedef NS_ENUM(NSUInteger, CellDecriptorType) {
> CellDecriptorTypeUnknown,
> CellDecriptorType1,
> CellDecriptorType2
> };
> 
> @interface BaseCellDescriptor : NSObject
> 
> @property (nonatomic, readonly) CellDecriptorType type;
> @property (nonatomic, strong) id value;
> 
> @end
> 
> 
> @interface CellDescriptor1 : BaseCellDescriptor
> @end
> 
> @implementation CellDescriptor1
> 
> - (CellDecriptorType)type {
> return CellDecriptorType1;
> }
> 
> - (NSString *)value {
>   return @"string value";
> }
> 
> @end
> 
> 
> @interface CellDescriptor2 : BaseCellDescriptor
> @end
> 
> @implementation CellDescriptor2
> 
> - (CellDecriptorType)type {
> return CellDecriptorType2;
> }
> 
> - (NSNumber *)value {
>   return @42;
> }
> 
> @end
> 
> And somewhere later we do:
> 
> - (void)doWorkWithCellDescriptors:(NSArray 
> *)descriptors {
> for (BaseCellDescriptor *descriptor in descriptors) {
> CellDecriptorType type = descriptor.type;
> switch(type) {
> case CellDecriptorType1: {
> CellDescriptor1 *aDescriptor = (CellDescriptor1 *)descriptor;
> NSString *value = aDescriptor.value;
> // Do something with value
> break;
> }
> case CellDecriptorType2: {
> CellDescriptor2 *aDescriptor = (CellDescriptor2 *)descriptor;
> NSNumber *value = aDescriptor.value;
> // Do something with value
> break;
> }
> case CellDecriptorTypeUnknown:
> default: {
> // Handle error
> break;
> }
> }
> }
> } 
> 
> 
> I want to implement it swifty way. So the questions are:
> 0. Is it a bad practice to use this pattern and how we can avoid it?
> 1. Is it possible to avoid inheritance here and only use generic protocols 
> and how?
> 2. Is it possible to avoid downcasting if using this pattern in swift?
> 
> 
> I've found the solution that seems to be a good example in this project 
> https://github.com/xmartlabs/Eureka.
> They maintain both inheritance hierarchy and protocol hierarchy.

If you have a fixed set of types here, and you want to switch over them in a 
type-safe way, the natural thing to do would be to use an enum with payloads:

enum BaseCellDescriptor {
  case type1(CellDescriptor1)
  case type2(CellDescriptor2)
}

func doWorkWithCellDescriptors(_ descriptors: [BaseCellDescriptor]) {
  for descriptor in descriptors {
switch descriptor {
case .type1(let aDescriptor):
  // aDescriptor has type CellDescriptor1 here
case .type2(let aDescriptor):
  // aDescriptor has type CellDescriptor2 here
}
  }
}

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

Re: [swift-users] Passing Data to a f(void *) function

[Joe Groff via swift-users]

> On Jun 30, 2017, at 7:40 AM, Martin R via swift-users  
> wrote:
> 
> I have a C function 
> 
>void myfunc(const void *ptr);
> 
> which is imported to Swift as
> 
>func myfunc(_ ptr: UnsafeRawPointer!)
> 
> This compiles and runs without problems:
> 
>let data = Data(bytes: [1, 2, 3, 4])
>data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)
> 
> and the type of `ptr` is inferred as `UnsafePointer`. But adding an 
> explicit type
> annotation produces a compiler warning:
> 
>data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (B)
>// warning: UnsafePointer has been replaced by UnsafeRawPointer
> 
> which is understandable in the view of "SE-0107 UnsafeRawPointer API".
> 
> The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and that 
> does not
> compile anymore:
> 
>data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
>// error: cannot convert value of type 'Void' to closure result type '_'
> 
> because there is no `withUnsafeBytes()` method taking a 
> `(UnsafeRawPointer)->ResultType`
> closure.

This is a bug. The Data API ought to be using UnsafeRawPointer here.

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

[swift-users] swift package manager sources as symbolic links

[Rick Summerhill via swift-users]

I have an application using only swift source code that works fine on mac osx.  
It is a UI app and I’d like to create a command line version separate from UI 
version.  I’ve also separated the model code into a separate framework and 
linked it to the UI version.  I’d like to use that framework code in the 
command line version.

To do that, I’ve created a package (using the Swift Package Manager on osx) 
corresponding to the framework whose sources are copied to the package sources 
directory.  The command line version works fine under that scenario.  However, 
in order to only have to maintain a single set of source code, I’d like to 
change the copied files to symbolic links to the framework source code 
(symbolic because the source may sit on a separate device). When I do that, the 
package library builds fine, but when I build the command line program, it 
fails with the error message

the package  contains no modules
fix: create at least one module

Am I doing something wrong here or can one just not use symbolic links?

Thanks,

--Rick

--
Rick Summerhill
Retired, Chief Technology Officer, Internet2
10233 Timberhill Rd
Manchester, MI 48158 USA
--
Home:   734-428-1422  Cell:  734-276-1904
Email:  rr...@summerhill.org  Web:   http://www.rick.summerhill.org





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

Re: [swift-users] Passing Data to a f(void *) function

[Martin R via swift-users]

> On 30. Jun 2017, at 16:57, Daniel Dunbar  wrote:
> 
>> 
>> On Jun 30, 2017, at 7:40 AM, Martin R via swift-users 
>>  wrote:
>> 
>> I have a C function 
>> 
>>   void myfunc(const void *ptr);
>> 
>> which is imported to Swift as
>> 
>>   func myfunc(_ ptr: UnsafeRawPointer!)
>> 
>> This compiles and runs without problems:
>> 
>>   let data = Data(bytes: [1, 2, 3, 4])
>>   data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)
>> 
>> and the type of `ptr` is inferred as `UnsafePointer`. But adding an 
>> explicit type
>> annotation produces a compiler warning:
> 
> How do you know the inferred type is `UnsafePointer`? I think it is 
> more likely it is `UnsafePointer`, and the following compiles:
> ```
> let data = Data(bytes: [1, 2, 3, 4])
> data.withUnsafeBytes { (ptr: UnsafePointer) in
>myfunc(ptr)
> }
> ```
> 
> - Daniel

Command-click on "ptr" in "myfunc(ptr)" (or the Quick Help inspector) shows

let ptr: (UnsafePointer<()>)

> 
>> 
>>   data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (B)
>>   // warning: UnsafePointer has been replaced by UnsafeRawPointer
>> 
>> which is understandable in the view of "SE-0107 UnsafeRawPointer API".
>> 
>> The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and that 
>> does not
>> compile anymore:
>> 
>>   data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
>>   // error: cannot convert value of type 'Void' to closure result type '_'
>> 
>> because there is no `withUnsafeBytes()` method taking a 
>> `(UnsafeRawPointer)->ResultType`
>> closure.
>> 
>> 
>> My questions are:
>> 
>> 1. Why are (A) and (B) treated differently?
>> 
>> 2. Is (A) "legal", or should one use some non-void pointer
>> 
>>   data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (D)
>> 
>>  (which feels wrong to me because it is converted back to a void pointer when
>>  calling the function).
>> 
>> 3. Or should there be a `withUnsafeRawPointer()` method which makes (C) 
>> compile as
>> 
>> data.withUnsafeRawBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) }
>> 
>>  This would also allow to access the data at byte offsets more easily, e.g.
>> 
>>  data.withUnsafeRawBytes { ptr in
>>  let u16 = ptr.load(fromByteOffset: 4, as: UInt16.self)
>>  }
>> 
>>  Does that makes sense?
>> 
>> Regards, Martin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Passing Data to a f(void *) function

[Daniel Dunbar via swift-users]

> On Jun 30, 2017, at 7:40 AM, Martin R via swift-users  
> wrote:
> 
> I have a C function 
> 
>void myfunc(const void *ptr);
> 
> which is imported to Swift as
> 
>func myfunc(_ ptr: UnsafeRawPointer!)
> 
> This compiles and runs without problems:
> 
>let data = Data(bytes: [1, 2, 3, 4])
>data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)
> 
> and the type of `ptr` is inferred as `UnsafePointer`. But adding an 
> explicit type
> annotation produces a compiler warning:

How do you know the inferred type is `UnsafePointer`? I think it is more 
likely it is `UnsafePointer`, and the following compiles:
```
let data = Data(bytes: [1, 2, 3, 4])
data.withUnsafeBytes { (ptr: UnsafePointer) in
myfunc(ptr)
}
```

 - Daniel

> 
>data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (B)
>// warning: UnsafePointer has been replaced by UnsafeRawPointer
> 
> which is understandable in the view of "SE-0107 UnsafeRawPointer API".
> 
> The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and that 
> does not
> compile anymore:
> 
>data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
>// error: cannot convert value of type 'Void' to closure result type '_'
> 
> because there is no `withUnsafeBytes()` method taking a 
> `(UnsafeRawPointer)->ResultType`
> closure.
> 
> 
> My questions are:
> 
> 1. Why are (A) and (B) treated differently?
> 
> 2. Is (A) "legal", or should one use some non-void pointer
> 
>data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (D)
> 
>   (which feels wrong to me because it is converted back to a void pointer when
>   calling the function).
> 
> 3. Or should there be a `withUnsafeRawPointer()` method which makes (C) 
> compile as
> 
>  data.withUnsafeRawBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) }
> 
>   This would also allow to access the data at byte offsets more easily, e.g.
> 
>   data.withUnsafeRawBytes { ptr in
>   let u16 = ptr.load(fromByteOffset: 4, as: UInt16.self)
>   }
> 
>   Does that makes sense?
> 
> Regards, Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Passing Data to a f(void *) function

[Martin R via swift-users]

I have a C function 

void myfunc(const void *ptr);

which is imported to Swift as

func myfunc(_ ptr: UnsafeRawPointer!)

This compiles and runs without problems:

let data = Data(bytes: [1, 2, 3, 4])
data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)

and the type of `ptr` is inferred as `UnsafePointer`. But adding an 
explicit type
annotation produces a compiler warning:

data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (B)
// warning: UnsafePointer has been replaced by UnsafeRawPointer

which is understandable in the view of "SE-0107 UnsafeRawPointer API".

The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and that 
does not
compile anymore:

data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
// error: cannot convert value of type 'Void' to closure result type '_'

because there is no `withUnsafeBytes()` method taking a 
`(UnsafeRawPointer)->ResultType`
closure.


My questions are:

1. Why are (A) and (B) treated differently?

2. Is (A) "legal", or should one use some non-void pointer

data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } // (D)

   (which feels wrong to me because it is converted back to a void pointer when
   calling the function).

3. Or should there be a `withUnsafeRawPointer()` method which makes (C) compile 
as

  data.withUnsafeRawBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) }

   This would also allow to access the data at byte offsets more easily, e.g.

   data.withUnsafeRawBytes { ptr in
   let u16 = ptr.load(fromByteOffset: 4, as: UInt16.self)
   }

   Does that makes sense?

Regards, Martin








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

Re: [swift-users] Compilation time problems when building matrices

[Elia Cereda via swift-users]

> The intermediates are also things you’re going to want to store if anything 
> for code clarity since the array literal starts looking messy when you shove 
> long expressions into it.

Yes, I agree. I guess having everything in the matrix looks kind of nice with 
simple expressions, but starts to become untenable once you need to do more 
than a few computations per element. Here I was more interested in learning 
something about the performance characteristics of the Swift type checker than 
writing good code. After all, this is a project that I started specifically to 
experiment.

> It also cuts down a little on the number of redundant operations you have to 
> do (from 21 in your example to 16), especially divisions which you have six 
> of in the original.


I’m not so sure about this. I haven’t tried optimising this function for 
performance, it is called only once in my application for now, but I would 
expect Common Subexpression Elimination in the Swift compiler / LLVM to be able 
to automatically identify those redundancies.

Back to the point of compilation times, is there some resource that explains 
the performance of the type checker? I’ve been reading 
https://github.com/apple/swift/blob/master/docs/TypeChecker.rst#performance 
, 
but that only illustrates possible optimisations to improve the performance 
from the side of the compiler. I’d also be curious to look at the constraints 
generated by the type checker, is there any flag that dumps them?
 
Regards,
Elia Cereda

> Il giorno 28 giu 2017, alle ore 22:21, Taylor Swift  ha 
> scritto:
> 
> i have a similar function in my code which uses four intermediates but 
> compiles in reasonable time 
> 
> {
> // frustum
> let f_width:Float  =  self.half_h  * self.twice_size,
> f_height:Float =  self.half_k  * self.twice_size,
> dx:Float   = -self.shift_x / self.half_h,
> dy:Float   = -self.shift_y / self.half_k
> 
> let clip_ratio:Float = 1000
> 
> self.projection_matrix =
> [self.z/f_width , 0  , 0  
>, 0,
>  0  , self.z/f_height, 0  
>, 0,
>  dx , dy ,(1 + clip_ratio) / (1 - 
> clip_ratio),-1,
>  0  , 0  , self.z*2*clip_ratio / (1 - 
> clip_ratio), 0]
> }
> 
> The intermediates are also things you’re going to want to store if anything 
> for code clarity since the array literal starts looking messy when you shove 
> long expressions into it. It also cuts down a little on the number of 
> redundant operations you have to do (from 21 in your example to 16), 
> especially divisions which you have six of in the original.
> 
> On Wed, Jun 28, 2017 at 1:51 PM, Elia Cereda via swift-users 
> mailto:swift-users@swift.org>> wrote:
> Hi,
> 
> I currently writing a demo app to teach myself the fundamentals of Metal and 
> a big part of that is obviously working with matrices. What I’m seeing is 
> that the code build them has some serious compilation time problems.
> 
> The worst case is this function, which according to 
> -debug-time-function-bodies takes over 9500ms of time to compile.
> 
> static func frustum(l: Float, r: Float, t: Float, b: Float, n: Float, f: 
> Float) -> float4x4 {
> return float4x4(rows: [
> [ 2 * n / (r - l),   0,  (r + l) / (r - l),   
>  0 ],
> [   0, 2 * n / (t - b),  (t + b) / (t - b),   
>  0 ],
> [   0,   0, -(f + n) / (f - n), -2 * f * 
> n / (f - n) ],
> [   0,   0, -1,   
>  1 ],
> ])
> }
> 
> I’ve tried making some naive changes to the code and gotten it down to a much 
> more reasonable 4ms, but the result is not something I would write if given a 
> choice.
> 
> static func frustum(l: Float, r: Float, t: Float, b: Float, n: Float, f: 
> Float) -> float4x4 {
> let twoN = 2 * n
> 
> let rPlusL = r + l
> let rMinusL = r - l
> 
> let tPlusB = t + b
> let tMinusB = t - b
> 
> let fPlusN = f + n
> let fMinusN = f - n
> 
> return float4x4(rows: [
> [ twoN / rMinusL,  0,  rPlusL / rMinusL,  
>  0 ],
> [  0, twoN / tMinusB,  tPlusB / tMinusB,  
>  0 ],
> [  0,  0, -fPlusN / fMinusN, -twoN * f / 
> fMinusN ],
> [  0,  0,-1,  
>  1 ],
> ])
> }
> 
> I’m taking this to swift-users since I’m aware this is a known pain point 
> with the compiler. Is this specific instance something that would be worth 
> filing a b

[swift-users] UIDocumentBrowserViewController Bug in Xcode 9 Beta 2?

[Howard Lovatt via swift-users]

Hi,

I am having problems with UIDocumentBrowserViewController Bug in Xcode 9
Beta 2, was working with beta 1.

The symptom is that you can't create a new document, on most pages the +
icon is missing or greyed out. On the browse page it is present and not
greyed out, but doesn't work.

EG If you start a new Documents project and modify the function below to
include the print statement given:

func documentBrowser(_ controller: UIDocumentBrowserViewController,
didRequestDocumentCreationWithHandler importHandler: @escaping (URL?,
UIDocumentBrowserViewController.ImportMode) -> Void) {

print("creating document")

...


Then the print statement isn't printed when + on browse page is tapped.


Testing on iPad Pro 12" (original) with latest iOS 11 beta.


Is this a bug? Am I doing something wrong?


Thanks for any help,


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