Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Greg Parker via swift-evolution]

> On Nov 15, 2016, at 6:42 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In Objective-C, asking whether or not an object conforms to a protocol just 
>> cascades in to a bunch of calls to “respondsToSelector”, so it’s also very 
>> painful.
> 
> This isn’t true; Objective-C stores a list of protocols that a class conforms 
> to, so -respondsToSelector: does not need to be called when checking protocol 
> conformance (also: simply adopting a protocol’s methods will not cause a 
> class to conform to the protocol).

That's right. -conformsToProtocol: asks "does the class implementation (or some 
superclass thereof or category thereon) claim to conform to the protocol?" The 
class's method lists are not consulted.

This affects the result of -conformsToProtocol: with a protocol whose methods 
are all optional. Devolving to selector checks would say that all classes 
conform to that protocol. Honoring declared conformances as the runtime 
actually does gives a different answer.

This also affects the result if you add required methods to a protocol without 
recompiling all of the protocol's clients. Old classes will still claim to 
conform to the protocol, even though they might not implement the protocol's 
new methods.

-conformsToProtocol: is usually slower than a single -respondsToSelector: 
check. The latter uses the runtime's method cache while the former always walks 
the protocol lists of the class and all of its superclasses. But 
-conformsToProtocol: on a flat hierarchy with few protocols can be faster than 
performing multiple -respondsToSelector: checks.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Shawn Erickson via swift-evolution]

Again my point isn't worrying about point of calling out to the delegate
but configuring my delegator to avoid a body of work or state management
that is unneeded if the delegate doesn't care about some mix of potential
delegation points. I was trying to point out things to consider for those
stating "why not just provide a default implementation that is a nop, etc."
when in fact knowing if the delegate decided to not implement something can
be helpful for some delegators.

Anyway as stated earlier sub protocols likely are good enough however I am
concerned about it degenerating into a single func per sub protocol in not
atypical situations.

-Shawn

On Tue, Nov 15, 2016 at 8:10 PM Karl  wrote:

>
> On 16 Nov 2016, at 04:37, Shawn Erickson  wrote:
>
> I think you are fixating on my talk about imp caching instead of my main
> point about setting up the state of my delegator to avoid unneeded work
> when a registered delegate hasn't implement a delegation point. It an
> unrelated topic to what is being discussed.
>
> -Shawn
>
> On Tue, Nov 15, 2016 at 5:27 PM Karl  wrote:
>
>
> On 15 Nov 2016, at 19:38, Shawn Erickson  wrote:
>
> Using sub-protocols may be sufficient and make sense... to be honest I
> haven't had the time to fully explore this space and convert some things I
> have done in objective-c to pure swift. I do wonder how often that those
> sub-protocols would degenerate into having single methods.
>
> In a nut shell it isn't atypical for a delegate to only care about
> "injecting itself" (e.g. implementing a delegate function) for a subset of
> the available delegation points leaving the others unimplemented. In the
> objective-c case the delegator can evaluate what delegation points a
> delegate implements at time of delegate registration (or more dynamically
> ... however I often did imp caching for performance reasons in some of my
> designs). This probe on delegate registration may make sense for the
> delegator if additional bookkeeping, processing, state management, or
> potentially whole code path/objects can be avoided if the delegate doesn't
> implement a delegation point(s). If the delegation points happened to be
> implemented using a default nop implementation this type of optimization
> may not be possible.
>
> In a nutshell I see and have the need for the delegator to know if the
> delegate has actually provided an implementation of their own or not so I
> can potentially leverage optimizations internal to my delegator. As a
> delegate is also nice to know clearly what I have to implement or not and
> the optional protocol member concept is one way of doing that, it would be
> nice to have something like that to help delegate implementors.
>
> I suggest mentally evaluating the delegation points of URLSession with the
> perspective of the delegator (URLSession) being able to optimize what it
> does based what it delegate has provided and implementation for. For
> example the new metrics delegation point like could optimize away book
> keeping and related processing if the delegate isn't interested.
> Additionally look at it from the point of view of a delegate implementor
> noting the despite already having some number of sub-protocols you still
> often only implement one or two delegate points. Alternate swifty
> implementations likely exist that would be interesting to explore to help
> inform what makes sense as a language addition and/or help folks used to
> "traditional" delegation pattern under Objective-C follow more Swifty
> patterns going forward.
>
> -Shawn
>
> On Tue, Nov 15, 2016 at 9:24 AM Karl  wrote:
>
>
> On 15 Nov 2016, at 16:46, Shawn Erickson  wrote:
>
> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).
> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One major example is the NS/UITableViewDataSource or Delegate - there are
> many many methods that you don't need to implement, hence are optional.
>
> But I think that this was partially solved by default implementation of
> protocol methods, which pretty much does what you want...
>
>
> I just realized I only responded to someone else, and not the whole lis

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Karl via swift-evolution]

> On 16 Nov 2016, at 03:42, Charles Srstka  wrote:
> 
>> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In Objective-C, asking whether or not an object conforms to a protocol just 
>> cascades in to a bunch of calls to “respondsToSelector”, so it’s also very 
>> painful.
> 
> This isn’t true; Objective-C stores a list of protocols that a class conforms 
> to, so -respondsToSelector: does not need to be called when checking protocol 
> conformance (also: simply adopting a protocol’s methods will not cause a 
> class to conform to the protocol).
> 
> You can test this yourself:
> 
> #import 
> 
> @protocol P
>   
> - (void)foo;
>   
> @end
> 
> @interface C: NSObject
> 
> - (void)foo;
> 
> @end
> 
> @implementation C
> 
> - (void)foo {
>   NSLog(@"foo");
> }
> 
> - (BOOL)respondsToSelector:(SEL)selector {
>   NSLog(@"respondsToSelector: called");
>   
>   return [super respondsToSelector:selector];
> }
> 
> @end
> 
> int main(int argc, char *argv[]) {
>   @autoreleasepool {
>   C *c = [C new];
>   
>   NSLog(@"C is P: %@", [c conformsToProtocol:@protocol(P)] ? 
> @"YES" : @"NO");
>   }
> }
> 
> The output is only:
> 
> C is P: YES
> 
> The log we put in -respondsToSelector: never gets printed.
> 
> Charles
> 

Huh. I’ve been using Objective-C for maybe 15 years and I’ve always avoided 
“conformsToProtocol” because I didn’t think it gave a strong contract like 
that. You learn something new every day :)

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Getting a list of protocol conformers

[Rick Mann via swift-evolution]

+1.

> On Nov 15, 2016, at 19:53 , Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to be able to get, at runtime, an array of all types conforming 
> to a particular protocol.  (Similarly, I would like to be able to get an 
> array of all subtypes of a given type).  Is this in the generics manifesto?  
> If not, can it be added?  What is the timeframe?
> 
> It seems to me, that the compiler should actually already have this 
> information, and it is just a matter of keeping it around when it is 
> requested.  I could be wrong about that though...
> 
> Why do I want this?  It would make a lot of things like plug-ins and 
> extensible factories possible (and much easier where they are possible).  For 
> example, you could add a new type to a factory (without the factory having to 
> be coupled to it) just by adhering to a protocol.  It would also make 
> building a swift version of NSCoding much easier.
> 
> I have asked for other, more complicated, language features (e.g. handler 
> funcs) to make those possible before, and I still want them (since I have 
> used them in other languages and it was enormously powerful), but I realized 
> that I should actually be able to make most of those features in a library 
> myself (albeit a bit slower than the compiler could) if I am able to get a 
> list of conforming types at runtime (and then call static methods on those 
> types).
> 
> Also, if there is a way to do this now (even if it is slow), I would 
> appreciate the help…
> 
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Karl via swift-evolution]

