Re: [swift-users] Class vs Structures

[Vitor Navarro via swift-users]

Hi Alex,

Thank you for the reply, actually Taylor gave me a great answer which
solved my question, that was "struct or classes and when should we apply
each".

Regarding the reference I found this
https://github.com/raywenderlich/swift-style-guide#code-organization which
doesn't follow exactly the structs most of the times approach or the
protocol driven development (WWDC)

Again thanks.

2017-06-29 14:21 GMT-04:00 Alex Blewitt :

> On 29 Jun 2017, at 18:16, Vitor Navarro via swift-users <
> swift-users@swift.org> wrote:
>
> Hi,
>
> I know this question is probably done a thousand times, but I wanted to
> hear from Swift dev community.
>
>
> What is the question?
>
> I think both of them have right places for usage depending on the occasion
> but documentation, WWDC and the internet give opposite answers regarding
> this.
>
>
> Do you have references that you can share?
>
> Do you guys have any guideline regarding usage here?
>
>
> The Swift Programming Language  sums up the similarities and differences
> between classes and structures quite well:
>
> https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html
>
> Alex
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Class vs Structures

[Vitor Navarro via swift-users]

Hi Taylor,

Thank you for the answer quite enlightening and also a better explanation
than the short direction given by the docs. Could you please provide a
sample for scoping with enums? I couldn't visualize it.

Thanks again.

2017-06-29 14:41 GMT-04:00 Taylor Swift :

> When in doubt, go with a struct. Probably nineteen types out of twenty I
> write are structs. Swift really is optimized with the assumption that
> you’re working with structs, that’s why almost everything in the standard
> library is a value type. Structs always pack contiguously into arrays,
> while arrays of classes can get bridged to a non-contiguous NSArray. Code
> that uses classes tends to be hard to read since `let` and `var` cease to
> convey useful information about mutability. Classes also open up cans of
> worms with strong and weak ownership cycles and all that crap which is
> almost completely avoidable if you know how to use value types well.
>
> The only reason to use a class is if you really, really need reference
> semantics — i.e., the instance does not have a clearly defined owner, and
> you want any changes to the instance to be reflected in all of its owners.
> This is rare though, and more often than not this is a code smell that
> something is wrong with the larger design. Another case is when the
> instance manages some kind of external resource, like a memory buffer, and
> you have no other way of untangling the resource management from the life
> cycle of the instance. This is why Swift array buffers are classes (though
> the Array type itself is a struct which contains the buffer class).
>
> Another case where a class *might* be appropriate is when your type
> contains many many stored properties, that pushing and popping them off the
> call stack by value would be slower than pushing a reference. That’s
> usually a sign that you’re not making enough use of static or computed
> properties though. The pass by value cost is also not as important as you
> might think — small functions will get inlined by the compiler, while large
> functions don’t care since the function call cost will be dwarfed by the
> cost of executing the actual function body.
>
> Inheritance and polymorphism are *not* a good enough reason to use
> classes; that’s what extensions and protocols are for.
>
> Don’t use a struct as a scoping container; use an enum for that. Some
> people scope things to structs because they don’t remember that enums can
> be used as a namespace, but the swift idiom is to use an enum for this, not
> a struct.
>
> tldr; structs and enums are the preferred native Swift object, classes are
> really only there for programmers coming from other languages who are used
> to thinking in terms of reference types.
>
> On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi,
>>
>> I know this question is probably done a thousand times, but I wanted to
>> hear from Swift dev community.
>>
>> I think both of them have right places for usage depending on the
>> occasion but documentation, WWDC and the internet give opposite answers
>> regarding this.
>>
>> Do you guys have any guideline regarding usage here?
>>
>> Thank you.
>>
>> Vitor Navarro
>>
>> ___
>> 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 4 compiler error tuple parameter does not support destructing

[CK TUNG via swift-users]

Many thanks.  It works in Swift 4 Xcode 9 beta2.

On Jun 30, 2017, at 11:20 AM, Daniel Dunbar  wrote:

This is due to SE-0110:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
but see the additional commentary:
  
https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html

