Re: [swift-users] Details of defer statement in Swift

[Rien via swift-users]

The manual says this:

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

A defer statement is used for executing code just before transferring program 
control outside of the scope that the defer statement appears in.

The scope of a for loop ends when the loop ends.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 10 Nov 2016, at 08:32, Andrea VEH via swift-users  
> wrote:
> 
> Hello,
> From The Swift Programming Language, I learn the defer statements execute 
> in the reverse order that they appear in the program. And when there are two 
> or more defer statements in a loop(e.g. a for loop), defer statements execute 
> still in the reverse order that they appear, but in the loop order that the 
> loop statement executes. Code snippet is 
> here(https://swiftlang.ng.bluemix.net/#/repl/582421bfdee52b5745935771).
> Early I saw this 
> thread(https://twitter.com/lexrus/status/796370747849441280) from Twitter, I 
> am curious about defer statement's execute order. Can you tell more details 
> about it?
> 
> Best regards,
> ___
> 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] Details of defer statement in Swift

[Andrea VEH via swift-users]

Hello,
From *The Swift Programming Language*, I learn the defer statements
execute in the reverse order that they appear in the program. And when
there are two or more defer statements in a loop(e.g. a for loop), defer
statements execute still in the reverse order that they appear, but in the
loop order that the loop statement executes. Code snippet is here(
https://swiftlang.ng.bluemix.net/#/repl/582421bfdee52b5745935771).
Early I saw this thread(
https://twitter.com/lexrus/status/796370747849441280) from Twitter, I am
curious about defer statement's execute order. Can you tell more details
about it?

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

Re: [swift-users] Int32.divideWithOverflow

[Dave Abrahams via swift-users]

on Wed Nov 09 2016, Peter W A Wood  wrote:

> I am using Swift to generate some tests with overflowing 32-bit
> integers. I have used the Int32.WithOverflow functions but have
> come across a problem dividing Int32.min by -1 with overflow. I get an
> overflow error:
>
> error: division '-2147483648 / -1' results in an overflow
> Int32.divideWithOverflow(Int32.min, -1)
>
> Is this the expected behaviour?

Yes.

   -Int64(Int32.min) > Int64(Int32.max)

which is to say that the result of the division can't be expressed as
an Int32.

-- 
-Dave

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

[swift-users] Int32.divideWithOverflow

[Peter W A Wood via swift-users]

I am using Swift to generate some tests with overflowing 32-bit integers. I 
have used the Int32.WithOverflow functions but have come across a problem 
dividing Int32.min by -1 with overflow. I get an overflow error:

error: division '-2147483648 / -1' results in an overflow
Int32.divideWithOverflow(Int32.min, -1)

Is this the expected behaviour?

Regards

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

[swift-users] lldb not working when C module includes a header outside of it's /include dir

[Andrey Fidrya via swift-users]

Hi All,

When C module includes a header outside of module's include/ directory and
not residing in /usr/local/include or /usr/include, lldb stops showing variable
values for the entire application.

I've created a ticket with a test project and additional details in the bug 
tracker,
any help is appreciated:
https://bugs.swift.org/browse/SR-3169 

Andrey

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

Re: [swift-users] wishing I could cast (sort of) to protocol, with associated type

[Jordan Rose via swift-users]

> On Nov 3, 2016, at 11:07, has  wrote:
> 
> Robert Nikander wrote:
>> Cc:"swift-users@swift.org"  
>> Subject: Re: [swift-users] wishing I could cast (sort of) to protocol
>>  with associated type
>> Message-ID:
>> Content-Type: text/plain; charset="utf-8"
>> 
>> The only real way to do this today is to have two layers of protocol:
>> 
>> protocol SpecialControllerBase {
>>   var currentValueBase: SpecialValue? { get }
>> }
>> protocol SpecialController: SpecialControllerBase {
>>   associatedtype SpecialValueType : SpecialValue
>>   var currentValue: SpecialValueType? { get }
>> }
>> extension SpecialController {
>>   var currentValueBase: SpecialValue? { return self.currentValue }
>> }
> 
> One other option may be to put a typealias in an extension instead of 
> declaring an associated type:
> 
> // The almost-a-generic protocol:
> 
> protocol AssProtocol {
>var xxx: AssType { get }
> }
> 
> extension AssProtocol {
>typealias AssType = Any
> }
> 
> // My concrete classes:
> 
> class MyClass1: AssProtocol {
>typealias AssType = Int
>var xxx: AssProtocol.AssType { return 1 }
> }
> 
> class MyClass2: AssProtocol {
>typealias AssType = String
>var xxx: AssProtocol.AssType { return "two" }
> }
> 
> // A generic function that uses the aforementioned protocol:
> 
> func doit(_ v: T) where T: AssProtocol.AssType {
>print(v, type(of: v))
> }
> 
> // The rare sweet joy that is 0 compiler errors AND 0 runtime crashes:
> 
> let res1 = MyClass1().xxx
> let res2 = MyClass2().xxx
> 
> doit(res1) // 1 Int.Type
> doit(res2) // two String.Type
> 
> 
> Needless to say my head is screeching "probable undefined behavior" even as I 
> type this, so caveat emptor, E, don't blame me when it eats your cat and 
> marries your wife, etc. [1] But it did finally get me out of an unspeakably 
> intractable problem with the Swift type system, thus preserving what precious 
> few last shreds of sanity I still possess. Who knows, now that I only have a 
> myriad of all-but-intractable problems left to work through, one day I might 
> even release!

To see what this is actually doing, try this instead:

func doit(_ v: T) where T: AssProtocol.AssType {
   print(T.self)
}

(and compare it with a true associated type rather than a typealias)

Associated types preserve static type information. The compiler refuses to let 
you perform operations on protocols with associated types that would throw that 
information away. You can't get around that check in today's language.

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

Re: [swift-users] Monorepo workflow using SPM

[Daniel Dunbar via swift-users]

> On Nov 3, 2016, at 2:06 PM, Erica Sadun via swift-users 
>  wrote:
> 
> I want less of a monorepo than an ability to build a group of orthogonal 
> elements into a single repo so I don't have to create a separate repo for 
> every single Swift library I build, especially when there are logical 
> relationships between subfolders and partial incorporation into builds  For 
> example, I'm messing with core graphics geometry right now. I have basic 
> types & extensions, some experimental stuff, and other misc things for (for 
> example) doing playground visualization support. Rather than 
> over-conditionalize my code, I'd rather conditionalize the package, so that 
> everything pulls, compiles, and works fine on, say, a macOS build but bits 
> that don't belong (iOS playground visualization support) can be omitted from 
> a specific configuration *for* *that* *repo* instead of me having to make 
> really ugly code conditions in files which are intended specifically for 
> known targets and may be excluded from package builds because of their 
> intended targets.

Can you explain the interaction between conditional compilation and monorepo / 
multi-package repos? They seem somewhat orthogonal to me.

 - Daniel

> -- E
> 
> 
>> On Nov 3, 2016, at 2:31 PM, Ankit Agarwal via swift-users 
>> > wrote:
>> 
>> +swift-build-dev
>> 
>> Not right now but we're considering adding support for multiple packages in 
>> a repository. It would be good if you can explain your 
>> requirements/features/flow are you looking for.
>> 
>> On Friday 4 November 2016, Georgios Moschovitis via swift-users 
>> > wrote:
>> The Swift Package Manager is a great addition to the Swift programmer's 
>> toolbelt and in general I like the integration with Git.
>> 
>> However, since SPM promotes a separate Git repo per package and actually 
>> leverages Git tags to resolve dependency versions, I am wondering if it's 
>> possible to use the popular(?) 'monorepo' workflow with SPM. 
>> 
>> thanks,
>> -g.
>> 
>> 
>> -- 
>> Ankit
>> 
>> 
>> ___
>> 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] Monorepo workflow using SPM

[Daniel Dunbar via swift-users]

(+ swift-build-dev)

Hi Georgios,

This is a very timely question, because I have been working on a proposal for 
solving exactly this problem.

Can you take a look at:
  
https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/-swiftpm-multi-package-repos.md
and see if you feel it would meet your needs?

 - Daniel


> On Nov 3, 2016, at 10:08 PM, Georgios Moschovitis via swift-users 
>  wrote:
> 
>> It would be good if you can explainyour requirements/features/floware you 
>> looking for.
> 
> Well the flow is simple, just put all your packages in one root repository. I 
> guess, SPM could be updated to allow
> linking to a local dependency by file path, not only by Git tag. 
> 
> Actually this feature would be useful even when developing multiple dependent 
> packages in separate repos. Currently you have to create new tags and refetch 
> all the time when you work on multiple packages at the same time, a small 
> annoyance.
> 
> 
> ___
> 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] if-case syntax ambiguity

[Nicholas Outram via swift-users]

Thanks for that, it was really helpful. I see it now.

I’m happy to admit I had not fully appreciated the notion of pattern matching, 
and I very much doubt I'm alone either.

The Swift Programming book goes some way to explain it (in the language 
reference section) - maybe this is an area that needs some attention (from an 
educational perspective).

Many thanks for replying.

Nick

p.s. I looked up some Erlang examples - it did help 








> On 9 Nov 2016, at 12:50, Michael Nisi  wrote:
> 
> Yes, equals isn't assignment but pattern matching here. Reminds of Erlang, 
> which I love.
> 
> Michael
> 
> On 9 Nov 2016, at 12:57, Zhao Xin via swift-users  > wrote:
> 
>> The `if case` is the same meaning as `switch-case`, so I don't think there 
>> is anything ambitious. For `switch-case`, it is not equal, it is matching.
>> 
>> Zhaoxin
>> 
>> On Wed, Nov 9, 2016 at 7:17 PM, Nicholas Outram via swift-users 
>> > wrote:
>> Hi
>> 
>> I’ve been drilling down on the syntax of enumerated types with associated 
>> data in the current release version of Swift 3.
>> I’ve pasted below a section of a Playground that captures an issue I’d like 
>> to raise.
>> 
>> In summary:
>> 
>> Consider the following 
>> enum Vehicle {
>>case car(petrol: Bool, sizeCC: Int)
>>case plane(engines : Int)
>>case other(String)
>>case none
>> }
>> let myJourney : Vehicle = .other("pogo stick")
>> 
>> Whereas the following is clear
>> if case .other(_) = myJourney
>> 
>> the following shorthand equivalent is potentially confusing for the sake of 
>> 3 characters
>> if case .other = myJourney
>> 
>> - In the first case, the presence of the underscore does communicate that 
>> something is being assigned, but dropped.
>> - In the second case, the reader could easily be mislead into thinking that 
>> = was supposed to be == as there no apparent place to assign anything.
>> 
>> My suggestion would simply be to drop the shorthand as it’s ambiguous?
>> 
>> 
>> Nick Outram
>> 
>> 
>> 
>> 
>> import Foundation
>> 
>> //: Consider the following enumerated type with associated data
>> enum Vehicle {
>>case car(petrol: Bool, sizeCC: Int)
>>case plane(engines : Int)
>>case other(String)
>>case none
>> }
>> 
>> //: Let's pick an example
>> let myJourney : Vehicle = .other("pogo stick")
>> 
>> //: I now want to test what case `myJourney` is.
>> //:
>> //: We cannot use the `==` operator because `Vehicle` has associated data. 
>> Instead we use `if case` and *simply drop the associated value* with `_` as 
>> shown above
>> if case .other(_) = myJourney {
>>print("Somewhere nice?")
>> } else {
>>print("Ok, it's a secret?")
>> }
>> //:The above is clear enough once you get used to the syntax. The `_` 
>> communicates that a value has been dropped.
>> //:
>> //: **However**, Swift 3 allows us to drop the parenthesis altogether and 
>> use the following shorthand:
>> if case .other = myJourney {
>>print("Somewhere nice?")
>> } else {
>>print("Ok, it's a secret?")
>> }
>> //: *Unlike the previous example, I do wonder if this is a language feature 
>> that needs review?*
>> //:
>> //: - On face value, reading this code as is there is an assignment operator 
>> `=` with nothing apparently being assigned.
>> //: - It also reads as if `=` should be `==`
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] if-case syntax ambiguity