> On 16 Nov 2016, at 04:37, Shawn Erickson  wrote:
> 
> I think you are fixating on my talk about imp caching instead of my main 
> point about setting up the state of my delegator to avoid unneeded work when 
> a registered delegate hasn't implement a delegation point. It an unrelated 
> topic to what is being discussed.
> 
> -Shawn
> 
> On Tue, Nov 15, 2016 at 5:27 PM Karl  > wrote:
> 
>> On 15 Nov 2016, at 19:38, Shawn Erickson > > wrote:
>> 
>> Using sub-protocols may be sufficient and make sense... to be honest I 
>> haven't had the time to fully explore this space and convert some things I 
>> have done in objective-c to pure swift. I do wonder how often that those 
>> sub-protocols would degenerate into having single methods.
>> 
>> In a nut shell it isn't atypical for a delegate to only care about 
>> "injecting itself" (e.g. implementing a delegate function) for a subset of 
>> the available delegation points leaving the others unimplemented. In the 
>> objective-c case the delegator can evaluate what delegation points a 
>> delegate implements at time of delegate registration (or more dynamically 
>> ... however I often did imp caching for performance reasons in some of my 
>> designs). This probe on delegate registration may make sense for the 
>> delegator if additional bookkeeping, processing, state management, or 
>> potentially whole code path/objects can be avoided if the delegate doesn't 
>> implement a delegation point(s). If the delegation points happened to be 
>> implemented using a default nop implementation this type of optimization may 
>> not be possible.
>> 
>> In a nutshell I see and have the need for the delegator to know if the 
>> delegate has actually provided an implementation of their own or not so I 
>> can potentially leverage optimizations internal to my delegator. As a 
>> delegate is also nice to know clearly what I have to implement or not and 
>> the optional protocol member concept is one way of doing that, it would be 
>> nice to have something like that to help delegate implementors.
>> 
>> I suggest mentally evaluating the delegation points of URLSession with the 
>> perspective of the delegator (URLSession) being able to optimize what it 
>> does based what it delegate has provided and implementation for. For example 
>> the new metrics delegation point like could optimize away book keeping and 
>> related processing if the delegate isn't interested. Additionally look at it 
>> from the point of view of a delegate implementor noting the despite already 
>> having some number of sub-protocols you still often only implement one or 
>> two delegate points. Alternate swifty implementations likely exist that 
>> would be interesting to explore to help inform what makes sense as a 
>> language addition  and/or help folks used to "traditional" delegation 
>> pattern under Objective-C follow more Swifty patterns going forward.
>> 
>> -Shawn
>> 
>> On Tue, Nov 15, 2016 at 9:24 AM Karl > > wrote:
>> 
>>> On 15 Nov 2016, at 16:46, Shawn Erickson >> > wrote:
>>> 
>>> This has been discussed somewhat heavily in the past and nothing yet has 
>>> really moved forward on it. I do think a good way of doing something like 
>>> this would be helpful. I have resulted to defining an interface with an 
>>> extension that provides empty defaults and for each function a match bool 
>>> var exists to imply if it exists or not. The code accepting a delegate can 
>>> probe these bool vars to configure itself to efficiently operate based on 
>>> knowledge about what the delegate expects (some missing from most proposed 
>>> solutions other then @objc optional).
>>> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On 15 Nov 2016, at 12:22, Haravikk via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> One major example is the NS/UITableViewDataSource or Delegate - there 
>> are many many methods that you don't need to implement, hence are 
>> optional.
>> 
>> But I think that this was partially solved by default implementation of 
>> protocol methods, which pretty much does what you want...
> 
> I just realized I only responded to someone else, and not the whole list. 
> It does, but it forces me to make the return value of the protocol method 
> optional, so that the default implementation can return nil. 
> 
> In the end, I guess that's not so bad, since I'm not happy with the 
> entire approach, but it'll do for now.
 
 What's different about having the method return nil vs being opt

[swift-evolution] Getting a list of protocol conformers

[Jonathan Hull via swift-evolution]

I would like to be able to get, at runtime, an array of all types conforming to 
a particular protocol.  (Similarly, I would like to be able to get an array of 
all subtypes of a given type).  Is this in the generics manifesto?  If not, can 
it be added?  What is the timeframe?

It seems to me, that the compiler should actually already have this 
information, and it is just a matter of keeping it around when it is requested. 
 I could be wrong about that though...

Why do I want this?  It would make a lot of things like plug-ins and extensible 
factories possible (and much easier where they are possible).  For example, you 
could add a new type to a factory (without the factory having to be coupled to 
it) just by adhering to a protocol.  It would also make building a swift 
version of NSCoding much easier.

I have asked for other, more complicated, language features (e.g. handler 
funcs) to make those possible before, and I still want them (since I have used 
them in other languages and it was enormously powerful), but I realized that I 
should actually be able to make most of those features in a library myself 
(albeit a bit slower than the compiler could) if I am able to get a list of 
conforming types at runtime (and then call static methods on those types).

Also, if there is a way to do this now (even if it is slow), I would appreciate 
the help…

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Shawn Erickson via swift-evolution]

I think you are fixating on my talk about imp caching instead of my main
point about setting up the state of my delegator to avoid unneeded work
when a registered delegate hasn't implement a delegation point. It an
unrelated topic to what is being discussed.

-Shawn

On Tue, Nov 15, 2016 at 5:27 PM Karl  wrote:

>
> On 15 Nov 2016, at 19:38, Shawn Erickson  wrote:
>
> Using sub-protocols may be sufficient and make sense... to be honest I
> haven't had the time to fully explore this space and convert some things I
> have done in objective-c to pure swift. I do wonder how often that those
> sub-protocols would degenerate into having single methods.
>
> In a nut shell it isn't atypical for a delegate to only care about
> "injecting itself" (e.g. implementing a delegate function) for a subset of
> the available delegation points leaving the others unimplemented. In the
> objective-c case the delegator can evaluate what delegation points a
> delegate implements at time of delegate registration (or more dynamically
> ... however I often did imp caching for performance reasons in some of my
> designs). This probe on delegate registration may make sense for the
> delegator if additional bookkeeping, processing, state management, or
> potentially whole code path/objects can be avoided if the delegate doesn't
> implement a delegation point(s). If the delegation points happened to be
> implemented using a default nop implementation this type of optimization
> may not be possible.
>
> In a nutshell I see and have the need for the delegator to know if the
> delegate has actually provided an implementation of their own or not so I
> can potentially leverage optimizations internal to my delegator. As a
> delegate is also nice to know clearly what I have to implement or not and
> the optional protocol member concept is one way of doing that, it would be
> nice to have something like that to help delegate implementors.
>
> I suggest mentally evaluating the delegation points of URLSession with the
> perspective of the delegator (URLSession) being able to optimize what it
> does based what it delegate has provided and implementation for. For
> example the new metrics delegation point like could optimize away book
> keeping and related processing if the delegate isn't interested.
> Additionally look at it from the point of view of a delegate implementor
> noting the despite already having some number of sub-protocols you still
> often only implement one or two delegate points. Alternate swifty
> implementations likely exist that would be interesting to explore to help
> inform what makes sense as a language addition and/or help folks used to
> "traditional" delegation pattern under Objective-C follow more Swifty
> patterns going forward.
>
> -Shawn
>
> On Tue, Nov 15, 2016 at 9:24 AM Karl  wrote:
>
>
> On 15 Nov 2016, at 16:46, Shawn Erickson  wrote:
>
> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).
> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One major example is the NS/UITableViewDataSource or Delegate - there are
> many many methods that you don't need to implement, hence are optional.
>
> But I think that this was partially solved by default implementation of
> protocol methods, which pretty much does what you want...
>
>
> I just realized I only responded to someone else, and not the whole list.
> It does, but it forces me to make the return value of the protocol method
> optional, so that the default implementation can return nil.
>
> In the end, I guess that's not so bad, since I'm not happy with the entire
> approach, but it'll do for now.
>
>
> What's different about having the method return nil vs being optional?
> You're attempting to call it either way, and presumably need some means of
> handling the return value, except in Swift it's all nice and explicit and
> easy to put in a conditional like:
>
> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
> print(myObject.someOptionalStringMethod() ?? "")
>
> And so-on. If you need a method to be both optional, and return a nilable
> result then you can use a double optional like s

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Charles Srstka via swift-evolution]

> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution 
>  wrote:
> 
> In Objective-C, asking whether or not an object conforms to a protocol just 
> cascades in to a bunch of calls to “respondsToSelector”, so it’s also very 
> painful.

This isn’t true; Objective-C stores a list of protocols that a class conforms 
to, so -respondsToSelector: does not need to be called when checking protocol 
conformance (also: simply adopting a protocol’s methods will not cause a class 
to conform to the protocol).

You can test this yourself:

#import 

@protocol P

- (void)foo;

@end

@interface C: NSObject

- (void)foo;

@end

@implementation C

- (void)foo {
NSLog(@"foo");
}

- (BOOL)respondsToSelector:(SEL)selector {
NSLog(@"respondsToSelector: called");

return [super respondsToSelector:selector];
}

@end

int main(int argc, char *argv[]) {
@autoreleasepool {
C *c = [C new];

NSLog(@"C is P: %@", [c conformsToProtocol:@protocol(P)] ? 
@"YES" : @"NO");
}
}

The output is only:

C is P: YES

The log we put in -respondsToSelector: never gets printed.

Charles

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Karl via swift-evolution]