For now you can rewrite it as:
```
let filenamelength = bytes
  .enumerated()
  .map {
    let (index, element) = $0
    return Int(Double(element) * pow(256,Double(index))) }
  .reduce(0, +)
```

 - Daniel

On Jun 29, 2017, at 8:08 PM, CK TUNG via swift-users  
wrote:
I have the following code snippet that compile OK in swift 3

            bytes = Array(UnsafeBufferPointer())
            let filenamelength = bytes[(i+28)..<(i+28+2)]
                .enumerated()
                .map { (index, element) in return Int(Double(element) * 
pow(256,Double(index))) }
                .reduce(0, +)
 
I have the following code snippet that compile OK in swift 3
In Swift 4 (Xcode beta1) it compiled with error something like "... too complex"
Now in Swift 4 Xocde beta2 the error is tuple parameter element does not 
support destructing
what has been changed in swift 4 ?

Please help how to solve it ?

Thanks

___
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 4 compiler error tuple parameter does not support destructing

[Daniel Dunbar via swift-users]

This is due to SE-0110:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
but see the additional commentary:
  
https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html

For now you can rewrite it as:
```
let filenamelength = bytes
  .enumerated()
  .map {
let (index, element) = $0
return Int(Double(element) * pow(256,Double(index))) }
  .reduce(0, +)
```

 - Daniel

> On Jun 29, 2017, at 8:08 PM, CK TUNG via swift-users  
> wrote:
> 
> I have the following code snippet that compile OK in swift 3
> 
> bytes = Array(UnsafeBufferPointer())
> let filenamelength = bytes[(i+28)..<(i+28+2)]
> .enumerated()
> .map { (index, element) in return Int(Double(element) * 
> pow(256,Double(index))) }
> .reduce(0, +)
>  
> I have the following code snippet that compile OK in swift 3
> In Swift 4 (Xcode beta1) it compiled with error something like "... too 
> complex"
> Now in Swift 4 Xocde beta2 the error is tuple parameter element does not 
> support destructing
> what has been changed in swift 4 ?
> 
> Please help how to solve it ?
> 
> Thanks
> 
> ___
> 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] swift 4 compiler error tuple parameter does not support destructing

[CK TUNG via swift-users]

I have the following code snippet that compile OK in swift 3

            bytes = Array(UnsafeBufferPointer())
            let filenamelength = bytes[(i+28)..<(i+28+2)]
                .enumerated()
                .map { (index, element) in return Int(Double(element) * 
pow(256,Double(index))) }
                .reduce(0, +)
 
I have the following code snippet that compile OK in swift 3
In Swift 4 (Xcode beta1) it compiled with error something like "... too complex"
Now in Swift 4 Xocde beta2 the error is tuple parameter element does not 
support destructing
what has been changed in swift 4 ?

Please help how to solve it ?

Thanks

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

Re: [swift-users] cascaded do/catch bug?

[Marco S Hyman via swift-users]

> On Jun 29, 2017, at 4:20 PM, Jordan Rose  wrote:
> 
> That does sound like a bug to me. Can you make a self-contained test case and 
> file at https://bugs.swift.org/ ?

Done. SR-5339

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

Re: [swift-users] cascaded do/catch bug?

[Jordan Rose via swift-users]

That does sound like a bug to me. Can you make a self-contained test case and 
file at https://bugs.swift.org/  ?

Thanks!
Jordan


> On Jun 29, 2017, at 14:00, Marco S Hyman via swift-users 
>  wrote:
> 
> This macOS code in Xcode 8.3.3:
> 
>if !fileManager.fileExists(atPath: (saveFileURL.path)) {
>do {
> 1 ==>   try fileManager.linkItem(atPath: url.path, toPath: 
> saveFileURL.path)
> 2 ==>   } catch {
>// couldn't create hard link, copy file instead
>do {
> 3 ==>   try fileManager.copyItem(at: url, to: saveFileURL)
>} catch let error as NSError {
>unexpected(error: error,
>   "Cannot copy \(url.path) to 
> \(saveFileURL.path)\n\nReason: ")
>return false
>}
>}
>}
>return true
> 
> 
> lldb tells me the code at 1 fails.  That was expected.  The app is sandboxed 
> and the security bookmark code that gives access to the destination is in 
> flux.  lldb says control transfers to 2 then falls into the do block 
> containing 3.
> 
> The code at 3 fails for the same reason.  This is when the unexpected 
> occurred.  lldb says that control transferred to 2 then to the end of the if 
> statement where the function returns true.  The catch following the do 
> containing the function “unexpected” is not entered.
> 
> Is that a bug?
> 
> As for why 1 uses path instead of URL an older version of the code had this 
> note.
> 
> // linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.
> 
> 
> ___
> 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] FloatingPoint equality ..

