I came across a strange behaviour. The following code produces a compile error where I call bar() with the message: "Missing argument for parameter #1 call"
func bar() {
println("bar with no argument")
}
class ClassA {
func bar(varOfAnyType: String) {
println("bar with argument")
}
func foo() {
bar()
}
}
If I change bar() function's name then I get no errors:
func barNameChanged() {
println("bar with no argument")
}
class ClassA {
func bar(varOfAnyType: String) {
println("bar with argument")
}
func foo() {
barNameChanged()
}
}
What's the reason for the compiler not allowing to override the function outside the class?
Cheers, Daniel
At the moment, the Swift compiler cannot distinguish between a method and a global function with the same name, regardless of overloading.
The solution is to prefix the global function with its module name, e.g.,
func bar() { }
class ClassA {
func bar(anything: String) {}
func foo() { Module.bar() }
}
Related
New to Swift and I am currently getting around passing a function as an optional parameter in the following way:
import Foundation
func foo()
{
print("Foo")
}
func bar()
{
print("Bar")
}
func dummy()
{
return
}
func myFunc()
{
myFunc(callBack: dummy())
}
func myFunc(callBack: (Void))
{
foo()
callBack
}
myFunc()
myFunc(callBack: bar())
i.e. exploiting polymorphism
This seems like an inelegant way to do this, is there a better way,
Thanks,
Tom
edit:
I am aware I could shorten this by doing:
import Foundation
func foo()
{
print("Foo")
}
func bar()
{
print("Bar")
}
func dummy()
{
return
}
func myFunc(callBack: (Void) = dummy())
{
foo()
callBack
}
myFunc()
myFunc(callBack: bar())
But I would still say this is an inelegant solution
You can easily define a default value for a function as parameter:
func foo(completion: () -> Void = { }) {
completion()
}
You could also have it be nil by default:
func foo(completion: (() -> Void)? = nil) {
When it's an optional closure, you'll have to call it like this:
completion?()
Your are referring to default arguments:
You can define a default value for any parameter in a function by assigning a value to the parameter after that parameter’s type. If a default value is defined, you can omit that parameter when calling the function.
So you need something like:
func myfunc (callback: ()->void = dummy) {
LinusGeffarth notes that callbacks in Swift are called completion, or closure as avismara notes.
Full code with answer applied:
import Foundation
func foo()
{
print("Foo")
}
func bar()
{
print("Bar")
}
func myFunc(completion: () -> Void = { })
{
foo()
completion()
}
myFunc()
myFunc(completion: bar)
Umm, are you passing function as an optional parameter, though? It looks like you have written a method that accepts Void, you have a function that accepts Void and you are just calling that method. I don't see any trace of polymorphism here except probably that the myFunc has multiple signatures. This method is an inelegant solution not because it is inelegant, but because it isn't a solution.
Here is a correct example of polymorphism in functional systems:
func printA() {
print("A")
}
func printB() {
print("B")
}
//This method accepts a function as a parameter
func higherOrderPrinter(with print: () -> Void ) {
print() //Can be anything, depends on the method you send here. Polymorphism much? :)
}
higherOrderPrinter(with: printA) //Prints A. See carefully how I am NOT doing printA()
higherOrderPrinter(with: printB) //Prints B
//In fact...
higherOrderPrinter {
print("C")
} //Prints C
I'd like to use the name of function to resolve some problems, but #function seems not to work well with #inline(__always), here is my codes:
#inline(__always) func log() {
print(#function)
}
func a() { log() } // want 'a()', but got 'log()'
func b() { log() }
func c() { log() }
//...
Can anybody explain? or that's just a stupid idea.
If your intention is to print the name of the function which calls
log(), then you should pass it as default argument (which is evaluated
in the context of the caller), as demonstrated
in Building assert() in Swift, Part 2: __FILE__ and __LINE__ in the Swift blog.
Example:
#inline(__always) func log(_ message: String, callingFunction: String = #function) {
print("\(callingFunction): \(message)")
}
func a() { log("Hello world") }
func b() { log("Foo") }
func c() { log("Bar") }
a() // a(): Hello world
b() // b(): Foo
c() // c(): Bar
This works regardless of whether the log function is inlined or not.
(Inlining does not change the semantics of a program. In particular,
it does not mean that the source code of func log is included from
the source code of func a() and compiled as a single function.)
In swift, an instance func can't call a static/class func without prefixing the method call with the class name. OR you can use type(of: self), e.g
class Foo {
static func doIt() { }
func callIt() {
Foo.doIt() // This works
type(of: self).doIt() // Or this
doIt() // This doesn't compile (unresolved identifier)
}
}
My question is, what's the difference here?
Is it just a matter of coding style, or is there some difference e.g. static or dynamic dispatch going on?
If it is just coding style, what's the preferred style?
There are two main differences.
1. The value of self inside the static method
The metatype that you call the static method on is available to you in the method as self (it's simply passed as an implicit parameter). Therefore if you call doIt() on type(of: self), self will be the dynamic metatype of the instance. If you call it on Foo, self will be Foo.self.
class Foo {
static func doIt() {
print("hey I'm of type \(self)")
}
func callDoItOnDynamicType() {
type(of: self).doIt() // call on the dynamic metatype of the instance.
}
func classDoItOnFoo() {
Foo.doIt() // call on the metatype Foo.self.
}
}
class Bar : Foo {}
let f: Foo = Bar()
f.callDoItOnDynamicType() // hey I'm of type Bar
f.classDoItOnFoo() // hey I'm of type Foo
This difference can be really important for factory methods, as it determines the type of instance you create.
class Foo {
required init() {}
static func create() -> Self {
return self.init()
}
func createDynamic() -> Foo {
return type(of: self).create()
}
func createFoo() -> Foo {
return Foo.create()
}
}
class Bar : Foo {}
let f: Foo = Bar()
print(f.createDynamic()) // Bar
print(f.createFoo()) // Foo
2. The dispatching of the static method
(Martin has already covered this, but I thought I would add it for the sake of completion.)
For class methods that are overridden in subclasses, the value of the metatype that you call the method on determines which implementation to call.
If called on a metatype that is known at compile time (e.g Foo.doIt()), Swift is able to statically dispatch the call. However, if you call the method on a metatype that isn't known until runtime (e.g type(of: self)), the method call will be dynamically dispatched to the correct implementation for the metatype value.
class Foo {
class func doIt() {
print("Foo's doIt")
}
func callDoItOnDynamicType() {
type(of: self).doIt() // the call to doIt() will be dynamically dispatched.
}
func classDoItOnFoo() {
Foo.doIt() // will be statically dispatched.
}
}
class Bar : Foo {
override class func doIt() {
print("Bar's doIt")
}
}
let f: Foo = Bar()
f.callDoItOnDynamicType() // Bar's doIt
f.classDoItOnFoo() // Foo's doIt
For a class method it makes a difference if the method is
overridden in a subclass:
class Foo {
class func doIt() {
print("Foo doit")
}
func callViaClassname() {
Foo.doIt()
}
func callViaTypeOf() {
type(of: self).doIt()
}
}
class Bar: Foo {
override class func doIt() {
print("Bar doit")
}
}
Bar().callViaClassname() // Foo doit
Bar().callViaTypeOf() // Bar doit
This is also documented in "Types" in the Swift Language Reference:
You can use a type(of:) expression with an instance of a type to access that instance’s dynamic, runtime type as a value, ...
I don't know a difference for a static method (which is final
and cannot be overridden in a subclass).
Correction: See Hamish's answer for the difference
in both static and class methods.
What I tried to do:
protocol HasElement {
associatedtype ItemType
func getElement() -> ItemType
func setElement(element: ItemType)
}
class Element {}
class BarElement: Element {}
class Foo: NSObject, HasElement {
typealias ItemType = Element
func getElement() -> Element { ... }
func setElement(element: Element) { ... }
}
class Bar: Foo {
typealias ItemType = BarElement
override func getElement() -> BarElement { ... } // This works.
override func setElement(element: BarElement) { ... } // This fails.
}
The error is:
Method does not override any method from its superclass
If I try to use ItemType instead:
override func setElement(element: ItemType) { ... } // Still fails.
The error is:
'ItemType' is ambiguous for type lookup in this context
Is there a way to make this work?
Here's a way to do what you want:
protocol HasElement {
associatedtype ItemType
func getElement() -> ItemType
func setElement(element: ItemType)
}
class Element {}
class BarElement: Element {}
class Foo: HasElement {
// no need for typealias, the associated type is inferred
func getElement() -> Element { return Element() }
func setElement(element: Element) { }
}
class Bar: Foo {
// no need for typealias, the associated type is inferred
override func getElement() -> BarElement { return BarElement() }
// hide the parent class method
#available(*, unavailable, message: "Use setElement(element: BarElement)")
override func setElement(element: Element) { }
// comply with protocol in this class
func setElement(element: BarElement) { }
}
// can't do this now:
let myElement = Element()
let myBar = Bar()
myBar.setElement(element: myElement) // Error: 'setElement(element: BarElement)' is unavailable: Use setElement(element: BarElement)
The problem here isn't associated types, it's that method inputs are contravariant. Therefore you cannot override a method that expects a given superclass instance input with a method that expects a subclass instance input.
In fact, you can simply boil your code down to:
class Element {}
class BarElement : Element {}
class Foo {
func setElement(element: Element) { }
}
class Bar : Foo {
// error: Method does not override any method from its superclass
override func setElement(element: BarElement) { }
}
You simply cannot override an (Element) -> Void method with a (BarElement) -> Void method. The reasons for this should be fairly obvious if you consider what would happen if you created a Bar instance and upcast it to Foo. You're now able to pass an Element instance to a method that expects a BarElement instance, which is illegal.
The reason it works for your getElement method is that method outputs are covariant. Therefore overriding a () -> Element method with a () -> BarElement method is perfectly legal, as even if you upcast a Bar instance to Foo, the BarElement instance returned from getElement can be freely upcast to Element.
As for solutions, it rather depends on your exact use case. It may well be that what you're trying to do doesn't require inheritance at all, and instead you can just conform Foo and Bar to HasElement separately.
This works:
override func getElement() -> BarElement { ... }
using override keyword is when function signature does not change (BarElement is still Element). You copy and paste function from super class with same function name, same parameter name and same return value type.
But
override func setElement(element: BarElement) { ... }
fails because when you change parameter type (with same parameter name).
This case is overloading not overriding.
I'm trying to use a protocol with associated type as return value of a class func.
Another post here on stackoverflow is about the same question and based on this post's answer I tried the following:
// addArg takes a single Int argument and returns something,
// which is capable of adding a another Int argument
class OpWithNoArg {
func addArg<OP: OpWithOneArg where OP.ArgType == Int>(arg: Int) -> OP {
return OpWithOneArgImpl() // (1) error here !
}
}
// a protocol with associated type, which allows adding another
// argument of a not yet specified type
protocol OpWithOneArg {
typealias ArgType
func addAnotherArg(arg: ArgType)
}
// an implementation of the protocol above,
// which fixes the associated type to an Int
class OpWithOneArgImpl : OpWithOneArg {
typealias ArgType = Int
func addAnotherArg(arg: Int) {
// ...
}
}
The error in Xcode 7.0 Beta 4 on line marked with (1) is
cannot convert return expression of type 'OpWithOneArgImpl' to
expected return type 'OP'
If I change the return value to an optional and nil is returned, the sample compiles successfully:
// return null
class OpWithNoArg {
func addArg<OP: OpWithOneArg where OP.ArgType == Int>(arg: Int) -> OP? {
// return OpWithOneArgImpl()
return nil
}
}
Is this way of using a protocol with associative type as return value possible in swift, and if that's the case, how can the compiler error mentioned above be fixed?
Thanks in advance!
EDIT:
In Java, the code would be something like the following snippet. I try to find a way in Swift to achieve the same.
class C {
<T> P<T> f(T arg) {
return new PImpl();
}
}
interface P<S> {
void g(S arg);
}
class PImpl<S> implements P<S> {
PImpl() {}
public void g(S arg) {}
}
Not clear what you are trying to achieve, but imho the error stems from the fact that in your addArg function you define a generic type OP which should be typically used in the function's arguments and body.
Instead you return a non generic type trying to force it to be treated as a generic `OP.
A quick fix could be a force cast to OP of your return object:
return OpWithOneArgImpl() as !OP
but I wouldn't recommend it.
In your example your addArg will always return a OpWithOneArgImpl thus it could just be defined as a func addArg(arg: Int) -> OpWithOneArgImpl
Hope this helps.
EDIT:
Probably this is not what you're trying to achieve, but hope it can help
with a clearer explanation of what I intended above.
protocol OpWithOneArg {
typealias ArgType
func addAnotherArg(arg: ArgType)
init() // Must have a init with no argument
}
class OpWithOneArgImpl : OpWithOneArg {
typealias ArgType = Int
func addAnotherArg(arg: Int) {
// ...
}
required init() {
// init implementation
}
}
class OpWithNoArg {
func addArgWithOPType<OP: OpWithOneArg where OP.ArgType == Int>(op: OP.Type, arg: Int) -> OP {
return OP() // Here we use the init
}
}
let foo = OpWithNoArg()
foo.addArgWithOPType(OpWithOneArgImpl.self, arg: 3)
Edit:
Maybe you might investigate the use of generic types:
protocol OpWithOneArg {
typealias ArgType
func addAnotherArg(arg: ArgType)
init() // Must have a init with no argument
}
class OpWithOneArgImpl<T> : OpWithOneArg { // Generic implementation confirming to protocol
typealias ArgType = T
func addAnotherArg(arg: T) {
// ...
}
required init() {
// init implementation
}
}
class OpWithNoArg {
func addArgWithOPType<OP: OpWithOneArg>(op: OP.Type, arg: OP.ArgType) -> OP {
return OP() // Here we use the init
}
}
let foo = OpWithNoArg()
// OpWithOneArgImpl<Int>
foo.addArgWithOPType(OpWithOneArgImpl.self, arg: 3)
// OpWithOneArgImpl<String>
foo.addArgWithOPType(OpWithOneArgImpl.self, arg: "Hello")