> On 15 Nov 2016, at 19:38, Shawn Erickson  wrote:
> 
> Using sub-protocols may be sufficient and make sense... to be honest I 
> haven't had the time to fully explore this space and convert some things I 
> have done in objective-c to pure swift. I do wonder how often that those 
> sub-protocols would degenerate into having single methods.
> 
> In a nut shell it isn't atypical for a delegate to only care about "injecting 
> itself" (e.g. implementing a delegate function) for a subset of the available 
> delegation points leaving the others unimplemented. In the objective-c case 
> the delegator can evaluate what delegation points a delegate implements at 
> time of delegate registration (or more dynamically ... however I often did 
> imp caching for performance reasons in some of my designs). This probe on 
> delegate registration may make sense for the delegator if additional 
> bookkeeping, processing, state management, or potentially whole code 
> path/objects can be avoided if the delegate doesn't implement a delegation 
> point(s). If the delegation points happened to be implemented using a default 
> nop implementation this type of optimization may not be possible.
> 
> In a nutshell I see and have the need for the delegator to know if the 
> delegate has actually provided an implementation of their own or not so I can 
> potentially leverage optimizations internal to my delegator. As a delegate is 
> also nice to know clearly what I have to implement or not and the optional 
> protocol member concept is one way of doing that, it would be nice to have 
> something like that to help delegate implementors.
> 
> I suggest mentally evaluating the delegation points of URLSession with the 
> perspective of the delegator (URLSession) being able to optimize what it does 
> based what it delegate has provided and implementation for. For example the 
> new metrics delegation point like could optimize away book keeping and 
> related processing if the delegate isn't interested. Additionally look at it 
> from the point of view of a delegate implementor noting the despite already 
> having some number of sub-protocols you still often only implement one or two 
> delegate points. Alternate swifty implementations likely exist that would be 
> interesting to explore to help inform what makes sense as a language addition 
>  and/or help folks used to "traditional" delegation pattern under Objective-C 
> follow more Swifty patterns going forward.
> 
> -Shawn
> 
> On Tue, Nov 15, 2016 at 9:24 AM Karl  > wrote:
> 
>> On 15 Nov 2016, at 16:46, Shawn Erickson > > wrote:
>> 
>> This has been discussed somewhat heavily in the past and nothing yet has 
>> really moved forward on it. I do think a good way of doing something like 
>> this would be helpful. I have resulted to defining an interface with an 
>> extension that provides empty defaults and for each function a match bool 
>> var exists to imply if it exists or not. The code accepting a delegate can 
>> probe these bool vars to configure itself to efficiently operate based on 
>> knowledge about what the delegate expects (some missing from most proposed 
>> solutions other then @objc optional).
>> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> One major example is the NS/UITableViewDataSource or Delegate - there are 
> many many methods that you don't need to implement, hence are optional.
> 
> But I think that this was partially solved by default implementation of 
> protocol methods, which pretty much does what you want...
 
 I just realized I only responded to someone else, and not the whole list. 
 It does, but it forces me to make the return value of the protocol method 
 optional, so that the default implementation can return nil. 
 
 In the end, I guess that's not so bad, since I'm not happy with the entire 
 approach, but it'll do for now.
>>> 
>>> What's different about having the method return nil vs being optional? 
>>> You're attempting to call it either way, and presumably need some means of 
>>> handling the return value, except in Swift it's all nice and explicit and 
>>> easy to put in a conditional like:
>>> 
>>> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>>> print(myObject.someOptionalStringMethod() ?? "")
>>> 
>>> And so-on. If you need a method to be both optional, and return a nilable 
>>> result then you can use a double optional like so:
>>> 
>>> if let result = myObject.someDoubleOptional

Re: [swift-evolution] Selector for current method

[Rudolf Adamkovič via swift-evolution]

> What I’m wondering is what you’re actually using this all for.


For example, when testing with Quick (popular testing framework), one can 
describe a function:

describe(“player.play()”) {
...
}

If #function worked like #selector, we could do:

describe(#function(Player.play())) {
...
}

This would be safe and refactoring friendly.

P.S. I could do this with #selector but that would require @objc/dynamic which 
is not ideal.

R+

> On 15 Nov 2016, at 18:02, Jordan Rose  wrote:
> 
> Sorry, I see that #function doesn’t work as a drop-in replacement for 
> #selector. What I’m wondering is what you’re actually using this all for. It 
> seems rare to have a dictionary keyed by the name of a function (but not its 
> arguments) and rarer still to need to prepopulate that dictionary. The only 
> use case I can think of is some generalized mock object, but even then I 
> wonder how useful it is in practice.
> 
> (Per the original request, remember too that many Swift methods do not have 
> selectors, since they are not exposed to Objective-C.)
> 
> Jordan
> 
> 
>> On Nov 15, 2016, at 03:47, Rudolf Adamkovič > > wrote:
>> 
>> Hi Jordan,
>> 
>>> The stripped-down code seems like it could use any unique key, including 
>>> #function.
>> 
>> 
>> That would work only if #function could be used with an argument just like 
>> #selector:
>> 
>> class DirectoryListingStub: DirectoryListing {
>> 
>>   var cannedOutput: [Selector: Any?] = [
>>   
>> #function(contentsOfDirectory(at:includingPropertiesForKeys:options:)): nil
>>   ]
>> 
>>   func contentsOfDirectory(at url: URL, includingPropertiesForKeys keys: 
>> [URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) throws 
>> -> [URL] {
>>   return cannedOutput[#function] as! [URL]
>>   }
>> 
>> }
>> 
>> Obviously, this doesn’t work as #function takes no arguments.
>> 
>> There's no way to get #selector for the current method. And there’s no way 
>> to get #function for arbitrary method.
>> 
>> R+
>> 
>>> On 14 Nov 2016, at 20:07, Jordan Rose >> > wrote:
>>> 
>>> This doesn’t seem unreasonable, but I’m not sure if that makes it 
>>> reasonable. :-) What’s your use case? The stripped-down code seems like it 
>>> could use any unique key, including #function.
>>> 
>>> Jordan
>>> 
>>> 
 On Nov 13, 2016, at 15:50, Rudolf Adamkovič via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hi there!
 
 in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd 
 like we have in Objective-C.
 
 Example:
 
 class DirectoryListingStub: DirectoryListing {
 
  var cannedOutput: [Selector: Any?] = [
  
 #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:)): nil
  ]
 
  dynamic func contentsOfDirectory(at url: URL, includingPropertiesForKeys 
 keys: [URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) 
 throws -> [URL] {
  let selector = 
 #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:))
  return cannedOutput[selector] as!  [URL]
  }
 
 }
 
 Problem: I had to specify #selector twice.
 
 I though I’d be able to use #function but:
 
 #selector = contentsOfDirectoryAt:includingPropertiesForKeys:options:error:
 #function = contentsOfDirectory(at:includingPropertiesForKeys:options:)
 
 It’d be great if #selector (without arguments) returned the current 
 selector.
 
 Or am I missing something?
 
 R+
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
> 

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Rick Mann via swift-evolution]

> On Nov 15, 2016, at 09:24 , Dave Abrahams via swift-evolution 
>  wrote:
> 
> Speaking for myself: I think “probe-a-type” programming is in general a
> bad idea, and I'm opposed to adding features that encourage it.  It's
> almost always better to design entry points into supertypes (protocols,
> or base classes if you must ;->) with default implementations that can
> be overridden to do the work you need based on the characteristics of a
> subtype, rather than trying to make decisions in the caller based on the
> shape of the type.  When you *do* need probing, it's a good idea to make
> the set of possible subtypes a closed set, so the compiler can ensure
> you handle all cases—i.e., use an enum.

(I'm re-watching your WWDC 2105 talk about protocol-oriented programming, so I 
may end up with answers to the issues below.)

The thing that prompted my original post on this subject was an exploration of 
how to best implement a CAD program. In this case, something like Illustrator, 
where you can create, manipulate, and draw various shape types. I wanted to 
separate, as much as possible, the mathematical representation of the shape 
from the drawing and manipulating, and ideally have only one set of objects 
permanently instantiated (the mathematical representations of the shapes, i.e. 
the model).

So, I have a CanvasView that has a list of these shapes (a simple array). I 
have a set of tools (generally, a single instance of each, although when each 
gets instantiated can be changed in the design). The CanvasView triggers the 
drawing and the mouse handling for the set of shapes (CanvasObjects).

I've got something like this:

protocol Renderable { func renderer() -> Renderer? }
extension Renderable { func renderer() -> Renderer? { return nil } }

protocol Selectable { var selectionState: enum SelectionState }
protocol HitTestable { func hitTest(_ inPt: CGPoitn) }

protocol CanvasObject : HitTestable, Selectable {}
class Path : CanvasObject { }

protocol Renderer { func draw(in inCTX: CGContext) }
class PathRenderer : Renderer { }

You get the idea. Stop me if I'm way off base here.

I initially wanted Renderable.renderer() to be optional. I think I'm convinced 
returning an optional Renderer is equivalent.

Drawing
---
CanvasView visits each CanvasObject in turn, instantiates an appropriate 
Renderer for the object (by calling Renderable.renderer()), calls 
Renderer.draw().

Mouse Handling
--
The currently-selected Tool is handed the mouse hit and the view. It iterates 
the objects, calling hitTest(). It then instantiates a handler based on the hit 
object type and current tool (might just be the current tool).

Problems

The CanvasView has a list of CanvasObjects, forcing all objects to conform to 
all the protocols (e.g. Renderable, Selectable, HitTestable.) That is the 
CanvasView has a view onto the set of objects as complete objects, rather than 
a view of all Renderable objects, all HitTestable objects, etc. In this app, it 
may not be meaningful to talk about objects that are only renderable, but then 
again, it might (a grid could be renderable, but not selectable or hit 
testable; in practice it'll be implemented as a completely different entity, 
not part of the set of objects).

There is a problem of state management. Shapes are drawn differently depending 
on their state (e.g. normal, hovered, selected, sub-selected, being-snapped-to, 
etc.). I see no good way to store that state, except in the core object (e.g. 
Path). Alternatively, a parallel data structure that holds that state, but now 
I have to ensure instances of associated objects can be mapped back and forth. 
In fact, as I think about this more, I think it's a better solution, because 
it's conceivable there would be multiple views of the same model data, and the 
various states might be independent per view.

And performance will probably be okay, but needs to be considered.

I'm probably just making a mountain out of a molehill, but I want to make sure 
I'm understanding Swift thoroughly.


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Chris Lattner via swift-evolution]