[Gavin Eadie via swift-users]

.. agreed but this looks too awful (and is mostly a joke!)

return a >= b.nextDown.nextDown.nextDown.nextDown && a <= b.nextUp.
nextUp.nextUp.nextUp

Thanks, friends, for your insights and info .. Gavin

On Thu, Jun 29, 2017 at 3:30 PM, Taylor Swift via swift-users <
swift-users@swift.org> wrote:

>
>> (b) one ULP is almost never a tolerance you want to use. It’s much too
>> small for almost all computations, and too large for most of the remaining
>> ones.
>>
>> – Steve
>>
>
> ___
> 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] cascaded do/catch bug?

[Marco S Hyman via swift-users]

This macOS code in Xcode 8.3.3:

if !fileManager.fileExists(atPath: (saveFileURL.path)) {
do {
1 ==>   try fileManager.linkItem(atPath: url.path, toPath: saveFileURL.path)
2 ==>   } catch {
// couldn't create hard link, copy file instead
do {
3 ==>   try fileManager.copyItem(at: url, to: saveFileURL)
} catch let error as NSError {
unexpected(error: error,
   "Cannot copy \(url.path) to 
\(saveFileURL.path)\n\nReason: ")
return false
}
}
}
return true


lldb tells me the code at 1 fails.  That was expected.  The app is sandboxed 
and the security bookmark code that gives access to the destination is in flux. 
 lldb says control transfers to 2 then falls into the do block containing 3.

The code at 3 fails for the same reason.  This is when the unexpected occurred. 
 lldb says that control transferred to 2 then to the end of the if statement 
where the function returns true.  The catch following the do containing the 
function “unexpected” is not entered.

Is that a bug?

As for why 1 uses path instead of URL an older version of the code had this 
note.

// linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.


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

[swift-users] New books

[Bill Marcy via swift-users]

Are there any books that you can recommend for Xcode 8.3.3 and Xcode 4.0?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Itai Ferber via swift-users]

Hi Kevin,

> On Jun 29, 2017, at 12:30 PM, Kevin Wooten via swift-users 
>  wrote:
> 
>> Hi Jon,
>> 
>> I just joined this mailing list and have tried to catch up on the 
>> history of this thread, so please excuse me if I’ve missed something.
>> 
>> I’m sorry the Codable API at the moment does not answer your needs — 
>> you’re clearly not the only one who’s run into this, so let’s see 
>> how we can work together to make the API better for everyone.
>> For one thing, in the case of grabbing a subtree of JSON as 
>> "unevaluated" or "unmapped" (as it appears to be in the metadata case), 
>> it should be fairly simple to add a `JSONDecoder.UnevaluatedJSON` type 
>> that will allow you to essentially decode that part of the tree as an 
>> `Any`. `JSONDecoder` would have knowledge of this type and would be able 
>> to return the subtree inside of it — you’d decode a property as 
>> `JSONDecoder.UnevaluatedJSON.self` and access the contents through `var 
>> value: Any?`, or something similar. This would be simple additive API, 
>> which although might not make it in the upcoming betas, should be fairly 
>> simple introduce. Would this solve that use case?
>> 
>> We’re also working on improving `NSISO8601DateFormatter`. I don’t 
>> think I saw it in any of your emails — what specific use case are you 
>> looking for that it doesn’t at the moment support?
>> 
>> — Itai
> 
> 
> Itai, 
> 
> Is this a formal solution that is going to be implemented? This would solve 
> just about every issue I currently have with Decodable.
I can’t make any promises at the moment — we’ve got a lot of high-priority 
things to fix before the Swift 4.0 release. However, this is something I’d 
certainly like to put through API review and eventually release, since this is 
clearly something that would be beneficial to a lot of our users.

