Swift 'In' Keyword Meaning

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 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)
    }
}

What does in mean in Swift?

As like in your code example using in afther newValue let`s Swift and you know the return value of process is going happen on newValue so it is more like a symbol or flag called: "token" to you and to CPU that work is going happen on newValue because you put it before in, for example you gave name to onChange modifier with using newValue in, you will get updated value for name if get any new update, also note you can use $0 instead of newValue in and works same.

.onChange(of: name) { newValue in
    return print("Name changed to \(name)!")
}

Or:

.onChange(of: name) { 
    print("Name changed to \($0)!")
}

Both are the same it depends how you like it.

Another example for better understanding:

let arrayOfInt: [Int] = [1, 2, 3]

let arrayOfString: [String] = arrayOfInt.map({ value in return value.description })
let arrayOfString: [String] = arrayOfInt.map({ $0.description })

For example we have an arrayOfInt and we want create a String array of it, for this work we can use map, and again like last example we used in in 2 way. in the first one as: value in and in the second on as $0. I recommend you work and learn more about closure in Swift/SwiftUI they are very important, without knowing them well, we cannot have good understanding of codes in iOS.

Also do not forget to attention to word of return right after in you can type and use or not use it, Swift is Smart enough to understand because of inference, but if you use it, it make your code much more easy and simple to read and better in syntax of code.

What does the `` mean in swift and why is it useful?

The backticks allow you to use restricted keywords in places where they otherwise couldn't be used, such as variable names.

default is a restricted keyword in Swift, but by putting backticks around it, it becomes a valid variable name.

Without the backticks, your code would result in the error

Keyword 'default' cannot be used as an identifier here

What does 'on' mean in Swift?

That's the "external name" for the parameter. So within the function you refer to the argument as day, but when calling it, you use the label on. It's not a Swift keyword.

What does the swift keyword Wrapped mean in the Optional extension?

In extensions, the generic parameters of the type that you are extending can be referenced by just writing their simple names, and notice that Optional is a generic type.

@frozen enum Optional<Wrapped>

So Wrapped in the function declaration refers to the generic parameter declared there.

As you may know, optional types are usually written as T? (where T is some type), which is a syntactic sugar for Optional<T>. For example, Int? is the same as Optional<Int>, and String? is the same as Optional<String>, etc.

In other words, Wrapped basically just means the type that precedes the ?, whatever that may be. If you have a String? (aka Optional<String>), then the signature of flatMap for that would be:

func flatMap<U>(_ transform: (String) -> U?) -> U?

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.

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 'In' Keyword Meaning