I really like the roadmap the core team has come up with. The only critic I
personally would have is the need of the comma in var op(lhs:,rhs:) : (Int,
Int) -> Int. To me it would be consistent enough with selectors if there wasn’t
any comma var op(lhs:rhs:) : (Int, Int) -> Int.
I have a few questions about pitch #1.
Assuming we’ll get that functionality, both var and let should satisfy the
protocol requirements right?
Will this example be valid?
@objc protocol P : class {
@objc optional func foo()
}
class A : NSObject, P {
var foo: (() -> Void)? = nil
}
A.init().foo?()
If it is valid, could we potentially get optional functions in pure Swift as
well?
--
Adrian Zubarev
Sent with Airmail
Am 26. März 2017 um 22:11:19, Xiaodi Wu via swift-evolution
([email protected]) schrieb:
I'm in favor of both of these.
However, the issue outlined in (1) with respect to labels is problematic. The
core team's post-Swift 3 plan
(https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html)
for evolving from SE-0111 solves that problem without the need to invent new
rules for (1). IMO, that issue should be addressed first, then (1).
On Sun, Mar 26, 2017 at 14:04 David Sweeris via swift-evolution
<[email protected]> wrote:
On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution
<[email protected]> wrote:
I’d like to pitch the following two language changes. Both of them are
technically possible today if you manually write thunks for the relevant
protocol requirements, but it would be nice if we allowed them to be written
directly:
1) Allow closures to satisfy function requirements in protocols
protocol MyProtocol {
func run(param: Int) -> String
}
struct MyStruct : MyProtocol {
var run : (Int)->String // Satisfies requirement MyProtocol.run
}
Among other things, it would make writing type-erased wrappers in the style of
AnyCollection much easier. The only obvious niggle is that the argument label
wouldn’t be required when invoking the closure directly. The labels have no
type-system significance, but it does make it subtly easier to write less
generic code than you intend do. We could solve this by having code-completion
favour protocol methods in this situation, or simply to require the label when
invoking a closure which implements a known protocol requirement.
2) Allow functions with default parameters to satisfy function requirements in
protocols
protocol Sportsplayer {
func goalsScored() -> Int
}
struct SoccerPlayer: Sportsplayer {
struct GoalType : RawOptionSet {
static let Shot = GoalType(0x1)
static let Volley = GoalType(0x10)
static let Header = GoalType(0x100)
static let Any = GoalType(0x111)
}
// Default value .Any means this conforms to Sportsplayer
func goalsScored(type: GoalType = .Any) {
//...
}
}
struct Footballer: Sportsplayer {
struct GoalType : RawOptionSet {
static let Touchdown = GoalType(0x1)
static let FieldGoal = GoalType(0x10)
static let Any = GoalType(0x11)
}
// Default value .Any means this conforms to Sportsplayer
func goalsScored(type: GoalType = .Any) {
//...
}
}
I often find that I want to add some optional, implementation-specific
parameter to a function which implements a protocol requirement. That’s
currently not possible, and it’s a bit annoying.
IIRC, the issue with #2 is that protocols specify declaration-site details, but
default parameters are implemented at the call-site. At least I believe that
statement was accurate about a year(ish) ago... Dunno if anything has changed
since then.
If it can be made to work, though, I'd be in favor of it, and I think #1 as
well.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