[Michael Nisi via swift-users]

Yes, equals isn't assignment but pattern matching here. Reminds of Erlang, 
which I love.

Michael

> On 9 Nov 2016, at 12:57, Zhao Xin via swift-users  
> wrote:
> 
> The `if case` is the same meaning as `switch-case`, so I don't think there is 
> anything ambitious. For `switch-case`, it is not equal, it is matching.
> 
> Zhaoxin
> 
>> On Wed, Nov 9, 2016 at 7:17 PM, Nicholas Outram via swift-users 
>>  wrote:
>> Hi
>> 
>> I’ve been drilling down on the syntax of enumerated types with associated 
>> data in the current release version of Swift 3.
>> I’ve pasted below a section of a Playground that captures an issue I’d like 
>> to raise.
>> 
>> In summary:
>> 
>> Consider the following 
>> enum Vehicle {
>>case car(petrol: Bool, sizeCC: Int)
>>case plane(engines : Int)
>>case other(String)
>>case none
>> }
>> let myJourney : Vehicle = .other("pogo stick")
>> 
>> Whereas the following is clear
>> if case .other(_) = myJourney
>> 
>> the following shorthand equivalent is potentially confusing for the sake of 
>> 3 characters
>> if case .other = myJourney
>> 
>> - In the first case, the presence of the underscore does communicate that 
>> something is being assigned, but dropped.
>> - In the second case, the reader could easily be mislead into thinking that 
>> = was supposed to be == as there no apparent place to assign anything.
>> 
>> My suggestion would simply be to drop the shorthand as it’s ambiguous?
>> 
>> 
>> Nick Outram
>> 
>> 
>> 
>> 
>> import Foundation
>> 
>> //: Consider the following enumerated type with associated data
>> enum Vehicle {
>>case car(petrol: Bool, sizeCC: Int)
>>case plane(engines : Int)
>>case other(String)
>>case none
>> }
>> 
>> //: Let's pick an example
>> let myJourney : Vehicle = .other("pogo stick")
>> 
>> //: I now want to test what case `myJourney` is.
>> //:
>> //: We cannot use the `==` operator because `Vehicle` has associated data. 
>> Instead we use `if case` and *simply drop the associated value* with `_` as 
>> shown above
>> if case .other(_) = myJourney {
>>print("Somewhere nice?")
>> } else {
>>print("Ok, it's a secret?")
>> }
>> //:The above is clear enough once you get used to the syntax. The `_` 
>> communicates that a value has been dropped.
>> //:
>> //: **However**, Swift 3 allows us to drop the parenthesis altogether and 
>> use the following shorthand:
>> if case .other = myJourney {
>>print("Somewhere nice?")
>> } else {
>>print("Ok, it's a secret?")
>> }
>> //: *Unlike the previous example, I do wonder if this is a language feature 
>> that needs review?*
>> //:
>> //: - On face value, reading this code as is there is an assignment operator 
>> `=` with nothing apparently being assigned.
>> //: - It also reads as if `=` should be `==`
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] if-case syntax ambiguity