> On Nov 14, 2016, at 3:48 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> Will Swift ever support optional methods without @objc?
> 

We discussed this extensively in the Swift 3 timeframe, and I believe that the 
consensus was “no”: optional requirements are considered an Objective-C 
compatibility feature.

I don’t recall all of the discussion, but a major one would have to be that it 
is highly redundant with other language features we already have, and makes the 
design space of Swift APIs more complicated.  If Objective-C didn’t already 
have them, we would never consider adding them to our protocol model.

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

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Alex Blewitt via swift-evolution]

OpenVMS isn't in the supported list of Swift packages, so comparing it to that 
is pointless.

https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/lib/Basic/LangOptions.cpp#L26-L36


static const StringRef SupportedConditionalCompilationOSs[] = {
  "OSX",
  "tvOS",
  "watchOS",
  "iOS",
  "Linux",
  "FreeBSD",
  "Windows",
  "Android",
  "PS4",
};

Look, this code is already battle tested in Swift. It's even used in the test 
case for the interpreter:

https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/test/Interpreter/SDK/libc.swift#L10-L14
 




#if os(OSX) || os(iOS) || os(watchOS) || os(tvOS)
  import Darwin
#elseif os(Linux) || os(FreeBSD) || os(PS4) || os(Android)
  import Glibc
#endif

Alex

> On 15 Nov 2016, at 19:51, Drew Crawford  wrote:
> 
> Thanks for using specific examples, as they are illustrative.
> 
>> Or, as used in 
>> https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift
>>  
>> 
>>  to just get access to the exit() function, which is the same across all 
>> platforms.
> 
> 
> exit is an interesting case.  Believe it or not, it is *not* portable, as 
> used here.  The C standard defines two constants for its parameter: 
> EXIT_SUCCESS (defined to be zero) and EXIT_FAILURE (undefined).  You can pass 
> other values (trivia time: only values less than 0377, because the high bits 
> of this integer are reserved on some platforms), but the "fail-iarity" or 
> "successiness" of values other than the defined two are not specified and may 
> take on different meanings on different platforms.  C programmers commonly 
> pick a nonzero value to indicate failure (as I did here) – sometimes multiple 
> distinct values to indicate different kinds of failure – but this is actually 
> non-portable.
> 
> The reason I am being pedantic here is because it demonstrates a broader 
> point: people do not actually write portable code; they target either their 
> current platform or some vague amalgamation of  2-3 platforms in their 
> immediate vicinity.  All the platforms I cared about do something sane with 
> exit(1) so it's "portable enough".  But "portable enough" isn't portable.
> 
>>  In any case, the four lines at the top of your files are almost certainly 
>> inconsistent on other platforms; for example, do you test for freebsd? Or 
>> ps4?
> 
> This is a feature, not a bug.  We *like* compiler errors because they give us 
> early warning we got something wrong.
> 
> I *want* the compiler to stop me when compiling this for OpenVMS.  When I 
> wrote this code, I had only Darwin/Glibc in mind, and on that basis, I used 
> exit(1). The working assumption is now violated, and the compiler is correct 
> to remind me about it.  I don't know, and would need to go find out, what 
> kind of exit is sensible for VMS.  Or to move to EXIT_FAILURE like a language 
> lawyer.
> 
> But the compile error itself is not a silly annoyance that I would like to 
> "solve" by blindly putting more libcs in the list etc. This is a guard rail 
> where I indicated the platforms I had in mind when writing this code, and 
> when I wake up one morning in a drunken stupor and try to do something else, 
> we fire a warning shot.
> 
> It's a safety feature, like force-unwrap.  If you're sure it won't blow up, 
> you can put an exclamation mark in there and shut up the compiler.  If you're 
> sure it's portable to bsd, add bsd to the list and shut up the compiler.  But 
> the resolution to this compile error is not to import more libcs.  The 
> resolution is to *consider carefully if that is a good idea*.
> 
> The assumption embedded in the proposal is that of course we want the program 
> to compile, and the question is merely to calculate the set of import 
> statements that will achieve compilation, for which the proposal offers an 
> algorithm.  My argument is that actually we do not want the program to 
> compile unless we are reasonably sure it will work as intended, and the 
> question is what syntax allows the author to reasonably encode their 
> assumptions so that when they are violated we provide a moment of quiet 
> reflection to consider e.g. if exit(1) is sensible on VMS.
> 
> The existing system is imperfect (and very ugly) but does a surprisingly good 
> job in this dimension.
> 
>>  It also doesn't seem to support some of the other platforms that might be 
>> desirable in a test framework, such as iOS, watchOS or tvOS.
> 
> I do support iOS (not in this component – it's a command-line tool, so the 
> omission of iOS in this file is deliberate, and the compatibility issues go 
> far beyond exit).  I don't yet support watchOS or tvOS because I don't have 
> CI for those 

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Drew Crawford via swift-evolution]

Thanks for using specific examples, as they are illustrative.

Or, as used in 
https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift
 to just get access to the exit() function, which is the same across all 
platforms.

exit is an interesting case.  Believe it or not, it is *not* portable, as used 
here.  The C standard defines two constants for its parameter: EXIT_SUCCESS 
(defined to be zero) and EXIT_FAILURE (undefined).  You can pass other values 
(trivia time: only values less than 0377, because the high bits of this integer 
are reserved on some platforms), but the "fail-iarity" or "successiness" of 
values other than the defined two are not specified and may take on different 
meanings on different platforms.  C programmers commonly pick a nonzero value 
to indicate failure (as I did here) – sometimes multiple distinct values to 
indicate different kinds of failure – but this is actually non-portable.

The reason I am being pedantic here is because it demonstrates a broader point: 
people do not actually write portable code; they target either their current 
platform or some vague amalgamation of  2-3 platforms in their immediate 
vicinity.  All the platforms I cared about do something sane with exit(1) so 
it's "portable enough".  But "portable enough" isn't portable.

 In any case, the four lines at the top of your files are almost certainly 
inconsistent on other platforms; for example, do you test for freebsd? Or ps4?

This is a feature, not a bug.  We *like* compiler errors because they give us 
early warning we got something wrong.

I *want* the compiler to stop me when compiling this for OpenVMS.  When I wrote 
this code, I had only Darwin/Glibc in mind, and on that basis, I used exit(1). 
The working assumption is now violated, and the compiler is correct to remind 
me about it.  I don't know, and would need to go find out, what kind of exit is 
sensible for VMS.  Or to move to EXIT_FAILURE like a language lawyer.

But the compile error itself is not a silly annoyance that I would like to 
"solve" by blindly putting more libcs in the list etc. This is a guard rail 
where I indicated the platforms I had in mind when writing this code, and when 
I wake up one morning in a drunken stupor and try to do something else, we fire 
a warning shot.

It's a safety feature, like force-unwrap.  If you're sure it won't blow up, you 
can put an exclamation mark in there and shut up the compiler.  If you're sure 
it's portable to bsd, add bsd to the list and shut up the compiler.  But the 
resolution to this compile error is not to import more libcs.  The resolution 
is to *consider carefully if that is a good idea*.

The assumption embedded in the proposal is that of course we want the program 
to compile, and the question is merely to calculate the set of import 
statements that will achieve compilation, for which the proposal offers an 
algorithm.  My argument is that actually we do not want the program to compile 
unless we are reasonably sure it will work as intended, and the question is 
what syntax allows the author to reasonably encode their assumptions so that 
when they are violated we provide a moment of quiet reflection to consider e.g. 
if exit(1) is sensible on VMS.

The existing system is imperfect (and very ugly) but does a surprisingly good 
job in this dimension.

 It also doesn't seem to support some of the other platforms that might be 
desirable in a test framework, such as iOS, watchOS or tvOS.
I do support iOS (not in this component – it's a command-line tool, so the 
omission of iOS in this file is deliberate, and the compatibility issues go far 
beyond exit).  I don't yet support watchOS or tvOS because I don't have CI for 
those platforms yet and in my view supporting a platform is more than adjusting 
an import statement and wondering if it will compile.

So in summary:

1.  I would not use this feature in the cited examples

2.  I would prefer it if others did not use this feature.  When I see "import 
Glibc" at the top of a file I know what I am signing up for.  When I see 
"import libc" for all I know the developer used Windows.

Finally, this is more of a detail, but I still do not understand how this would 
be implemented for a Linux platform without Glibc, such as Arch.  The current 
proposal has 



  #if os(Linux)

      @_exported import Glibc

which is obviously not going to compile on Arch.  So if the goal is to have 
syntax that is portable the current proposal does not do it.

I do believe there is some room for a more moderate reform on the libc problem. 
 For example instead of the traditional ifdefs, we could have

import? Glibc

import? Darwin


Where the "import?" keyword imports the module if available or otherwise has no 
effect.