> Two points…
> 
> 1) Putting it on `JSONDecoder` seems dubious since you’d only have access to 
> `Decoder` (although conditional casting could solve that). It seems adding 
> the method to `Decoder` and using `Decoder.Unevaluated.self` as the requested 
> type, would be more useful. A user could then conditionally cast that value 
> to things like `[String: Any]` and possibly use its contents generically.
Putting that on Decoder would require all Decoders to have an "unevaluated 
type" representation, which may not be appropriate for all formats.
Since this is very often a request when working with 3rd-party APIs which you 
don’t control (and are rarely offered in more than one format, if that), 
putting this directly on JSONDecoder seems reasonable — you’d only really 
expect this representation if you’re decoding from JSON; if you’re encoding 
to/from a different format, you’re likely in control of the data in those 
formats.

> 2) Matching it with an equivalent on `Encoder` would be great as well.  We 
> take in JSON that has “metaData” like one aforementioned exampled. We then 
> have to send back the equivalent metadata during a subsequent update; without 
> ever inspecting or altering the unevaluated data. Being able encode a 
> `Decoder.Unevaluated` would solve that problem as well.
Yes, we’d add an equivalent type on encode as well.

> 
> 
> ___
> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Kevin Wooten via swift-users]

> Hi Jon,
> 
> I just joined this mailing list and have tried to catch up on the 
> history of this thread, so please excuse me if I’ve missed something.
> 
> I’m sorry the Codable API at the moment does not answer your needs — 
> you’re clearly not the only one who’s run into this, so let’s see 
> how we can work together to make the API better for everyone.
> For one thing, in the case of grabbing a subtree of JSON as 
> "unevaluated" or "unmapped" (as it appears to be in the metadata case), 
> it should be fairly simple to add a `JSONDecoder.UnevaluatedJSON` type 
> that will allow you to essentially decode that part of the tree as an 
> `Any`. `JSONDecoder` would have knowledge of this type and would be able 
> to return the subtree inside of it — you’d decode a property as 
> `JSONDecoder.UnevaluatedJSON.self` and access the contents through `var 
> value: Any?`, or something similar. This would be simple additive API, 
> which although might not make it in the upcoming betas, should be fairly 
> simple introduce. Would this solve that use case?
> 
> We’re also working on improving `NSISO8601DateFormatter`. I don’t 
> think I saw it in any of your emails — what specific use case are you 
> looking for that it doesn’t at the moment support?
> 
> — Itai


Itai, 

Is this a formal solution that is going to be implemented? This would solve 
just about every issue I currently have with Decodable.

Two points…

1) Putting it on `JSONDecoder` seems dubious since you’d only have access to 
`Decoder` (although conditional casting could solve that). It seems adding the 
method to `Decoder` and using `Decoder.Unevaluated.self` as the requested type, 
would be more useful. A user could then conditionally cast that value to things 
like `[String: Any]` and possibly use its contents generically.

2) Matching it with an equivalent on `Encoder` would be great as well.  We take 
in JSON that has “metaData” like one aforementioned exampled. We then have to 
send back the equivalent metadata during a subsequent update; without ever 
inspecting or altering the unevaluated data. Being able encode a 
`Decoder.Unevaluated` would solve that problem as well.


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

Re: [swift-users] FloatingPoint equality ..

[Stephen Canon via swift-users]

I should also point out:

(a) your code can be somewhat simpler in Swift. I would probably write 
something along the lines of:

func almostEqual(_ a: T, _ b: T) -> Bool {
return a >= b.nextDown && a <= b.nextUp
}

(b) one ULP is almost never a tolerance you want to use. It’s much too small 
for almost all computations, and too large for most of the remaining ones.

– Steve___
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]

