In Swift, Any could be used to represent any type (if you are not certain with it, see Apple's official tutorial or related tip in this book first). The definition of Any is seldom seen in fact, which is a type alias of protocol<>. It is a protocol composition in Swift, and the syntax would be:

protocol<ProtocolA, ProtocolB, ProtocolC>

The ProtocolA, ProtocolB and ProtocolC in angle bracket < > are the names of concrete protocols. By grouping them in a protocol<>, a new anonymous protocol is declared. The new anonymous protocol will require implementing all methods in ProtocolA, ProtocolB and ProtocolC, which means it is a composition of these three protocols.

It is equal to the ProtocolD below:

protocol ProtocolD: ProtocolA, ProtocolB, ProtocolC {

}

So, what is the meaning of protocol<> in the definition of Any? Yes, it means a protocol should implement nothing, which is conformed by every type!

Except for the ability to express empty protocol, the other difference from normal protocol is protocol composition is anonymous. Sometimes this could help us write clearer code. Types can be organized in different extensions in Swift. They might be here and there in the project. When a type conforms to a lot of protocols, it is very difficult for us to know what protocols this type implements.

Take an example, we have three protocols, each one represents an action of a kind of animal. And there is another mystery animal that conforms to all these three protocols.

protocol KittenLike {
    func meow() -> String
}

protocol DogLike {
    func bark() -> String
}

protocol TigerLike {
    func roar() -> String
}

class MysteryAnimal: CatLike, DogLike, TigerLike {
    func meow() {
        return "meow"
    }

    func bark() {
        return "bark"
    }

    func roar() {
        return "roar"
    }
}

Now if we wish to check how an animal makes sound as a pet, we may define a new protocol called PetLike, which is in fact a composition of KittenLike and DogLike. Analogous to that, if we are concerned with how it performs as a cat, we might define another CatLike protocol to conform to KittenLike and TigerLike. Finally, it turns to be:

protocol PetLike: KittenLike, DogLike {

}

protocol CatLike: KittenLike, TigerLike {

}

struct SoundChecker {
    static func checkPetTalking(pet: PetLike) {
        //...
    }

    static func checkCatTalking(cat: CatLike) {
        //...
    }
}

No additional content introduced, but two more protocols. It makes our code complicated, and the users of your code (maybe you in future) might guess what the PetLike and CatLike do -- they do not add any required methods and are just used for marking.

With the help of protocol composition, you can get rid of these kinds of confusing. Just mark them a typealias of the composition of protocols. Everyone could understand they are just a name later.

typealias PetLike = protocol<KittenLike, DogLike>
typealias CatLike = protocol<KittenLike, TigerLike>

It is more readable, and without introducing new types.

Furthermore, if we only use this composition once, and there is no misunderstanding in context, we can even make them anonymous like this:

struct SoundChecker {
    static func checkPetTalking(pet: protocol<KittenLike, DogLike>) {
        //...
    }

    static func checkCatTalking(cat: protocol<KittenLike, TigerLike>) {
        //...
    }
}    

The code and definition are closer, so there are less jumps when reading the code. However, the anonymous protocol composition hides some information. Please consider twice when you like to take it like this.

It is already quite a long topic, but I wish to say more about the conflict in extensions of Swift. There is no limitation about method names in different extensions. If we have two protocols A and B, with the same method name:

protocol A {
    func bar() -> Int
}

protocol B {
    func bar() -> String
}

In both protocols, the only difference in bar() method is the return value. If we write a Class type to conform A and B in the same time, how to avoid the conflict in method name when compositing protocols?

class Class: A, B {
    func bar() -> Int {
        return 1
    }

    func bar() -> String {
        return "Hi"
    }
}

For bar(), convert type when calling it could resolve the problem:

let instance = Class()
let num = (instance as A).bar()  // 1
let str = (instance as B).bar()  // "Hi"