This preserves the majority of desireable properties discussed above (clearly 
indicates the intended libcs, provides guard rails similar to the present 
regime) while be

Re: [swift-evolution] Fwd: about protocols

[Reynaldo Aguilar Casajuana via swift-evolution]

Yes, that would be a classic factory method.
However, what I want is to take advantage of the power of protocol
extensions and use them for improving the way in which dependencies are
resolved in most classic programming languages. The current meaning of
static method/property in protocols, how much useful is it? I even think
that it is a bit ugly to let the user to add a static property directly to
a protocol via an extension, and don't let the user use that static
property via the protocol.

On Tue, Nov 15, 2016 at 1:38 PM, David Waite 
wrote:

> A static method or property on a protocol already means something separate
> - that the types which implement that protocol that static method/property.
>
> I’d recommend moving your factory method to another type or a global
> function?
>
> -DW
>
> On Nov 15, 2016, at 10:10 AM, Reynaldo Aguilar Casajuana via
> swift-evolution  wrote:
>
> Hi.
> I was thinking about a simple way of implementing the handling of
> dependencies in swift and arrived to the following solution, however,
> currently it isn't supported in swift. Can we get a way of making this work?
>
> http://stackoverflow.com/questions/40595621/getting-dependen
> cies-using-static-members-in-protocol-in-swift
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Shawn Erickson via swift-evolution]

Using sub-protocols may be sufficient and make sense... to be honest I
haven't had the time to fully explore this space and convert some things I
have done in objective-c to pure swift. I do wonder how often that those
sub-protocols would degenerate into having single methods.

In a nut shell it isn't atypical for a delegate to only care about
"injecting itself" (e.g. implementing a delegate function) for a subset of
the available delegation points leaving the others unimplemented. In the
objective-c case the delegator can evaluate what delegation points a
delegate implements at time of delegate registration (or more dynamically
... however I often did imp caching for performance reasons in some of my
designs). This probe on delegate registration may make sense for the
delegator if additional bookkeeping, processing, state management, or
potentially whole code path/objects can be avoided if the delegate doesn't
implement a delegation point(s). If the delegation points happened to be
implemented using a default nop implementation this type of optimization
may not be possible.

In a nutshell I see and have the need for the delegator to know if the
delegate has actually provided an implementation of their own or not so I
can potentially leverage optimizations internal to my delegator. As a
delegate is also nice to know clearly what I have to implement or not and
the optional protocol member concept is one way of doing that, it would be
nice to have something like that to help delegate implementors.

I suggest mentally evaluating the delegation points of URLSession with the
perspective of the delegator (URLSession) being able to optimize what it
does based what it delegate has provided and implementation for. For
example the new metrics delegation point like could optimize away book
keeping and related processing if the delegate isn't interested.
Additionally look at it from the point of view of a delegate implementor
noting the despite already having some number of sub-protocols you still
often only implement one or two delegate points. Alternate swifty
implementations likely exist that would be interesting to explore to help
inform what makes sense as a language addition and/or help folks used to
"traditional" delegation pattern under Objective-C follow more Swifty
patterns going forward.

-Shawn

On Tue, Nov 15, 2016 at 9:24 AM Karl  wrote:

>
> On 15 Nov 2016, at 16:46, Shawn Erickson  wrote:
>
> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).
> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One major example is the NS/UITableViewDataSource or Delegate - there are
> many many methods that you don't need to implement, hence are optional.
>
> But I think that this was partially solved by default implementation of
> protocol methods, which pretty much does what you want...
>
>
> I just realized I only responded to someone else, and not the whole list.
> It does, but it forces me to make the return value of the protocol method
> optional, so that the default implementation can return nil.
>
> In the end, I guess that's not so bad, since I'm not happy with the entire
> approach, but it'll do for now.
>
>
> What's different about having the method return nil vs being optional?
> You're attempting to call it either way, and presumably need some means of
> handling the return value, except in Swift it's all nice and explicit and
> easy to put in a conditional like:
>
> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
> print(myObject.someOptionalStringMethod() ?? "")
>
> And so-on. If you need a method to be both optional, and return a nilable
> result then you can use a double optional like so:
>
> if let result = myObject.someDoubleOptionalMethod() { // Method was
> implemented
> if let value = result { // Method returned a value
> /* Do some stuff */
> }
> }
>
>
> By defining the methods as returning an Optional and throwing in default
> implementations you can specify fewer, bigger protocols and make clear what
> the requirements really are, though personally given the choice I'd prefer
> a dozen smaller protocols that are abso

Re: [swift-evolution] Fwd: about protocols

[David Waite via swift-evolution]

A static method or property on a protocol already means something separate - 
that the types which implement that protocol that static method/property.

I’d recommend moving your factory method to another type or a global function?

-DW

> On Nov 15, 2016, at 10:10 AM, Reynaldo Aguilar Casajuana via swift-evolution 
>  wrote:
> 
> Hi.
> I was thinking about a simple way of implementing the handling of 
> dependencies in swift and arrived to the following solution, however, 
> currently it isn't supported in swift. Can we get a way of making this work?
> 
> http://stackoverflow.com/questions/40595621/getting-dependencies-using-static-members-in-protocol-in-swift
>  
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Fwd: about protocols

[Reynaldo Aguilar Casajuana via swift-evolution]

Hi.
I was thinking about a simple way of implementing the handling of
dependencies in swift and arrived to the following solution, however,
currently it isn't supported in swift. Can we get a way of making this work?

http://stackoverflow.com/questions/40595621/getting-
dependencies-using-static-members-in-protocol-in-swift
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Haravikk via swift-evolution]

> On 15 Nov 2016, at 14:59, Karl  wrote:
>> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> What's different about having the method return nil vs being optional? 
>> You're attempting to call it either way, and presumably need some means of 
>> handling the return value, except in Swift it's all nice and explicit and 
>> easy to put in a conditional like:
>> 
>>  if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>>  print(myObject.someOptionalStringMethod() ?? "")
>> 
>> And so-on. If you need a method to be both optional, and return a nilable 
>> result then you can use a double optional like so:
>> 
>>  if let result = myObject.someDoubleOptionalMethod() { // Method was 
>> implemented
>>  if let value = result { // Method returned a value
>>  /* Do some stuff */
>>  }
>>  }
>> 
>> 
>> By defining the methods as returning an Optional and throwing in default 
>> implementations you can specify fewer, bigger protocols and make clear what 
>> the requirements really are, though personally given the choice I'd prefer a 
>> dozen smaller protocols that are absolutely explicit in what they do.
>> 
>> But yeah, I think the tools you need are all there already; maybe there's an 
>> argument to be made for allowing default return values on protocol methods, 
>> to reduce the boiler-plate?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I think there is a difference between:
> 
> - A method which returns an optional result, and
> - An optional method which, if present, always returns a result
> 
> Perhaps not so much of a difference at the usage site (it’s just a question 
> of placing a ? for optional chaining), but semantically and when conforming 
> to the protocol, they mean different things.

Maybe, but it just seems like default implementations do everything that 
optional methods require, it's just not got a shorthand to make it easier.

Really the question is, do we adopt the optional keyword for non @objc methods, 
along with the special syntax for calling them (it's not exactly the same as 
chaining). Personally though I'd rather do the opposite and do away with both, 
and have @objc optional methods replaced by default implementations somehow.

The question then is how; simply making the methods optional (return type 
becomes optional, or more optional) is not the best solution as testing 
optionality isn't a one-size-fits-all solution. For example, API designers may 
prefer to return a method's non-implemented state with a specific int or enum 
case, or by throwing an exception or producing an error. You can do all of 
these things with default implementations.

Otherwise you could allow specifying of default return values within a protocol 
itself, functionally this would be identical to adding a default 
implementation, just a bit easier for the simplest case, I'm not sure it 
warrants special treatment though.


I mean, when it comes down to it an optional method is just one that might do 
nothing; but a default implementation that returns a default value or has no 
body achieves this just as effectively. The only advantage here is the 
call-site semantics, but you can enforce the same by having an optional return 
value if that's required.

Put another way, I don't see what's gained by the first of these two:

foo.someOptionalMethod?() // @objc optional method
foo.someMethod() // default implementation is empty

You've attempted to call both, and in both cases it just won't do anything. 
Your knowing that doesn't really change anything. Meanwhile if you have a 
return value:

if let result = foo.someOptionalMethod?() { /* Process result * / }
if let result = foo.someMethod() { /* Process result */ } // default 
implementation returns nil


If just doesn't seem like such a special case to require special treatment when 
Swift's optional support is already really good and encapsulates the same 
ideas, and the void case just needs a default implementation that's a no-op. 
Plus by using a default implementation you have more flexibility overall in how 
you actually respond when a method isn't implemented.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Selector for current method

[Timothy J. Wood via swift-evolution]

> On Nov 14, 2016, at 11:07 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> This doesn’t seem unreasonable, but I’m not sure if that makes it reasonable. 
> :-) What’s your use case? The stripped-down code seems like it could use any 
> unique key, including #function.
> 
> Jordan