When in doubt, go with a struct. Probably nineteen types out of twenty I
write are structs. Swift really is optimized with the assumption that
you’re working with structs, that’s why almost everything in the standard
library is a value type. Structs always pack contiguously into arrays,
while arrays of classes can get bridged to a non-contiguous NSArray. Code
that uses classes tends to be hard to read since `let` and `var` cease to
convey useful information about mutability. Classes also open up cans of
worms with strong and weak ownership cycles and all that crap which is
almost completely avoidable if you know how to use value types well.

The only reason to use a class is if you really, really need reference
semantics — i.e., the instance does not have a clearly defined owner, and
you want any changes to the instance to be reflected in all of its owners.
This is rare though, and more often than not this is a code smell that
something is wrong with the larger design. Another case is when the
instance manages some kind of external resource, like a memory buffer, and
you have no other way of untangling the resource management from the life
cycle of the instance. This is why Swift array buffers are classes (though
the Array type itself is a struct which contains the buffer class).

Another case where a class *might* be appropriate is when your type
contains many many stored properties, that pushing and popping them off the
call stack by value would be slower than pushing a reference. That’s
usually a sign that you’re not making enough use of static or computed
properties though. The pass by value cost is also not as important as you
might think — small functions will get inlined by the compiler, while large
functions don’t care since the function call cost will be dwarfed by the
cost of executing the actual function body.

Inheritance and polymorphism are *not* a good enough reason to use classes;
that’s what extensions and protocols are for.

Don’t use a struct as a scoping container; use an enum for that. Some
people scope things to structs because they don’t remember that enums can
be used as a namespace, but the swift idiom is to use an enum for this, not
a struct.

tldr; structs and enums are the preferred native Swift object, classes are
really only there for programmers coming from other languages who are used
to thinking in terms of reference types.

On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
> I know this question is probably done a thousand times, but I wanted to
> hear from Swift dev community.
>
> I think both of them have right places for usage depending on the occasion
> but documentation, WWDC and the internet give opposite answers regarding
> this.
>
> Do you guys have any guideline regarding usage here?
>
> Thank you.
>
> Vitor Navarro
>
> ___
> 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] FloatingPoint equality ..

[Gavin Eadie via swift-users]

I've spent a fascinating evening and morning in the arcane depths of
floating point, specifically researching the comparison of two floating
point numbers.  I pretty much understand how to do this with a combination
of 'epsilon' and 'ULPs' after reading this

.

For example, for a off-by-one ULP comparison:

public func almostEqual(_ a: Double, _ b: Double) -> Bool {

return a == b ||

   a == nextafter(b, +.greatestFiniteMagnitude) ||

   a == nextafter(b, -.greatestFiniteMagnitude)

}

My question is whether Swift has a built in method that provides an 'almost
equal' comparison?

Or, asking the same question another way, what doesn't the Swift method

 func isEqual(to other: Self) -> Bool


actually do?  Does it test for equality of the binary representation of
'self' and 'other' (I assume it must given no 'precision' argument) .. I
read it follows the IEEE meaning of equality but that document is not on my
bookshelf and is quite expensive!

Apologies if this has been asked and answered before .. Gavin
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Class vs Structures

[Alex Blewitt via swift-users]

> On 29 Jun 2017, at 18:16, Vitor Navarro via swift-users 
>  wrote:
> 
> Hi,
> 
> I know this question is probably done a thousand times, but I wanted to hear 
> from Swift dev community.

What is the question?

> I think both of them have right places for usage depending on the occasion 
> but documentation, WWDC and the internet give opposite answers regarding this.

Do you have references that you can share?

> Do you guys have any guideline regarding usage here?

The Swift Programming Language  sums up the similarities and differences 
between classes and structures quite well:

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html
 


Alex

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

[swift-users] Class vs Structures

[Vitor Navarro via swift-users]

Hi,

I know this question is probably done a thousand times, but I wanted to
hear from Swift dev community.

I think both of them have right places for usage depending on the occasion
but documentation, WWDC and the internet give opposite answers regarding
this.

Do you guys have any guideline regarding usage here?

Thank you.

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