[Zhao Xin via swift-users]

The `if case` is the same meaning as `switch-case`, so I don't think there
is anything ambitious. For `switch-case`, it is not equal, it is matching.

Zhaoxin

On Wed, Nov 9, 2016 at 7:17 PM, Nicholas Outram via swift-users <
swift-users@swift.org> wrote:

> Hi
>
> I’ve been drilling down on the syntax of enumerated types with associated
> data in the current release version of Swift 3.
> I’ve pasted below a section of a Playground that captures an issue I’d
> like to raise.
>
> In summary:
>
> Consider the following
> enum Vehicle {
>case car(petrol: Bool, sizeCC: Int)
>case plane(engines : Int)
>case other(String)
>case none
> }
> let myJourney : Vehicle = .other("pogo stick")
>
> *Whereas the following is clear*
> if case .other(_) = myJourney
>
> *the following shorthand equivalent is potentially confusing for the sake
> of 3 characters*
> if case .other = myJourney
>
> - In the first case, the presence of the underscore does communicate that
> something is being assigned, but dropped.
> - In the second case, the reader could easily be mislead into thinking
> that = was supposed to be == as there no apparent place to assign anything.
>
> My suggestion would simply be to drop the shorthand as it’s ambiguous?
>
>
> Nick Outram
>
>
>
>
> import Foundation
>
> //: Consider the following enumerated type with associated data
> enum Vehicle {
>case car(petrol: Bool, sizeCC: Int)
>case plane(engines : Int)
>case other(String)
>case none
> }
>
> //: Let's pick an example
> let myJourney : Vehicle = .other("pogo stick")
>
> //: I now want to test what case `myJourney` is.
> //:
> //: We cannot use the `==` operator because `Vehicle` has associated data.
> Instead we use `if case` and *simply drop the associated value* with `_` as
> shown above
> if case .other(_) = myJourney {
>print("Somewhere nice?")
> } else {
>print("Ok, it's a secret?")
> }
> //:The above is clear enough once you get used to the syntax. The `_`
> communicates that a value has been dropped.
> //:
> //: **However**, Swift 3 allows us to drop the parenthesis altogether and
> use the following shorthand:
> if case .other = myJourney {
>print("Somewhere nice?")
> } else {
>print("Ok, it's a secret?")
> }
> //: *Unlike the previous example, I do wonder if this is a language
> feature that needs review?*
> //:
> //: - On face value, reading this code as is there is an assignment
> operator `=` with nothing apparently being assigned.
> //: - It also reads as if `=` should be `==`
>
>
>
>
>
>
> ___
> 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