One use case for bare `#selector` would be in patterns like 
NSTextViewDelegate’s -textView:doCommandBySelector:, where there are many call 
sites that need to pass the selector (and thus are open to copy-paste errors). 
I could imagine having a helper to make this less error prone and less verbose:

class SomeView : NSView {
private func validate(selector: Selector = #selector, action: (Void) -> 
Void) -> Bool {
guard checkDelegate(selector) else {
return
}
action()
}

@objc func action1(_ sender: AnyObject?) {
validate {
// do action
}
}

...

@objc func actionN(_ sender: AnyObject?) {
validate {
// do action
}
}

}

-tim

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Dave Abrahams via swift-evolution]

on Tue Nov 15 2016, Shawn Erickson  wrote:

> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).

If there are truly programming problems that don't have a clean solution
without introducing optional requirements, I'd really like to see them.

Speaking for myself: I think “probe-a-type” programming is in general a
bad idea, and I'm opposed to adding features that encourage it.  It's
almost always better to design entry points into supertypes (protocols,
or base classes if you must ;->) with default implementations that can
be overridden to do the work you need based on the characteristics of a
subtype, rather than trying to make decisions in the caller based on the
shape of the type.  When you *do* need probing, it's a good idea to make
the set of possible subtypes a closed set, so the compiler can ensure
you handle all cases—i.e., use an enum.

> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> One major example is the NS/UITableViewDataSource or Delegate - there are
>> many many methods that you don't need to implement, hence are optional.
>>
>> But I think that this was partially solved by default implementation of
>> protocol methods, which pretty much does what you want...
>>
>>
>> I just realized I only responded to someone else, and not the whole list.
>> It does, but it forces me to make the return value of the protocol method
>> optional, so that the default implementation can return nil.
>>
>> In the end, I guess that's not so bad, since I'm not happy with the entire
>> approach, but it'll do for now.
>>
>>
>> What's different about having the method return nil vs being optional?
>> You're attempting to call it either way, and presumably need some means of
>> handling the return value, except in Swift it's all nice and explicit and
>> easy to put in a conditional like:
>>
>> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>> print(myObject.someOptionalStringMethod() ?? "")
>>
>> And so-on. If you need a method to be both optional, and return a nilable
>> result then you can use a double optional like so:
>>
>> if let result = myObject.someDoubleOptionalMethod() { // Method was
>> implemented
>> if let value = result { // Method returned a value
>> /* Do some stuff */
>> }
>> }
>>
>>
>> By defining the methods as returning an Optional and throwing in default
>> implementations you can specify fewer, bigger protocols and make clear what
>> the requirements really are, though personally given the choice I'd prefer
>> a dozen smaller protocols that are absolutely explicit in what they do.
>>
>> But yeah, I think the tools you need are all there already; maybe there's
>> an argument to be made for allowing default return values on protocol
>> methods, to reduce the boiler-plate?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> I think there is a difference between:
>>
>> - A method which returns an optional result, and
>> - An optional method which, if present, always returns a result
>>
>> Perhaps not so much of a difference at the usage site (it’s just a
>> question of placing a ? for optional chaining), but semantically and when
>> conforming to the protocol, they mean different things.
>>
>> - Karl
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Karl via swift-evolution]

> On 15 Nov 2016, at 16:46, Shawn Erickson  wrote:
> 
> This has been discussed somewhat heavily in the past and nothing yet has 
> really moved forward on it. I do think a good way of doing something like 
> this would be helpful. I have resulted to defining an interface with an 
> extension that provides empty defaults and for each function a match bool var 
> exists to imply if it exists or not. The code accepting a delegate can probe 
> these bool vars to configure itself to efficiently operate based on knowledge 
> about what the delegate expects (some missing from most proposed solutions 
> other then @objc optional).
> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 One major example is the NS/UITableViewDataSource or Delegate - there are 
 many many methods that you don't need to implement, hence are optional.
 
 But I think that this was partially solved by default implementation of 
 protocol methods, which pretty much does what you want...
>>> 
>>> I just realized I only responded to someone else, and not the whole list. 
>>> It does, but it forces me to make the return value of the protocol method 
>>> optional, so that the default implementation can return nil. 
>>> 
>>> In the end, I guess that's not so bad, since I'm not happy with the entire 
>>> approach, but it'll do for now.
>> 
>> What's different about having the method return nil vs being optional? 
>> You're attempting to call it either way, and presumably need some means of 
>> handling the return value, except in Swift it's all nice and explicit and 
>> easy to put in a conditional like:
>> 
>>  if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>>  print(myObject.someOptionalStringMethod() ?? "")
>> 
>> And so-on. If you need a method to be both optional, and return a nilable 
>> result then you can use a double optional like so:
>> 
>>  if let result = myObject.someDoubleOptionalMethod() { // Method was 
>> implemented
>>  if let value = result { // Method returned a value
>>  /* Do some stuff */
>>  }
>>  }
>> 
>> 
>> By defining the methods as returning an Optional and throwing in default 
>> implementations you can specify fewer, bigger protocols and make clear what 
>> the requirements really are, though personally given the choice I'd prefer a 
>> dozen smaller protocols that are absolutely explicit in what they do.
>> 
>> But yeah, I think the tools you need are all there already; maybe there's an 
>> argument to be made for allowing default return values on protocol methods, 
>> to reduce the boiler-plate?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> I think there is a difference between:
> 
> - A method which returns an optional result, and
> - An optional method which, if present, always returns a result
> 
> Perhaps not so much of a difference at the usage site (it’s just a question 
> of placing a ? for optional chaining), but semantically and when conforming 
> to the protocol, they mean different things.
> 
> - Karl
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

If you don’t mind me asking, what is your use-case?

Even though I think "optional methods" and “methods returning optionals” are 
different things, I don’t really have any examples where optional methods are 
better than sub-protocols.

e.g.

```
// Core callbacks
protocol MyDelegate { }

// Optional callbacks, added like a mixin
protocol MyDelegateWithExtras : MyDelegate { }

// Some more optional callbacks
protocol MySubDelegate : MyDelegate {}

class DelegateImpl : MySubDelegate, MyDelegateWithExtras {
  // Implement all core + optional callbacks
}

var d : MyDelegate = DelegateImpl()

if let extras = d as? MyDelegateWithExtras {
// invoke optional functionality
}
```

I don’t know what the overhead of the as? call is, but it’s almost certainly 
less than an Obj-C `respondsToSelector` call. Depending on whether you need to 
swap the delegate for objects of different types, you could also use generics 
to optimise the checks (and possibly more) away.

- Karl___
swift

Re: [swift-evolution] Selector for current method

[Jordan Rose via swift-evolution]

Sorry, I see that #function doesn’t work as a drop-in replacement for 
#selector. What I’m wondering is what you’re actually using this all for. It 
seems rare to have a dictionary keyed by the name of a function (but not its 
arguments) and rarer still to need to prepopulate that dictionary. The only use 
case I can think of is some generalized mock object, but even then I wonder how 
useful it is in practice.

(Per the original request, remember too that many Swift methods do not have 
selectors, since they are not exposed to Objective-C.)

Jordan


