Re: [swift-users] [Feature Request] Extend the `defer` statement

2017-10-08 Thread Jun Zhang via swift-users 
Yes that's true, but this requires me to set a return value in every `early
return` statement. I think this should be done by the compiler instead of
me, to make code cleaner and also less error-prone.

On Mon, Oct 9, 2017 at 11:24 AM, Slava Pestov  wrote:

> I think you can achieve what you want by having the ‘defer’ block capture
> a mutable local variable. Eg,
>
> func doStuff() {
>   var success = false
>
>   defer {
> if !success {
>   // do some additional cleanup
> }
>   }
>
>   …
>   success = true
>   …
>
>   return result
> }
>
> On Oct 8, 2017, at 7:34 PM, Jun Zhang via swift-users <
> swift-users@swift.org> wrote:
>
> Hi dear swift developers,
>I am kind of new to swift and I don't know if this feature already
> exists. And if it exists already please tell me how. Thank you very much!
>   The feature is to capturing the return value (maybe input value also) of
> the function. Here is the demo code:
>
> func tableView(_ tableView: UITableView, numberOfRowsInSection
> section: Int) -> Int {
> defer {
> if $> >= 0 {
> // table is not empty
> }
> else {
> // table is empty
> }
> }
> return dataSource.cout
> }
>
>I suggest using `$>` as the return value symbol and `$<` as the input
> parameter symbol.
>Thank you all and best regards to you!
> ___
> 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] [Feature Request] Extend the `defer` statement

2017-10-08 Thread Slava Pestov via swift-users 
I think you can achieve what you want by having the ‘defer’ block capture a 
mutable local variable. Eg,

func doStuff() {
  var success = false

  defer {
if !success {
  // do some additional cleanup
}
  }

  …
  success = true
  …

  return result
}

> On Oct 8, 2017, at 7:34 PM, Jun Zhang via swift-users  
> wrote:
> 
> Hi dear swift developers,
>I am kind of new to swift and I don't know if this feature already exists. 
> And if it exists already please tell me how. Thank you very much!
>   The feature is to capturing the return value (maybe input value also) of 
> the function. Here is the demo code:
> 
> func tableView(_ tableView: UITableView, numberOfRowsInSection section: 
> Int) -> Int {
> defer {
> if $> >= 0 {
> // table is not empty
> }
> else {
> // table is empty
> }
> }
> return dataSource.cout
> }
> 
>I suggest using `$>` as the return value symbol and `$<` as the input 
> parameter symbol. 
>Thank you all and best regards to you!
> ___
> 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] [Feature Request] Extend the `defer` statement

2017-10-08 Thread Jun Zhang via swift-users 
Hi dear swift developers,
   I am kind of new to swift and I don't know if this feature already
exists. And if it exists already please tell me how. Thank you very much!
  The feature is to capturing the return value (maybe input value also) of
the function. Here is the demo code:

func tableView(_ tableView: UITableView, numberOfRowsInSection section:
Int) -> Int {

defer {

if $> >= 0 {

// table is not empty

}

else {

// table is empty

}

}

return dataSource.cout

}

   I suggest using `$>` as the return value symbol and `$<` as the input
parameter symbol.
   Thank you all and best regards to you!
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] TWISt-shout Newsletter 2017-10-09

2017-10-08 Thread Kenny Leung via swift-users 

Hi All.

Here is your TWISt-shout Newsletter for the week of 2017-10-02 to 2017-10-08

https://github.com/pepperdog/TWISt-shout/blob/master/2017/TWISt-shout-2017-10-09.md
 


Enjoy!

-Kenny


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

[swift-users] Why does the withUnsafeMutableBufferPointer closure take an inout parameter?

2017-10-08 Thread Martin R via swift-users 
I wonder why the closure in the Array method

mutating func withUnsafeMutableBufferPointer(_ body: (inout 
UnsafeMutableBufferPointer) throws -> R) rethrows -> R

takes an _inout_ parameter. The closure is called with a pointer to the 
contiguous array storage, and I fail to imagine an example where it makes sense 
to assign a new value to the parameter.

Any insights are welcome!

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

Re: [swift-users] How to check the type of a concrete class that inherits from a generic class?

2017-10-08 Thread C. Keith Ray via swift-users 
good point - type safety would prevent it from compiling.

also, the controllers are subclasses of  
NSFetchedResultsController

but the delegate method takes a different type:  
NSFetchedResultsController

NSManagedObject != NSFetchRequestResult



--
C. Keith Ray
Senior Software Engineer / Trainer / Agile Coach
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf



> On Oct 7, 2017, at 10:32 PM, Glen Huang  wrote:
> 
> I need to do things differently in the shared delegate based on the 
> controller type, so this probably won’t work. But thanks, I believe it will 
> come in handy when I do need to branch on controllers themselves.
> 
> I do have a question though, since the method is a callback, and its 
> signature is changed (with "Thing &” added), will NSFetchedResultsController 
> be able to find it and call it? 
> 
>> On 8 Oct 2017, at 12:14 AM, C. Keith Ray > > wrote:
>> 
>> Or make a base class for both Controller classes which defines todo () and 
>> override todo() in each Controller class.
>> 
>> --
>> C. Keith Ray
>> 
>> * https://leanpub.com/wepntk  <- buy my book?
>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
>> 
>> * http://agilesolutionspace.blogspot.com/ 
>> 
>> 
>> On Oct 7, 2017, at 9:12 AM, C. Keith Ray > > wrote:
>> 
>>> You should be able to do this to avoid casting.(I think)
>>> 
>>> protocol Thing {
>>>func todo()
>>> }
>>> 
>>> class Controller1: NSFetchedResultsController, Thing {
>>> func todo () {doOneThing}
>>> }
>>> class Controller2: NSFetchedResultsController, Thing {
>>> func todo () {doAnotherThing}
>>> }
>>> 
>>> func controllerWillChangeContent(_ controller: Thing & 
>>> NSFetchedResultsController) {
>>> controller.todo()
>>> ...
>>> }
>>> 
>>> --
>>> C. Keith Ray
>>> 
>>> * https://leanpub.com/wepntk  <- buy my book?
>>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
>>> 
>>> * http://agilesolutionspace.blogspot.com/ 
>>> 
>>> 
>>> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
 Hi,
 
 I defined some concrete classes inheriting from a generic class like this:
 
 class Controller1: NSFetchedResultsController {}
 class Controller2: NSFetchedResultsController {}
 
 And I assign them a shared delegate, and in the delegate method:
 
 func controllerWillChangeContent(_ controller: 
 NSFetchedResultsController)
 
 I want to test the concrete type of controller, doing things differently 
 for Controller1 and Controller2.
 
 But doing the following gives me a warning: Cast from 
 'NSFetchedResultsController' to unrelated type 
 'Controller1’ always fails
 
 switch controller {
 case is Controller1:
// ...
 default:
break
 }
 
 I wonder what’s the correct way to check the concrete type?
 
 Regards,
 Glen
 ___
 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] Communicating with dynamically loaded swift library

2017-10-08 Thread Ján Kosa via swift-users 
I filed bug report: https://bugs.swift.org/browse/SR-6091

On 8 October 2017 at 20:31, Daniel Dunbar  wrote:

> Can you file this on bugs.swift.org? We are likely to lose track of it if
> it just an email thread
>
>  - Daniel
>
> On Oct 8, 2017, at 8:27 AM, Ján Kosa  wrote:
>
> Hey guys,
>
> I have been able to create simplest possible setup that exhibits this
> problem, the protobuf module wasn't necessary. All I import is
> PluginInterface and I get the error:
>
> objc[66212]: Class _TtC15PluginInterface15PluginInterface is implemented
> in both /Users/Lope/Dev/swift/SwiftPlugins/PluginConsumer/.
> build/x86_64-apple-macosx10.10/debug/libPluginInterface.dylib
> (0x10fc7b668) and /Users/Lope/Dev/swift/SwiftPlugins/
> PluginImplementation/.build/x86_64-apple-macosx10.10/debug/libPluginInterface.dylib
> (0x1107dd668). One of the two will be used. Which one is undefined.
>
>
> You can find modules on my github:
>
> https://github.com/Lopdo/SwiftPlugins-PluginInterface
>
> https://github.com/Lopdo/SwiftPlugins-PluginImplementation
>
> https://github.com/Lopdo/SwiftPlugins-PluginConsumer
>
>
> Could you have a quick look if I didn't mess up or missed something and I
> will create bug report. If you want to run the code for yourself, you will
> have to change the path to dylib in the PluginConsumer (I don't know how to
> use relative path and didn't have time to find out yet)
>
> On 8 October 2017 at 09:51, Ján Kosa via swift-users <
> swift-users@swift.org> wrote:
>
>> I was afraid it will come to that :) I will try to make something
>> tonight, either it will help you fix it, or I will find out what I did wrong
>>
>> On 8 October 2017 at 09:49, Daniel Dunbar 
>> wrote:
>>
>>> Is it possible for you to make a small test package that shows the
>>> problem, and file a bug in bugs.swift.org? There may be something we
>>> need to fix in SwiftPM before this can work (because of our linking model).
>>>
>>>  - Daniel
>>>
>>>
>>> On Oct 7, 2017, at 10:42 PM, Ján Kosa via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> That is exactly what I did. The only package that depends on the
>>> protobuf is the PluginInterface. Both MyPlugin and and PluginConsumer
>>> depend on the PluginInterface and not on the protobuf itself. I had to
>>> shuffle around my dependencies a bit, which resulted in smaller number of
>>> dependencies but they don't make much sense now (as in, some target had to
>>> depend on PluginInterface even if they don't need to, just to get access to
>>> protobuf). I could live with that if it solved the issue, but it didn't.
>>>
>>> I am adding my Package.swift files in case I missed something:
>>>
>>> PluginInterface:
>>>
>>> ```swift
>>> let package = Package(
>>>
>>> name: "PluginInterface",
>>>
>>> products: [ .library(name: "PluginInterface", type: .dynamic, targets: [
>>> "PluginInterface"]) ],
>>>
>>> dependencies: [ .package(url: "https://github.com/apple/swif
>>> t-protobuf.git", from: "0.0.0") ],
>>>
>>> targets: [ .target(name: "PluginInterface", dependencies: [
>>> "SwiftProtobuf"]) ]
>>>
>>> )```
>>>
>>>
>>> MyPlugin:
>>>
>>> ```swift
>>>
>>> let package = Package(
>>>
>>> name: "MyPlugin",
>>>
>>> products: [ .library(name: "MyPlugin", type: .dynamic, targets: [
>>> "PluginImpl"]) ],
>>>
>>> dependencies: [
>>>
>>> .package(url: "path/to/PluginInterface.git", from: "0.0.0"),
>>>
>>> ],
>>>
>>> targets: [
>>>
>>> .target(name: "PluginImpl", dependencies: ["ProtoBufMessages"]),
>>>
>>> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>>>
>>> ]
>>>
>>> )```
>>>
>>>
>>> PluginConsumer:
>>>
>>> ```swift
>>>
>>> let package = Package(
>>>
>>> name: "PluginConsumer",
>>>
>>> dependencies: [
>>>
>>> .package(url: "https://github.com/PerfectlySoft/Perfect-WebSockets.git";,
>>> from: "3.0.0"),
>>>
>>> .package(url: "https://github.com/PerfectlySoft/Perfect-HTTPServer.git";,
>>> from: "3.0.0"),
>>>
>>> .package(url: "path/to/PluginInterface", from: "0.0.0"),
>>>
>>> .package(url: "https://github.com/krzyzanowskim/CryptoSwift.git";, from:
>>> "0.0.0")
>>>
>>> ],
>>>
>>> targets: [
>>>
>>> .target(name: "AppMaster", dependencies: ["Shared", "CryptoSwift"]),
>>>
>>> .target(name: "PluginConsumer", dependencies: ["Shared", "CryptoSwift"
>>> ]),
>>>
>>> .target(name: "Shared", dependencies: ["ProtoBufMessages",
>>> "PerfectHTTPServer", "PerfectWebSockets"]),
>>>
>>> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>>>
>>> ]
>>>
>>> )```
>>>
>>>
>>> App master is separate executable that shares some functionality with
>>> PluginConsumer, but it doesn't link against it in any way. I guess it could
>>> be omitted, but I wanted to give you whole thing as it is
>>>
>>> On 7 October 2017 at 18:33, Geordie Jay  wrote:
>>>

 Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 15:27:

> I tried to use @_exported and it helped somewhat. While I still have
> same warnings, size of the PluginInterface library went down by 6mb (to
> 120kb) so it looks like Proto

[swift-users] Question about typo fixes on the Swift website.

2017-10-08 Thread Mayur Dhaka via swift-users 
Hello,

I recently came across a couple of typos in the ‘Contributing’ document on 
Swift.org . I wanted to know what the preferred place to 
raise these issues might be? 

Thanks for your time.
— Mayur___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Communicating with dynamically loaded swift library

2017-10-08 Thread Ján Kosa via swift-users 
Hey guys,

I have been able to create simplest possible setup that exhibits this
problem, the protobuf module wasn't necessary. All I import is
PluginInterface and I get the error:

objc[66212]: Class _TtC15PluginInterface15PluginInterface is implemented in
both
/Users/Lope/Dev/swift/SwiftPlugins/PluginConsumer/.build/x86_64-apple-macosx10.10/debug/libPluginInterface.dylib
(0x10fc7b668) and
/Users/Lope/Dev/swift/SwiftPlugins/PluginImplementation/.build/x86_64-apple-macosx10.10/debug/libPluginInterface.dylib
(0x1107dd668). One of the two will be used. Which one is undefined.


You can find modules on my github:

https://github.com/Lopdo/SwiftPlugins-PluginInterface

https://github.com/Lopdo/SwiftPlugins-PluginImplementation

https://github.com/Lopdo/SwiftPlugins-PluginConsumer


Could you have a quick look if I didn't mess up or missed something and I
will create bug report. If you want to run the code for yourself, you will
have to change the path to dylib in the PluginConsumer (I don't know how to
use relative path and didn't have time to find out yet)

On 8 October 2017 at 09:51, Ján Kosa via swift-users 
wrote:

> I was afraid it will come to that :) I will try to make something tonight,
> either it will help you fix it, or I will find out what I did wrong
>
> On 8 October 2017 at 09:49, Daniel Dunbar  wrote:
>
>> Is it possible for you to make a small test package that shows the
>> problem, and file a bug in bugs.swift.org? There may be something we
>> need to fix in SwiftPM before this can work (because of our linking model).
>>
>>  - Daniel
>>
>>
>> On Oct 7, 2017, at 10:42 PM, Ján Kosa via swift-users <
>> swift-users@swift.org> wrote:
>>
>> That is exactly what I did. The only package that depends on the protobuf
>> is the PluginInterface. Both MyPlugin and and PluginConsumer depend on the
>> PluginInterface and not on the protobuf itself. I had to shuffle around my
>> dependencies a bit, which resulted in smaller number of dependencies but
>> they don't make much sense now (as in, some target had to depend on
>> PluginInterface even if they don't need to, just to get access to
>> protobuf). I could live with that if it solved the issue, but it didn't.
>>
>> I am adding my Package.swift files in case I missed something:
>>
>> PluginInterface:
>>
>> ```swift
>> let package = Package(
>>
>> name: "PluginInterface",
>>
>> products: [ .library(name: "PluginInterface", type: .dynamic, targets: [
>> "PluginInterface"]) ],
>>
>> dependencies: [ .package(url: "https://github.com/apple/swif
>> t-protobuf.git", from: "0.0.0") ],
>>
>> targets: [ .target(name: "PluginInterface", dependencies: [
>> "SwiftProtobuf"]) ]
>>
>> )```
>>
>>
>> MyPlugin:
>>
>> ```swift
>>
>> let package = Package(
>>
>> name: "MyPlugin",
>>
>> products: [ .library(name: "MyPlugin", type: .dynamic, targets: [
>> "PluginImpl"]) ],
>>
>> dependencies: [
>>
>> .package(url: "path/to/PluginInterface.git", from: "0.0.0"),
>>
>> ],
>>
>> targets: [
>>
>> .target(name: "PluginImpl", dependencies: ["ProtoBufMessages"]),
>>
>> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>>
>> ]
>>
>> )```
>>
>>
>> PluginConsumer:
>>
>> ```swift
>>
>> let package = Package(
>>
>> name: "PluginConsumer",
>>
>> dependencies: [
>>
>> .package(url: "https://github.com/PerfectlySoft/Perfect-WebSockets.git";,
>> from: "3.0.0"),
>>
>> .package(url: "https://github.com/PerfectlySoft/Perfect-HTTPServer.git";,
>> from: "3.0.0"),
>>
>> .package(url: "path/to/PluginInterface", from: "0.0.0"),
>>
>> .package(url: "https://github.com/krzyzanowskim/CryptoSwift.git";, from:
>> "0.0.0")
>>
>> ],
>>
>> targets: [
>>
>> .target(name: "AppMaster", dependencies: ["Shared", "CryptoSwift"]),
>>
>> .target(name: "PluginConsumer", dependencies: ["Shared", "CryptoSwift"]),
>>
>> .target(name: "Shared", dependencies: ["ProtoBufMessages",
>> "PerfectHTTPServer", "PerfectWebSockets"]),
>>
>> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>>
>> ]
>>
>> )```
>>
>>
>> App master is separate executable that shares some functionality with
>> PluginConsumer, but it doesn't link against it in any way. I guess it could
>> be omitted, but I wanted to give you whole thing as it is
>>
>> On 7 October 2017 at 18:33, Geordie Jay  wrote:
>>
>>>
>>> Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 15:27:
>>>
 I tried to use @_exported and it helped somewhat. While I still have
 same warnings, size of the PluginInterface library went down by 6mb (to
 120kb) so it looks like Protobuf is no longer statically linked to it.
 However, size of PluginConsumer executable went up by same 6mb, it looks
 like it is linked there twice now.

>>>
>>> To be clear: take protobuf out of the PluginConsumer dependencies.
>>> Actually, I’m not sure which is which, but protobuf should only be listed
>>> as a dependency of one package, where it is imported as @_exported. After
>>> that, your other modules depend on the package that imports / exports
>>> protobuf.
>