Swift "With" Keyword

Swift with keyword

with is not a keyword - it's just an external parameter identifier. This works as well:

func toDebugString<T>(whatever x: T) -> String

Since the toDebugString<T>(x: T) function is already defined, by using an external parameter you are creating an overload: same function name, but different parameters. In this case the parameter is the same, but identified with an external name, and in swift that makes it a method with a different signature, hence an overload.

To prove that, paste this in a playground:

func toDebugString<T>(# x: T) -> String {
    return "overload"
}

toDebugString(x: "t") // Prints "overload"
toDebugString("t") // Prints "t"

The first calls your overloaded implementation, whereas the second uses the existing function

Suggested reading: Function Parameter Names

What is the use of the of keyword in Swift?

In this case, "of" is the label for the argument called "name".

If you were to call this function, it would be

student(of: "Mathematics")

However inside the student function, you would get it's value with "name"

func student(of name: String) -> String {

    print(name)

    // TODO: Do something and return

}

Just a suggestion, IMHO "of" is not very descriptive of what the function does or what "of" represents (is "of" an id? The name of the student?).

Can we use keywords as parameter names in SWIFT?

When using a keyword as a normal identifier you have to escape it using backticks ` like this

func setupTable(for: Genre) {
    switch `for` {
        case .drama: break
        case .comedy: break
    }
}

On a side note, as pointed out by @Hamish in a comment on the question, you should try to avoid using such names for variables, which (in this case) you can do by providing both an internal and external name for the parameter:

func setupTable(for genre: Genre) {
    switch genre {
        case .drama: break
        case .comedy: break
    }
}

Swift `in` keyword meaning?

In a named function, we declare the parameters and return type in the func declaration line.

func say(s:String)->() {
    // body
}

In an anonymous function, there is no func declaration line - it's anonymous! So we do it with an in line at the start of the body instead.

{
    (s:String)->() in
    // body
}

(That is the full form of an anonymous function. But then Swift has a series of rules allowing the return type, the parameter types, and even the parameter names and the whole in line to be omitted under certain circumstances.)

What are the new for , at , in keywords in Swift3 function declarations?

The syntax allow you to label arguments twice - once for use within the function (the parameter name) and once for use when calling (the argument label). By default these two will be the same (like with sender in your example), but they differ when it makes a function more readable at the call site:

prepare(for: aSegue, sender: something)

being more readable-as-a-sentence than:

prepare(segue: aSegue, sender: something)

Which sounds like you're preparing the segue, not preparing for the segue.

for would be a dreadful name to use internally in the function to refer to the segue, so you can use a different one if you require.

The idea is to meet the sometimes conflicting goals of readability at the call site and sensible naming in the implementation.

When defining a function, if you are going to use separate argument labels and parameter names, you specify the argument label first, and the parameter name second:

func sayHello(to name: String) {
    print("Hello " + name)
}

sayHello(to: "Pekka")

to only has relevance when calling the function. name is used inside the function.

What is the keyword repeating used for in Swift?

It's not a keyword, it's an optional function argument label that can differ from the local parameter name that's used inside the function/method.

Read the section Function Argument Labels and Parameter Names in The Swift Programming Language:

Each function parameter has both an argument label and a parameter name. The argument label is used when calling the function; each argument is written in the function call with its argument label before it. The parameter name is used in the implementation of the function. By default, parameters use their parameter name as their argument label. …

You write an argument label before the parameter name, separated by a space …

If you don’t want an argument label for a parameter, write an underscore (_) instead of an explicit argument label for that parameter.

What is the some keyword in Swift(UI)?

some View is an opaque result type as introduced by SE-0244 and is available in Swift 5.1 with Xcode 11. You can think of this as being a "reverse" generic placeholder.

Unlike a regular generic placeholder which is satisfied by the caller:

protocol P {}
struct S1 : P {}
struct S2 : P {}

func foo<T : P>(_ x: T) {}
foo(S1()) // Caller chooses T == S1.
foo(S2()) // Caller chooses T == S2.

An opaque result type is an implicit generic placeholder satisfied by the implementation, so you can think of this:

func bar() -> some P {
  return S1() // Implementation chooses S1 for the opaque result.
}

as looking like this:

func bar() -> <Output : P> Output {
  return S1() // Implementation chooses Output == S1.
}

In fact, the eventual goal with this feature is to allow reverse generics in this more explicit form, which would also let you add constraints, e.g -> <T : Collection> T where T.Element == Int. See this post for more info.

The main thing to take away from this is that a function returning some P is one that returns a value of a specific single concrete type that conforms to P. Attempting to return different conforming types within the function yields a compiler error:

// error: Function declares an opaque return type, but the return
// statements in its body do not have matching underlying types.
func bar(_ x: Int) -> some P {
  if x > 10 {
    return S1()
  } else {
    return S2()
  }
}

As the implicit generic placeholder cannot be satisfied by multiple types.

This is in contrast to a function returning P, which can be used to represent both S1 and S2 because it represents an arbitrary P conforming value:

func baz(_ x: Int) -> P {
  if x > 10 {
    return S1()
  } else {
    return S2()
  }
}

Okay, so what benefits do opaque result types -> some P have over protocol return types -> P?

1. Opaque result types can be used with PATs

A major current limitation of protocols is that PATs (protocols with associated types) cannot be used as actual types. Although this is a restriction that will likely be lifted in a future version of the language, because opaque result types are effectively just generic placeholders, they can be used with PATs today.

This means you can do things like:

func giveMeACollection() -> some Collection {
  return [1, 2, 3]
}

let collection = giveMeACollection()
print(collection.count) // 3

2. Opaque result types have identity

Because opaque result types enforce a single concrete type is returned, the compiler knows that two calls to the same function must return two values of the same type.

This means you can do things like:

//   foo() -> <Output : Equatable> Output {
func foo() -> some Equatable { 
  return 5 // The opaque result type is inferred to be Int.
}

let x = foo()
let y = foo()
print(x == y) // Legal both x and y have the return type of foo.

This is legal because the compiler knows that both x and y have the same concrete type. This is an important requirement for ==, where both parameters of type Self.

protocol Equatable {
  static func == (lhs: Self, rhs: Self) -> Bool
}

This means that it expects two values that are both the same type as the concrete conforming type. Even if Equatable were usable as a type, you wouldn't be able to compare two arbitrary Equatable conforming values with each other, for example:

func foo(_ x: Int) -> Equatable { // Assume this is legal.
  if x > 10 {
    return 0
  } else {
    return "hello world"      
  }
}

let x = foo(20)
let y = foo(5)
print(x == y) // Illegal.

As the compiler cannot prove that two arbitrary Equatable values have the same underlying concrete type.

In a similar manner, if we introduced another opaque type returning function:

//   foo() -> <Output1 : Equatable> Output1 {
func foo() -> some Equatable { 
  return 5 // The opaque result type is inferred to be Int.
}

//   bar() -> <Output2 : Equatable> Output2 {
func bar() -> some Equatable { 
  return "" // The opaque result type is inferred to be String.
}

let x = foo()
let y = bar()
print(x == y) // Illegal, the return type of foo != return type of bar.

The example becomes illegal because although both foo and bar return some Equatable, their "reverse" generic placeholders Output1 and Output2 could be satisfied by different types.

3. Opaque result types compose with generic placeholders

Unlike regular protocol-typed values, opaque result types compose well with regular generic placeholders, for example:

protocol P {
  var i: Int { get }
}
struct S : P {
  var i: Int
}

func makeP() -> some P { // Opaque result type inferred to be S.
  return S(i: .random(in: 0 ..< 10))
}

func bar<T : P>(_ x: T, _ y: T) -> T {
  return x.i < y.i ? x : y
}

let p1 = makeP()
let p2 = makeP()
print(bar(p1, p2)) // Legal, T is inferred to be the return type of makeP.

This wouldn't have worked if makeP had just returned P, as two P values may have different underlying concrete types, for example:

struct T : P {
  var i: Int
}

func makeP() -> P {
  if .random() { // 50:50 chance of picking each branch.
    return S(i: 0)
  } else {
    return T(i: 1)
  }
}

let p1 = makeP()
let p2 = makeP()
print(bar(p1, p2)) // Illegal.

Why use an opaque result type over the concrete type?

At this point you may be thinking to yourself, why not just write the code as:

func makeP() -> S {
  return S(i: 0)
}

Well, the use of an opaque result type allows you to make the type S an implementation detail by exposing only the interface provided by P, giving you flexibility of changing the concrete type later down the line without breaking any code that depends on the function.

For example, you could replace:

func makeP() -> some P {
  return S(i: 0)
}

with:

func makeP() -> some P { 
  return T(i: 1)
}

without breaking any code that calls makeP().

See the Opaque Types section of the language guide and the Swift evolution proposal for further information on this feature.

How to declare keyword variable in Swift

var `extension`: String?
var username: String?

init(`extension`: String, username: String) {
    self.`extension` = `extension`
    self.username = username
}

I think this will work by using ``.

What is the meaning of keyword throws in Swift?

init() throws can return more information about the failure and let the caller decide if they care about it or not. Read a useful post about it here.

To indicate that a function, method, or initializer can throw an error, you need to write the throws keyword in the function’s declaration after its parameters. A function marked with throws is called a throwing function. If the function specifies a return type, you write the throws keyword before the return arrow.

func thisFunctionCanThrowErrors() throws -> String

or in real code it might look like this:

enum PossibleErrors: Error {
    case wrongUsername
    case wrongPassword
}

func loggingIn(name: String, pass: String) throws -> String {

    if name.isEmpty { 
        throw PossibleErrors.wrongUsername 
    }
    if pass.isEmpty { 
        throw PossibleErrors.wrongPassword 
    }
    return "Fine"
}

The throwing functions like this must be called using one of the following try operators:

try
try?
try!

Using init() throws you can break the execution of a class initialiser without the need of populating all stored properties:

class TestClass {

    let textFile: String

    init() throws {
        do {
            textFile = try String(contentsOfFile: "/Users/swift/text.txt", 
                                        encoding: NSUTF8StringEncoding)
        catch let error as NSError {
            throw error
        }
    }
}

And in a structure you can even avoid the do/catch block:

struct TestStruct {

    var textFile: String

    init() throws {
        textFile = try String(contentsOfFile: "/Users/swift/text.txt", 
                                    encoding: NSUTF8StringEncoding)
    }
}

Is it complusory to use in keyword in closure? If no then what is the syntax wise difference between closure and computed property in swift?

greet is a closure. A computed property is

var greet : Int {
  return 4+3
}

greet // without parentheses

And "in" in closure is ~~also not~~ compulsory if a parameter is passed (by the way the return keyword is not compulsory)

var greet = { x in
  4+x
}

greet(4)

unless you use the shorthand syntax

var greet = {
   4+$0
}

greet(4)

Swift "With" Keyword