> On Nov 15, 2016, at 03:47, Rudolf Adamkovič  wrote:
> 
> Hi Jordan,
> 
>> The stripped-down code seems like it could use any unique key, including 
>> #function.
> 
> 
> That would work only if #function could be used with an argument just like 
> #selector:
> 
> class DirectoryListingStub: DirectoryListing {
> 
>   var cannedOutput: [Selector: Any?] = [
>   #function(contentsOfDirectory(at:includingPropertiesForKeys:options:)): 
> nil
>   ]
> 
>   func contentsOfDirectory(at url: URL, includingPropertiesForKeys keys: 
> [URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) throws 
> -> [URL] {
>   return cannedOutput[#function] as! [URL]
>   }
> 
> }
> 
> Obviously, this doesn’t work as #function takes no arguments.
> 
> There's no way to get #selector for the current method. And there’s no way to 
> get #function for arbitrary method.
> 
> R+
> 
>> On 14 Nov 2016, at 20:07, Jordan Rose  wrote:
>> 
>> This doesn’t seem unreasonable, but I’m not sure if that makes it 
>> reasonable. :-) What’s your use case? The stripped-down code seems like it 
>> could use any unique key, including #function.
>> 
>> Jordan
>> 
>> 
>>> On Nov 13, 2016, at 15:50, Rudolf Adamkovič via swift-evolution 
>>>  wrote:
>>> 
>>> Hi there!
>>> 
>>> in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd 
>>> like we have in Objective-C.
>>> 
>>> Example:
>>> 
>>> class DirectoryListingStub: DirectoryListing {
>>> 
>>>  var cannedOutput: [Selector: Any?] = [
>>>  
>>> #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:)): nil
>>>  ]
>>> 
>>>  dynamic func contentsOfDirectory(at url: URL, includingPropertiesForKeys 
>>> keys: [URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) 
>>> throws -> [URL] {
>>>  let selector = 
>>> #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:))
>>>  return cannedOutput[selector] as!  [URL]
>>>  }
>>> 
>>> }
>>> 
>>> Problem: I had to specify #selector twice.
>>> 
>>> I though I’d be able to use #function but:
>>> 
>>> #selector = contentsOfDirectoryAt:includingPropertiesForKeys:options:error:
>>> #function = contentsOfDirectory(at:includingPropertiesForKeys:options:)
>>> 
>>> It’d be great if #selector (without arguments) returned the current 
>>> selector.
>>> 
>>> Or am I missing something?
>>> 
>>> R+
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

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

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Alex Blewitt via swift-evolution]

> On 11 Nov 2016, at 03:48, Drew Crawford  wrote:
> 
> grep -R "import Glibc" ~/Code --include "*.swift" | wc -l
> 297
> 
> As someone who might be characterized as suffering from the problem this 
> proposal purports to solve, I am not convinced.
> 
> The primary problem here is that "libc" is a misnomer.  Did you mean musl, 
> dietlibc, or glibc?  Did you mean "whatever libc my distro likes?"  Swift in 
> practice only supports one per platform, but that is a bug not a feature, and 
> that bug should not be standardized.  We could try to invent some syntax to 
> specify one but now we are back with the current system again.

We're at the current system to start off with, though. When you do "import 
Darwin" or "import GlibC" you're getting whatever the platform has, regardless 
of what you call it. You could call it something else, like "Platform" or 
"Base" but it doesn't change the suggestion itself.

> The other problem is that in all my usages, "import Glibc" is not a real 
> problem I face.  The real problems are that "the libcs plural" are *just 
> different*.  Darwin has timeval64, glibc does not, and you'd better check 
> your arch and pick the right one, only on one platform.  SO_REUSEADDR has one 
> type in Brand X and another type in Brand Y.  Don't even get me *started* on 
> poll, EREs, or half a dozen other behavioral variations.  

Yes, these are issues. Some of them will be worked out with the swift server 
workgroup, or at least standardising Socket as a type which abstracts the 
platform away. But we're at that position at the moment, whether or not there's 
a standard module to represent Darwin/Glibc.

> Taking two different libraries and pretending they are the same is not the 
> solution, it's the disease.  The way out of this swamp for most developers is 
> to use a real Swift library, the same damn Swift library, on all platforms 
> (sadly, Foundation today does not meet this requirement).  The way out of 
> this swamp for crazy people like me who must write to the metal is to 
> actually write to the metal, to the particular libc being targeted, not to a 
> hypothetical platonic ideal libc which does not exist.  
> 
> I realize that four lines at the top of my files is a *visible* annoyance, 
> but fixing it just promotes it to an invisible one. 

Not necessarily, it can be a starting point to fix some of the other problems. 
In any case, the four lines at the top of your files are almost certainly 
inconsistent on other platforms; for example, do you test for freebsd? Or ps4?

https://github.com/drewcrawford/Caroline/blob/26cd0d71e57a62fac6258e4e13dfd6849a1945c6/caroline-static-tool/FileUtils.swift
 



#if os(OSX)
import Darwin
#elseif os(Linux)
import Glibc
#endif

So your test framework doesn't work on FreeBSD by default. Yet they've still 
got the same 'write' method. It also doesn't seem to support some of the other 
platforms that might be desirable in a test framework, such as iOS, watchOS or 
tvOS. You'll just get silent errors on those when it's used on those platforms. 
And as new platforms get added, your code will slowly drift further away from 
supporting everything to supporting a few known values.

Now granted, some of these may have yet more incompatible versions for 'write' 
which needs handling specifically. That's bad, and it should be something that 
can be worked on. But most of the other functions (like 'close') don't need 
handling specifically. Or, as used in 
https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift
 

 to just get access to the exit() function, which is the same across all 
platforms.

Other proposals - such as Johannes' treatment of how to handle errno - will 
help work around these problems. Perhaps we end up with a generic write 
function that wraps the platform specific one to abstract that away as well, 
which reduces these issues one by one.

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Shawn Erickson via swift-evolution]

Note you can also use a protocol of optional methods to do the same things
as the var... I for now haven't done it that way.

On Tue, Nov 15, 2016 at 7:46 AM Shawn Erickson  wrote:

> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).
> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One major example is the NS/UITableViewDataSource or Delegate - there are
> many many methods that you don't need to implement, hence are optional.
>
> But I think that this was partially solved by default implementation of
> protocol methods, which pretty much does what you want...
>
>
> I just realized I only responded to someone else, and not the whole list.
> It does, but it forces me to make the return value of the protocol method
> optional, so that the default implementation can return nil.
>
> In the end, I guess that's not so bad, since I'm not happy with the entire
> approach, but it'll do for now.
>
>
> What's different about having the method return nil vs being optional?
> You're attempting to call it either way, and presumably need some means of
> handling the return value, except in Swift it's all nice and explicit and
> easy to put in a conditional like:
>
> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
> print(myObject.someOptionalStringMethod() ?? "")
>
> And so-on. If you need a method to be both optional, and return a nilable
> result then you can use a double optional like so:
>
> if let result = myObject.someDoubleOptionalMethod() { // Method was
> implemented
> if let value = result { // Method returned a value
> /* Do some stuff */
> }
> }
>
>
> By defining the methods as returning an Optional and throwing in default
> implementations you can specify fewer, bigger protocols and make clear what
> the requirements really are, though personally given the choice I'd prefer
> a dozen smaller protocols that are absolutely explicit in what they do.
>
> But yeah, I think the tools you need are all there already; maybe there's
> an argument to be made for allowing default return values on protocol
> methods, to reduce the boiler-plate?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I think there is a difference between:
>
> - A method which returns an optional result, and
> - An optional method which, if present, always returns a result
>
> Perhaps not so much of a difference at the usage site (it’s just a
> question of placing a ? for optional chaining), but semantically and when
> conforming to the protocol, they mean different things.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Shawn Erickson via swift-evolution]

This has been discussed somewhat heavily in the past and nothing yet has
really moved forward on it. I do think a good way of doing something like
this would be helpful. I have resulted to defining an interface with an
extension that provides empty defaults and for each function a match bool
var exists to imply if it exists or not. The code accepting a delegate can
probe these bool vars to configure itself to efficiently operate based on
knowledge about what the delegate expects (some missing from most proposed
solutions other then @objc optional).
On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One major example is the NS/UITableViewDataSource or Delegate - there are
> many many methods that you don't need to implement, hence are optional.
>
> But I think that this was partially solved by default implementation of
> protocol methods, which pretty much does what you want...
>
>
> I just realized I only responded to someone else, and not the whole list.
> It does, but it forces me to make the return value of the protocol method
> optional, so that the default implementation can return nil.
>
> In the end, I guess that's not so bad, since I'm not happy with the entire
> approach, but it'll do for now.
>
>
> What's different about having the method return nil vs being optional?
> You're attempting to call it either way, and presumably need some means of
> handling the return value, except in Swift it's all nice and explicit and
> easy to put in a conditional like:
>
> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
> print(myObject.someOptionalStringMethod() ?? "")
>
> And so-on. If you need a method to be both optional, and return a nilable
> result then you can use a double optional like so:
>
> if let result = myObject.someDoubleOptionalMethod() { // Method was
> implemented
> if let value = result { // Method returned a value
> /* Do some stuff */
> }
> }
>
>
> By defining the methods as returning an Optional and throwing in default
> implementations you can specify fewer, bigger protocols and make clear what
> the requirements really are, though personally given the choice I'd prefer
> a dozen smaller protocols that are absolutely explicit in what they do.
>
> But yeah, I think the tools you need are all there already; maybe there's
> an argument to be made for allowing default return values on protocol
> methods, to reduce the boiler-plate?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I think there is a difference between:
>
> - A method which returns an optional result, and
> - An optional method which, if present, always returns a result
>
> Perhaps not so much of a difference at the usage site (it’s just a
> question of placing a ? for optional chaining), but semantically and when
> conforming to the protocol, they mean different things.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Karl via swift-evolution]

> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> One major example is the NS/UITableViewDataSource or Delegate - there are 
>>> many many methods that you don't need to implement, hence are optional.
>>> 
>>> But I think that this was partially solved by default implementation of 
>>> protocol methods, which pretty much does what you want...
>> 
>> I just realized I only responded to someone else, and not the whole list. It 
>> does, but it forces me to make the return value of the protocol method 
>> optional, so that the default implementation can return nil. 
>> 
>> In the end, I guess that's not so bad, since I'm not happy with the entire 
>> approach, but it'll do for now.
> 
> What's different about having the method return nil vs being optional? You're 
> attempting to call it either way, and presumably need some means of handling 
> the return value, except in Swift it's all nice and explicit and easy to put 
> in a conditional like:
> 
>   if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>   print(myObject.someOptionalStringMethod() ?? "")
> 
> And so-on. If you need a method to be both optional, and return a nilable 
> result then you can use a double optional like so:
> 
>   if let result = myObject.someDoubleOptionalMethod() { // Method was 
> implemented
>   if let value = result { // Method returned a value
>   /* Do some stuff */
>   }
>   }
> 
> 
> By defining the methods as returning an Optional and throwing in default 
> implementations you can specify fewer, bigger protocols and make clear what 
> the requirements really are, though personally given the choice I'd prefer a 
> dozen smaller protocols that are absolutely explicit in what they do.
> 
> But yeah, I think the tools you need are all there already; maybe there's an 
> argument to be made for allowing default return values on protocol methods, 
> to reduce the boiler-plate?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I think there is a difference between:

