Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

2016-12-14 Thread Jeremy Pereira via swift-evolution
The Swift compiler can give you the information that you want. Here is what you can do: Write a Swift source file that creates an instance of the type you want to test and then tries to access each of the private members. Write a shell script to compile this source file i a module with the fi

[swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

2016-12-14 Thread Davide Mendolia via swift-evolution
Hi, Maybe this has been asked before but I couldn't find it. I would like to be able to give visibility of non-generic subclass of a generic class to obj-c. Is there any limitation of the compiler knowing that the type of the non-generic type is closed, to generate a compatible version for obj-c?

[swift-evolution] Installing and Packaging Swift

2016-12-14 Thread Kyle Fuller via swift-evolution
Hi, I've been thinking a lot about the experience building and installing Swift from source and being able to package Swift (such as providing packages in systems such as emerge, pacman, rpm, apt-get, homebrew, etc). As it is, the current process of building and installing Swift from source isn't

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

2016-12-14 Thread Charlie Monroe via swift-evolution
Hi Davide, AFAIK this is not (easily) possible (please, correct me someone if I'm wrong) since Swift's generics aren't "lightweight" as ObjC generics are. In ObjC, no matter what you use for the generics, you still have just 1 class that handles all call: @interface MyClass : NSObject @end @c

Re: [swift-evolution] It's the little things..

2016-12-14 Thread Jordan Rose via swift-evolution
> On Dec 13, 2016, at 20:43, David Sweeris via swift-evolution > wrote: > >> >> On Dec 13, 2016, at 9:51 AM, Chris Lattner > > wrote: >> >> On Dec 12, 2016, at 6:58 PM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: On Dec 12, 2

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

2016-12-14 Thread Jordan Rose via swift-evolution
Right. Even though the class you want to expose isn't generic, its superclass is, and Objective-C needs to know the whole inheritance chain in order to use the class in any meaningful way. Depending on what your use case is, you may be able to work with a @objc protocol instead (either imported

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

2016-12-14 Thread Davide Mendolia via swift-evolution
Ok, I understand. But my use case is adding functionality to obj-c class provided by the ios sdk through generics. As I see it's not something possible, I will go for an implementation that's it's not checking the type through generic at compile time. On Wed, Dec 14, 2016 at 6:56 PM Jordan Rose w

Re: [swift-evolution] It's the little things..

2016-12-14 Thread David Sweeris via swift-evolution
> On Dec 14, 2016, at 09:54, Jordan Rose wrote: > > >>> On Dec 13, 2016, at 20:43, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Dec 13, 2016, at 9:51 AM, Chris Lattner wrote: >>> >>> On Dec 12, 2016, at 6:58 PM, David Sweeris via swift-evolution >>> wrote: > On Dec 12

Re: [swift-evolution] It's the little things..

2016-12-14 Thread Hooman Mehr via swift-evolution
> On Dec 14, 2016, at 11:08 AM, David Sweeris via swift-evolution > wrote: > I'll be curious as to how they propose we prevent collisions between > Optional.none.hashValue and any given T's hash value. It is a hash, collision is fine. It is just a single value. I guess a hashValue of zero w

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

2016-12-14 Thread Kevin Ballard via swift-evolution
On Fri, Dec 9, 2016, at 11:50 AM, Dave Abrahams via swift-evolution wrote: > > on Fri Dec 09 2016, Andrew Trick wrote: > > >> On Dec 9, 2016, at 10:27 AM, Dave Abrahams via swift-evolution > > wrote: > >> > >> > >> on Thu Dec 08 2016, Xiaodi Wu >> > wrote: > >

[swift-evolution] [Pitch] Changing NSObject dispatch behavior

2016-12-14 Thread Brian King via swift-evolution
I wanted to follow up to a blog post I wrote about Message Dispatch in Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I mentioned some changes to NSObject that didn’t result in any objections, so I thought it was time to see what the SE mailing list thought. I’ve read a few co

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

2016-12-14 Thread Kevin Ballard via swift-evolution
Please no. Just because I have to subclass NSObject doesn't mean I want to discard the performance benefits of static dispatch, and it especially doesn't mean I want to actually change the semantics of method resolution. Taking an existing Swift class and changing its base class to NSObject shou

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

2016-12-14 Thread Brian King via swift-evolution
> Please no. Just because I have to subclass NSObject doesn't mean I want to > discard the performance benefits of static dispatch, and it especially > doesn't mean I want to actually change the semantics of method resolution. > Taking an existing Swift class and changing its base class to NSObj

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

2016-12-14 Thread Kevin Ballard via swift-evolution
On Wed, Dec 14, 2016, at 05:54 PM, Brian King wrote: > > Please no. Just because I have to subclass NSObject doesn't mean I want to > > discard the performance benefits of static dispatch, and it especially > > doesn't mean I want to actually change the semantics of method resolution. > > Taking

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

2016-12-14 Thread Derrick Ho via swift-evolution
Swift generics are swift only Objective-c lightweight generics are not true generics but rather just annotation that helps with interoperability. Even though you are subclassing a generic class into a supposed non-generic type it is still a generic. Inheritance follows an is-a relationship and th

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

2016-12-14 Thread Derrick Ho via swift-evolution
You might be able to ensure access modifiers by using protocols. If you want to ensure that a class has a property called foo that is private you can make a private protocol that specifies a private property called foo. This isn't a XCTest but it is a compile time check. If a programmer tries to

[swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

2016-12-14 Thread Charles Srstka via swift-evolution
MOTIVATION: Many Cocoa classes which allow the user to choose from a list of items, such as NSPopUpButton, NSSegmentedControl, and NSTabView, offer the ability to bind the view to an integer or string in the model via KVO, through bindings such as “Selected Tag”, “Selected Index”, “Selected Ide

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

2016-12-14 Thread Benjamin Spratling via swift-evolution
Howdy, Thanks, I’ll consider this as an alternative. I don’t see that this solves the issues of whether a property on a class is let, however. -Ben > On Dec 14, 2016, at 11:41 PM, Derrick Ho wrote: > > You might be able to ensure access modifiers by using protocols. > > If you

Re: [swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

2016-12-14 Thread Derrick Ho via swift-evolution
You can currently access swift enums from objective c provided that it is marked @objc and inherits from Int. Objectivec can not however access a swift enum that inherits from a string. I've asked the community about how they feel about enabling this but there was little to no response. On Thu, De

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

2016-12-14 Thread Derrick Ho via swift-evolution
Use protocols {get} Can be used for let {get set} Can be used for var On Thu, Dec 15, 2016 at 1:16 AM Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Howdy, > Thanks, I’ll consider this as an alternative. > I don’t see that this solves the issues of w

Re: [swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

2016-12-14 Thread Charles Srstka via swift-evolution
> On Dec 15, 2016, at 12:16 AM, Derrick Ho wrote: > > You can currently access swift enums from objective c provided that it is > marked @objc and inherits from Int. Not when I try it: enum MyEnum: Int { case foo = 0 case bar = 1 } @objc var myEnum: MyEnum = .foo // Property canno

Re: [swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

2016-12-14 Thread Charlie Monroe via swift-evolution
> On Dec 15, 2016, at 7:28 AM, Charles Srstka via swift-evolution > wrote: > >> On Dec 15, 2016, at 12:16 AM, Derrick Ho > > wrote: >> >> You can currently access swift enums from objective c provided that it is >> marked @objc and inherits from Int. > > Not when

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

2016-12-14 Thread Benjamin Spratling via swift-evolution
Howdy, Do you see this working with the package manager as well? -Ben > On Dec 14, 2016, at 7:42 AM, Jeremy Pereira > wrote: > > The Swift compiler can give you the information that you want. > > Here is what you can do: > > Write a Swift source file that creates an instance of the t