- A method which returns an optional result, and
- An optional method which, if present, always returns a result

Perhaps not so much of a difference at the usage site (it’s just a question of 
placing a ? for optional chaining), but semantically and when conforming to the 
protocol, they mean different things.

- Karl

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

Re: [swift-evolution] Selector for current method

[Rudolf Adamkovič via swift-evolution]

Hi Jordan,

> The stripped-down code seems like it could use any unique key, including 
> #function.


That would work only if #function could be used with an argument just like 
#selector:

class DirectoryListingStub: DirectoryListing {

   var cannedOutput: [Selector: Any?] = [
   #function(contentsOfDirectory(at:includingPropertiesForKeys:options:)): 
nil
   ]

   func contentsOfDirectory(at url: URL, includingPropertiesForKeys keys: 
[URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) throws -> 
[URL] {
   return cannedOutput[#function] as! [URL]
   }

}

Obviously, this doesn’t work as #function takes no arguments.

There's no way to get #selector for the current method. And there’s no way to 
get #function for arbitrary method.

R+

> On 14 Nov 2016, at 20:07, Jordan Rose  wrote:
> 
> This doesn’t seem unreasonable, but I’m not sure if that makes it reasonable. 
> :-) What’s your use case? The stripped-down code seems like it could use any 
> unique key, including #function.
> 
> Jordan
> 
> 
>> On Nov 13, 2016, at 15:50, Rudolf Adamkovič via swift-evolution 
>>  wrote:
>> 
>> Hi there!
>> 
>> in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd 
>> like we have in Objective-C.
>> 
>> Example:
>> 
>> class DirectoryListingStub: DirectoryListing {
>> 
>>   var cannedOutput: [Selector: Any?] = [
>>   
>> #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:)): nil
>>   ]
>> 
>>   dynamic func contentsOfDirectory(at url: URL, includingPropertiesForKeys 
>> keys: [URLResourceKey]?, options: FileManager.DirectoryEnumerationOptions) 
>> throws -> [URL] {
>>   let selector = 
>> #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:))
>>   return cannedOutput[selector] as!  [URL]
>>   }
>> 
>> }
>> 
>> Problem: I had to specify #selector twice.
>> 
>> I though I’d be able to use #function but:
>> 
>> #selector = contentsOfDirectoryAt:includingPropertiesForKeys:options:error:
>> #function = contentsOfDirectory(at:includingPropertiesForKeys:options:)
>> 
>> It’d be great if #selector (without arguments) returned the current selector.
>> 
>> Or am I missing something?
>> 
>> R+
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Haravikk via swift-evolution]

> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution 
>  wrote:
> 
> 
>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> One major example is the NS/UITableViewDataSource or Delegate - there are 
>> many many methods that you don't need to implement, hence are optional.
>> 
>> But I think that this was partially solved by default implementation of 
>> protocol methods, which pretty much does what you want...
> 
> I just realized I only responded to someone else, and not the whole list. It 
> does, but it forces me to make the return value of the protocol method 
> optional, so that the default implementation can return nil. 
> 
> In the end, I guess that's not so bad, since I'm not happy with the entire 
> approach, but it'll do for now.

What's different about having the method return nil vs being optional? You're 
attempting to call it either way, and presumably need some means of handling 
the return value, except in Swift it's all nice and explicit and easy to put in 
a conditional like:

if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
print(myObject.someOptionalStringMethod() ?? "")

And so-on. If you need a method to be both optional, and return a nilable 
result then you can use a double optional like so:

if let result = myObject.someDoubleOptionalMethod() { // Method was 
implemented
if let value = result { // Method returned a value
/* Do some stuff */
}
}


By defining the methods as returning an Optional and throwing in default 
implementations you can specify fewer, bigger protocols and make clear what the 
requirements really are, though personally given the choice I'd prefer a dozen 
smaller protocols that are absolutely explicit in what they do.

But yeah, I think the tools you need are all there already; maybe there's an 
argument to be made for allowing default return values on protocol methods, to 
reduce the boiler-plate?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Type Narrowing

[Haravikk via swift-evolution]

> On 15 Nov 2016, at 07:19, Jean-Daniel  wrote:
>> Le 14 nov. 2016 à 10:10, Haravikk > > a écrit :
>>> On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
 Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution 
 mailto:swift-evolution@swift.org>> a écrit :
 
 That's a good point in Jay's example and from what I can tell a good way 
 to address it, Haravikk. 
 
 I've done some work in a language that only provides type narrowing for 
 immutable types (that'd be Kotlin as I've mentioned before) and whenever 
 I've used it it feels like the only thing it's really been missing is the 
 "if let" construct allowing you to bind and unwrap mutable values, which 
 leads me to think that synergistically, in Swift, this would be fantastic. 
 The main benefit probably is that it would allow code to read much better.
>>> 
>>> IMHO, the Kotlin solution is flaw. The fact that type narrowing does not 
>>> works for var and that there is no simple way to unwrap optional just force 
>>> the developer either to introduce local variable, or to use the force 
>>> unwrap operator.
>>> Moreover, introducing a unwrap syntax (if let) like in swift would just 
>>> result in having 2 different and inconsistent way to do the same thing.
>> 
>> I'll have to take a closer look at how Kotlin does this when I get a chance, 
>> but how would this affect the two proposals as they currently stand?
>> 
>> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-type-narrowing.md
>>  
>> 
>> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-optional-unwrapping.md
>>  
>> 
>> 
>> These keep automatic narrowing of polymorphic types, but requires explicit 
>> narrow/unwrapping of optionals (because we can define methods/properties on 
>> Optional there's no other choice unfortunately); it would work for both 
>> mutable and immutable values, but mutable reference types require an extra 
>> step due to the potential for unsafe operations.
>> 
>> I think that's about as flexible as we're going to be able to get without 
>> introducing other difficulties.
> 
> While the proposals try to be less restrictive than Kotlin, I don’t like the 
> way they handle concurrency.
> All usage of the ‘!’ operator in swift guarantee a crash at the call site if 
> something is wrong (try!, as!, optional!, …). In the proposals, the ‘!’ 
> operator means that the app may crash at call site or may crash later.

The error should still be associated with the line that actually failed, the 
only difference here is that the type-checking or force-unwrapping is handled 
for you behind the scenes, as you've opted into it for that scope by forcing 
the unwrap/narrowing to occur. Put another way; when you force unwrap/narrow a 
reference type, it is treated like an implicitly unwrapped Optional or 
implicitly narrowed type, so is checked for correctness as necessary.

Since narrowing/unwrapping has (sort of) occurred, we can produce an error that 
better highlights the problem, e.g- "Force unwrapped reference was set to nil 
by another method or thread", as the unwrap/narrowing functionality ensures 
that you can't do it in the current scope without it being detected. The error 
that requires you to use force unwrapping/narrowing can likewise be more 
specific, e.g- "Reference type foo cannot be unwrapped/narrowed safely" (I suck 
at writing error messages btw), the idea being to encourage developers to 
consider why and decide for themselves whether it's better to force the 
unwrap/narrowing (because they're confident it will work) or to instead work 
with a copy and put it back later, use locking etc. etc.

The only other component is an attribute to indicate when a reference is safe; 
I'm favouring something like @concurrency(safe), but the difficulty is whether 
it's enough to just indicate this or if it also needs to be enforced somehow. I 
might use the attribute for example on a property I know will be used in a 
copy-on-write style, but is it feasible to enforce that, perhaps with some kind 
of behaviour similar to no-escape? It becomes tough to consider every possible 
case for something like that, and it'd probably need some other supporting 
features, like a @copy attribute for return types so we can account for methods 
methods that produce a new copy of an instance (e.g- if your return type has 
the @copy attribute then it can't return self). It's probably more of a 
separate proposal though for how we'll handle concurrency and reference types 
natively.

Little bit off track there, but the short version is; forcing the 
unwrap/narrowing doesn't make your code any more or less safe for references, 
it just

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Charlie Monroe via swift-evolution]

> On Nov 15, 2016, at 8:53 AM, Rick Mann  wrote:
> 
> 
>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> One major example is the NS/UITableViewDataSource or Delegate - there are 
>> many many methods that you don't need to implement, hence are optional.
>> 
>> But I think that this was partially solved by default implementation of 
>> protocol methods, which pretty much does what you want...
> 
> I just realized I only responded to someone else, and not the whole list. It 
> does, but it forces me to make the return value of the protocol method 
> optional, so that the default implementation can return nil. 

You'd still get an optional even with @optional protocol methods:

@objc
protocol Foo {
@optional func bar() -> Int
}

let x = foo.bar?() // x is Int?

Nevertheless, in the previous example:

>   var titleForRow:((_ indexPath:IndexPath)->(String))? { get }

You can return String? in the closure instead and the default implementation 
can simply return a closure that returns nil. This is pretty much equivalent.


> In the end, I guess that's not so bad, since I'm not happy with the entire 
> approach, but it'll do for now.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 

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